Always use HTTPS doesn't always work


#1

… or else I misunderstand it. I’m hosting a few sites that use Cloudflare; all have valid SSL certificates, all have Always Use HTTPS turned on. Some of them do not redirect to HTTPS. Some of them do. Some of the ones that do seem to do it stealthily; in Safari, for example, the lock won’t appear in the URL bar, but the site is in fact resolving to HTTPS.

All of the sites will resolve to https if I enter the https url manually. Of the ones that won’t, I’ve tried forcing them with .htaccess, but they remain http.

Is there any logic to how this feature works? What could I be missing?


#2

Hey there, I’ll see if I can help.

Yes, this can happen. Another user on the community is experiencing similar issue right now in fact with their site, due to mixed content. Here is the thread:

If you provide a URL of one of the sites that is affected deeper analysis can be conducted.

Edit: additionally, you may try enabling Automatic HTTPS Rewrites for one of the sites affected (if not already enabled). It’s at the bottom of the Crypto tab on the Cloudflare dashboard.


#3

Mixed content is a very common reason for the SSL status to appear inconsistent. More info here as well:


#4

Hi, thanks for offering to look. I don’t believe there’s a mixed content issue here. It’s a simple static site that’s mostly a placeholder right now: under-belly.org.

“Always use https” is selected on the Cloudflare Crypto page. There’s an .htaccess file that redirects www.under-belly.org to the right url; curiously this does force https. My attempts to get the .htaccess to also redirect http://under-belly.org to https have either done nothing or else broken the site.


#5

Yeah, mixed content issue. http://www.google-analytics.com/ga.js, is bein invoked via document.write statement at (around) line 44.


#6

“Yeah, mixed content issue. http://www.google-analytics.com/ga.js, is bein invoked via document.write statement at (around) line 44.”

Oh, that makes sense! I manually embedded that code ages ago. It’s probably years obsolete.

I’ve replaced that with the contemporary analytics code. Oddly, I didn’t see any non-https google addresses in the original version.

I don’t see a change in behavior, but it could be a caching issue at this point. I’ll see if fixes itself over the next few days. If not, the google code isn’t the issue.


#7

A post was split to a new topic: Receiving unsupported protocol error? Cipher Mismatch


#8

24 hours later and no changes.

I tried another version of .httaccess redirection. This solves half the problem: it consistently forces https.
But it won’t convert www to non-www. I tried adding the lines from the file that stripped the www, but it didn’t have any effect.

Here’s the code that at least forced https:

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

(this is identical to the code used by the WP Rocket plugin)