SSL revisited...external js resource not available w/ SSL does not run - SSL error

RapidWeaver Classic
1

I have converted to SSL. I have a Rewrite redirect in my htaccess to redirect all site links to SSL. I also used this meta tag:

http-equiv=“Content-Security-Policy” content=“upgrade-insecure-requests”

which I believe redirects some external scripts (google analytics and such) to their SSL version. Correct? All my pages do now show “Secure.”

However…
I have one external script that is not executing because it is not available on SSL. The Chrome Dev tools shows "net::ERR_SSL_PROTOCOL_ERROR.

So I’m assuming that the use of the meta tag shown above forces one to use ALL SSL resources and there is no alternative? (To be “Secure” you can’t use ANY non-secure external script.)

Thanks in advance for your comments to my assumptions…

2

Yes need to have everything available as an https request:

It is worth noting, that if the resource is not available over HTTPS, the upgraded request fails and the resource is not loaded. This maintains the security of your page.
From:
Cómo corregir contenido mixto  |  Articles  |  web.dev

1 Like
3

Also should note that a script would be considered “active content” and would be blocked without the above meta tag.

4

Thanks for the info Doug! Appreciate the link info!

5

I had contacted the owner of the non-secure script and he informs me (knowing Googles plan re SSL) that he’s adding an script that runs on SSL. Nice, seeing that it is a free service…

6

@teefers and alll
OK… this is weird… I swear I had tag shown below on my pages before (in the code section) - it’s still on most my live pages and they show secure even though there is non-secure calls.

http-equiv=“Content-Security-Policy” content=“upgrade-insecure-requests”

But now I see it is gone from all projects and when I add it to page code Preview is broken (css is not executing nor images). Yet, again, when I look at page code on the server the meta tag is there on my pages so I know I had the meta tag there at one time. I recently upgraded Stacks… and RW. Could the code had been removed somehow and now cause problems in preview? This is very very odd.

7

Don’t know what happened to the code, never had an upgrade effect a project but the sample you have above will not work needs to be a meta tag:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Needs to be in the head section:

Page level:

Site wide:

2017-06-08_07-53-22.png1089×138 24.2 KB

8

that’s exactly what I have and it breaks my RW Preview (i didn’t include the entire code line in my post… I thought it would mess up the forum post.)

I can send you screenshots but I put the COMPLETE meta tag in HEAD section exactly as you show and it destroys my Preview - (css and pic paths are destryed)

9

And strangely, if I go remove the meta tag the broken Preview remains until I Quit and Relauch then Preview is back to normal. Shall I make a screen video to show???

10

video coming video coming

11

This use to work. Looks like it breaks both preview and “local published” sites now.
I tested it as well, and any file that is still HTTP: or relative linked (all the internal CSS etc.) does not load in a preview.
Also tried local publishing and same problem in Chrome and Safari.

1 Like
12

ok… won’t post video then… At least I know I’m not crazy. I know it worked at some point as almost all of my 1500 pages have that meta tag on them. At some point in my 7 projects the tag just disappeared from “code” and now it doesn’t work. weird…

1 Like
13

Don’t know what happened to the code in your projects, but it is still listed in the Google document above as being a usable workaround. Did you say it still works on the server?

Perhaps @ben or @dan can chime in on this one.

14

yes… works fine when the page is published… Page renders correctly and non secure site links are upgraded. Non-secure offsite scripts are not executed. It is only RW Preview that breaks.

Here’s a video if @ben @dan want to see…

https://vimeo.com/220826453/88ee3df2b6

1 Like
15

What if you use this snippet

# Content Security Policy rule
Content-Security-Policy: upgrade-insecure-requests;

in your .htaccess file instead of placing it in the head of your document? It will serve the same purpose, but it should not affect the Preview mode in RW.

16

Is that valid? I searched for methods using htacces but didn’t find any. My host said there was no way to do this on server side… Also, the whole thing looks too browser dependent to me when I read about it.

Thus… I’m simply forcing myself to fix all non-secure calls. After working on this all day I’m well on my way to a “native” (real) secure site without any tricks. It also forced me to cleanup some old RW5 custom css that appeared on hundreds of pages. Those have all now been deleted and “global” secure css calls used instead.

17

That is not a valid Apache Directive. You should be able to set it in the htaccess file with something like this:

Header set Content-Security-Policy "upgrade-insecure-requests; default-src https:"
I don’t have a way to test this.

1 Like
18

Indeed, Doug, Greg, you were right. Sorry for this.

I have checked with the Mozilla Observatory site and I can confirm that the following snippet of code works when placed in the .htaccess file:

# Content Security Policy rule
Header always set Content-Security-Policy: upgrade-insecure-requests;
2 Likes
19

Thanks for that. I always appreciate your comments and suggestions. We all post mistakes now and again. As for myself, it’s usually when I haven’t had my 10 cups of coffee yet… :dizzy_face:

1 Like
20

Be careful with that coffee, Greg. Medical studies show that more than two cups a day pose increased risk of a heart attack in people who are prone to a heart attack… :worried: