Have you cleared cache in Edge and Firefox? May take several tries.

I did that before and now several times again. I even googled how to do it just to make sure I did. I can't reboot right now but I'll do that later on a couple of times.

I will say, I seldom use FireFox and never use Edge. I have any number of URLs to choose from that neither of those browsers have ever accessed at all. All of these "new" pages display the same behavior (wrong URL structure, and for that reason broken https notice).

I would ask the support people at your host just to make sure about your redirect code.

Another thing to check is your cert. Some self-signed certs may cause this type of issue.

[webmasterworld.com...]

- Also -

Try changing your last line to:

RewriteRule ^ [%{HTTP_HOST}%{REQUEST_URI}...] [L,R=301]

(it was missing the "s")

Sorry, forum software hid the full code. That may have also happened with your code, but just to make sure, that should have said:

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Thanks for the clarification keyplyr. I looked at your code and mine above and noticed some problems

I've changed the code in my htaccess file, I guess 4 times.

Recently I used this code, the idea was for each variation:
https://www.example.com/
http://www.example.com/
https://example.com/
http://example.com/

Each variant would only involve one 301 redirect-

 # non-www to https://www
 RewriteCond %{HTTP_HOST} .
 RewriteCond %{HTTP_HOST} !^www\. [NC]
 RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] 

 # http traffic to https
 RewriteCond %{HTTPS} off
 RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The problem variant is the form:
https://example.com/
(all of the other forms work fine)
My results are:

1) The Chrome browser address bar and the tool at www.redirect-checker.org and they both show a redirect was made to https://www.example.com. With these everything checks out fine.

2) FireFox and Microsoft Edge both show https://example.com in the address bar (as in no redirect took place, I get the broken https notice).

I've used the www.redirect-checker.org in FireFox, it shows the redirects as occurring (I don't know if that's really a test or not).

I've also tried https://example.com on mobile (Chrome and Dolphin). I get the problem results (no redirect, broken https).
-------
I didn't really have the knowlege to read the above code, so I rewrote it this way so I could understand it better:

 # non-www to https://www
 RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
 RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

 # http traffic to https
 RewriteCond %{HTTPS} off
 RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This resulted in the exact same success and failure as reported above.

-----------------------
All of the above was done to minimize the total number of redirects for each of the variants above.
I finally threw in the towel and coded things this way.
With it some variants would end up with two 301's, including my problem https://example.com

 # non-www to http://www. Note - this doesn't convert to https right off the bat.
 RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
 RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]

 # http: traffic to https: 
 RewriteCond %{HTTPS} off
 RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This resulted in the exact same success and failure as reported above.

=============================================
I rewrote the code so I could read it better.

 # non-www to http://www.
 RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
 RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]

 # http: traffic to https: 
 RewriteCond %{HTTPS} off
 RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

This resulted in the exact same success and failure as reported above.

==========================================
It seems all of these tries at redirecting each get the job done (why else would Chrome and www.redirect-checker.org show they did).

Is there something else about Apache or cPanel or Drupal where the https://example.com form gets reversed?

The www form of my URL has been declared as my preferred one for over a decade.
That makes me think the https://example.com form is the least likely one someone might try or be presented to use, so I guess this isn't the end of the world.

But does anyone have any ideas? Thanks.

The certicate is one of those "Let's Encrypt" ones, installed by cPanel (apache). (I ran my installation through one of those ssl checker websites, it suggested that everything with it was fine.

I was aware of the SNI issue, but that involves browsers and OS much older than what I'm using (stated above).

The glaring issue is in the non-www form of the domain (https://example.com) showing both in the browser address bar and in the "not secure" warning.

The certificate works, when the URL is correct. The problems seems to be triggered by the wrong form of the URL showing (https://example.com instead of https://www.example.com).

Drupal may be the issue. Make sure all pluggins/apps are https complaint and that they are not redirecting tha path themselves.

[edited by: keyplyr at 2:37 am (utc) on Oct 18, 2016]

Ok thank you. I'll google that. After spending most of the day with this, I've finally opened a ticket with my host.

You'll figure it out. This is how we learn.

I found this thread, and have read it but don't understand it.
[bugzilla.mozilla.org...]

The person has the exact same problem as I do (Aug 2016) except that their preferred URL is the non-www version.

It talks about getting a second ssl certificate, in my case it would be for https://example.com

But wouldn't that allow https://example.com pages to be served for a https://www.example.com domain?
Isn't that a duplicate content issue?

Gosh, I just now realized it. As things are right now don't I have a duplicate content issue?
(Would google's spider have the same difficulty as firefox, edge and mobile chrome in resolving things?)

I have all 4 forms of this website set up in Search Console (https://wwww.example.com, http://www.example.com, https://example.com, http://example.com). Does that protect me?

I've also found this thread, and think this specific comment in it addresses my issue but I don't really know what they are referring to or what solution they are suggesting:
[community.letsencrypt.org...]

I would definitely check into your Drupal requirements (which I know nothing about) because in your first post on this topic you mentioned that there had been a few lines with [protossl that were in your .htaccess file that got removed when you added the rewrite lines. Possibly the Drupal platform needs to have those lines in place to comply?

As for the lines mentioned here, there are two 301s because there are two separate 301 rewrites. It is possible to combine those two rewrites into one simply by rewriting the non-www to https rather than http and then to https:

#Redirect invalid and non www requests
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule (.*) https://www.example.com/$1 [R=301,L]

It is also possible that some of your existing resources use http without the 's' that can cause mixed http and https requests for the same page which can show warnings in some browsers/versions. For example, if Drupal uses full URIs and needs those [protossl lines to change a link for a .css file or a .js file to a secure https request you may see some warnings. On some of the https upgrades I see these lines added:

RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

to deal with those kinds of full URI internal and third party external resources. This may or may not work on your host's setup, may or may not be necessary. The Apache site offers tons of information and also warns:

Note that many of these examples won't work unchanged in your particular server configuration, so it's important that you understand them, rather than merely cutting and pasting the examples into your configuration.

By all means I would check into both Drupal's documentation and the information supplied by your host rather than depend on shared code that works fine in another server environment. I believe it is to every webmaster's advantage to get a basic understanding of the meaning of whatever they add to an .htaccess file.

I had finally contacted my host. Their response there was some error in my redirect code (at least I think that's what they're suggesing) in htaccess. They needed an OK on my incurring a small fee to change things. I OK'ed that but just now, the change hasn't been implemented yet.

I'm not really sure I have much faith in that working. I've tried different ways of stating the redirects in my .htaccess (listed above). I could definitely see that they all worked in Chrome and in 301-checker websites. A redirect does occur. It's just that by the time the page gets back to some browsers that detail is lost.

If that doesn't solve my problem I'll try your redirect code above.

Then I'll investigate the protossl issue.
A part of my http to https switched was discussed here:
[webmasterworld.com...]
In it, there is a suggestion that commenting out the protossl lines could be a problem.

I've got a support thread at Drupal.org about my general problem but no real solutions suggested yet.

In your list of Rewrite Rules, these should be the last - other than any default Drupal lines (if any). If you have any rules after these, that could cause a problem.

I do have these rules following:

This first one looks like it needs all of the above to work properly.

 # anti-hotlink for images
 RewriteCond %{HTTP_REFERER} !^$
 RewriteCond %{HTTP_REFERER} !^https://(www\.)?example.com [NC]
 RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

This second one just doesn't seem like something involved with the type of problem I am having.

 # Pass all requests not referring directly to files in the filesystem to
 # index.php. Clean URLs are handled in drupal_environment_initialize().
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteCond %{REQUEST_URI} !=/favicon.ico
 RewriteRule ^ index.php [L]

[edited by: Broadway at 12:34 am (utc) on Oct 19, 2016]

The fix provided by my host (fiddling with the redirect in htaccess) didn't do the job.

I'll try putting the protossl variable back into the htaccess file.
Having said that, a few minutes ago it dawned on me that I have one section of this website that is still coded in static HTML.
I tried the offending form of the URL (https://example.com) with those pages. Just like above they work with Chrome and fail with Firefox. I guess that suggests that Drupal really isn't the problem.

I had been worried that my problem either wasn't universal or else just due to not clearing browser caches properly.
I dug out a Windows 7 laptop I haven't booted in months. With it all browsers failed (broken https notice, no redirect shown in the Address Bar) - Chrome, Firefox, IE.

I also tried two different ISP's (Mediacom, Verizon).

Possibly its the way I configured something in cPanel, I've asked my host.

I did a reverse IP look up and found two websites hosted on the same server who are https and use the form www. They are also both Drupal 7 websites just like mine.

I tried the form of the URL I am having problems with on those sites:
https://example.com

Both redirect and work fine.

I mentioned them to my host, thinking maybe they can compare mind to those at their end to help to figure this out.

The certicate is one of those "Let's Encrypt" ones, installed by cPanel (apache). (I ran my installation through one of those ssl checker websites, it suggested that everything with it was fine.

The redirect code shouldn't make any difference, the fact that different browsers act in different ways is most likely due to their differences in handling the certificate when used with the bare domain. If the certificate is not valid for the bare domain but only for the www version, the browser could interrupt the redirect.

So, you need to start by making sure the Let's Encrypt certificate was issued for all variants of the domain (with and without www).

As an update to some suggestions above:

I downloaded a fresh gzip of Drupal and copied and pasted it's .htaccess file protossl and redirection code verbatim.
It only makes the switch non-www to www (or whatever your needs are).
That worked fine in all browsers.
From there I tried to insert code for the http to https redirection.
I was never successful, in some browsers (detailed above) the https://example.com redirection to https://www.example.com was not seen as taking place.

Also as mentioned above, I have one section on this website that is static html still (no Drupal involved) and those pages display the same symptoms.

How sad, all of that effort associated with the simple solution encyclo states.

The certificate needs to be for both www and non-www.

To me, that would suggest that I'm allowing both forms and therefore serving duplicate content.
The fact that FireFox and others evidently don't acknowledge the actual redirect I'm sure has a purpose to them but is misleading about the actual problem. Why would I need a certificate for a form of the URL that isn't served?

What's worse is I have two websites (two different servers) having this identical problem.
I saw encyclo's comment and immediately went to test and see (with success).
But by the time I had written a note to close out my support ticket about the original site, they had already identified the same problem and corrected it, so I didn't even get the satisfaction of claiming the victory over them.

I'll also state, why wouldn't the host have thought of that solution first rather than the .htaccess file?
I bet they saw the answer here.

Why would I need a certificate for a form of the URL that isn't served?

Well, technically you are serving it, just with a 301 :) Glad it's worked out OK, it is interesting to note that Edge and Firefox are possibly more technically correct, but Chrome is more usable and fault-tolerant by not choking on an invalid certificate when the response is a redirect.

Strangely I'm currently dealing with an issue on a site where Chrome on Android throws up an error due to a chain issue with a certificate, whereas Chrome on Windows doesn't show the same error and Edge, Firefox and Safari (iOS) are all fine. So you should also check with the same browsers in Android and iOS, not just Windows (Chrome/Android seems to be a stickler for exactitude when it comes to certificates).

There is also something wrong with the host's implementation of the Let's Encrypt certificate-generation scripts if they are not generating certificates which are valid for all variants of all the domain names associated with the site.

I've checked on my Android phone (Chrome, Dolphin), things work fine.
I dug out an old Windows 7 laptop. With it, all browsers failed (Chrome,IE,Safari,Firefox) with my original set up.
With the new certificate, they all now work properly.

I can't fault Let's Encrypt. In cPanel there clearly is an option for selecting your domain and any associated "aliases" you want when generating the (multiple) certificate. It's just like I stated above, with my htaccess redirects in place I thought I was just serving one form of my URL.