tobireif.com / posts Twitter

Switching to HTTPS 🔒

Why?

Chrome's planned (or by now current) status bar for HTTP pages:

red triangle, and the text 'not secure'

(More info is on the Google Security Blog.)

Chrome's status bar for HTTPS pages:

green lock, and the text 'secure'

HTTPS (HTTP over SSL/TLS) is more secure than HTTP. (As a user you still have to make sure you're at the right domain 😃 )

Service Workers "should be hosted over HTTPS".

The Web Share API requires "a secure context (typically HTTPS)".

For HTTP/2, HTTPS (TLS) is "de facto mandatory".

"Brotli availability is restricted to HTTPS connections."

If a site of yours is still being served over HTTP, here's one way of switching. Let's go!

Important Notes

HTTPS is supported by all current browser versions. Some obsolete browser versions don't support it, but they're obsolete.

Switching to HTTPS shouldn't negatively impact your Google ranking. And: Google says it uses HTTPS as a positive ranking signal (the effect might be small). But until Google finished indexing the new URLs there might be a negative impact on Google traffic/ranking.

If you have a huge complex website with many possibilities for non-HTTPS requests, you might want to consider doing the steps on a staging domain first.

For this howto, Chrome is assumed. Open the dev tools (eg on Mac do alt-cmd-j), then in the dev tool settings (accessed eg via the three dots near the closing cross) make sure that caching is disabled.

In this howto, "example.com" always stands for the domain.

You might need to adapt some steps to your site setup. For example, in addition to searching through static files using grep you might also have to search through the respective database.

For each step: If it didn't automatically cover the subdomains, do it for them as well.

Change any same-domain URLs to Paths

In the local website directory, search for same-domain URLs:

(Make sure to replace "example.com" with your domain.)

grep -ri "example.com" *

If the URL is a ref/link, change it to a path. (If necessary test eg the ref/link.)

Update URLs pointing to other Domains

In the local website directory, search for non-https URLs:

grep -ri "http:" *

For each URL:

(Namespace URIs typically are not to be changed.)

(Should be changed to "https:" when it's a link, must be changed to "https:" when it's a ref.)

Make sure that it can be loaded via HTTPS, then make sure that the URL starts with "https:". (And also adjust the link URL that gets displayed on the page, if any.) If necessary test it: Make sure that the refd resource / linked page works using that updated ref/link/URL (and check the browser console).

Set up an SSL (TLS) Certificate

In the hosting account, activate an SSL (TLS) certificate (it might be free / included in your plan). Another option to consider is Let's Encrypt (Wikipedia).

Ensure a Blank Slate

Make sure there are no HTTPS-related lines in the server config (eg in the .htaccess file), eg comment them out. (Don't forget to eg uncomment/delete them after this howto.)

Chrome → click top right on the profile name (or "People") → Manage People. Add Person. As name have "DELETE_THIS_PROFILE", Save. Another way is Chrome → Preferences → People → Add Person, enter the name, Add.

Use the new browser profile. Ignore the page content. Open the dev tools, open the network tab.

Enter the HTTP URL.

In the URL bar there should be no green lock, because the browser hasn't been instructed to use HTTPS.

Forward to HTTPS

For example if the site gets served by Apache: See "RewriteHTTPToHTTPS". For example add these lines to eg the .htaccess file, including R=301:

RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

If you use NGINX there's an example at Creating NGINX Rewrite Rules → "Forcing all Requests to Use SSL/TLS".

In the browser enter the HTTP URL.

In the dev tools network tab you should see (for the site index page) status 301, and in the next line (also for the site index page) status 200.

All is good: 301 is a good status code for the redirect, and 200 means OK.

(Make sure to replace "example.com" with your domain.)

Make sure that both URLs "http://example.com" and "https://example.com" can be entered. The "http:" URL should automatically change to "https:". Both should load the site and there should be a green lock in the browser's URL bar.

Set the HSTS Header

From the Mozilla Developer Network page: "The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) is a security feature that lets a web site tell browsers that it should only be communicated with using HTTPS, instead of using HTTP." (more)

For example if you use Apache ensure eg this (eg in the .htaccess file):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS

Enter the HTTP URL.

The status codes for the site index page should still be 301,200 this first time after the HSTS header has been set, and there should be a green lock.

Enter the HTTP URL again.

Now (in Chrome, not in Firefox) there might be a different status code in the network tab, eg status 307 - that's because of the HSTS header, and is OK:

Zineb Ait of Google says: Tweet 1: "The 307 is just an "internal redirect". The browser basically decides to not even try to call the HTTP version". Tweet 2: "It uses the 307 "internal redirect" to go directly to the HTTPS version, without talking to the server."

In the second network tab row (in Firefox it's the only one) for the site index there should be status 200. And there should be a green lock in the browser's URL bar.

If these two are true it's all good now.

Delete the profile: Chrome → click top right on the profile name → Manage People. In the "DELETE_THIS_PROFILE" box click the menu dots, Remove This Person (then click Remove This Person again). Another way is Chrome → Preferences → People, click on the profile, click the cross.

Check the Site

Navigate through a small but roughly representative subset of pages, using eg the website dir tree as list.

(Always have the browser console open.)

For each of these pages (including the site index page) check the browser console, and check whether there's a green lock in the browser's URL bar.

Check the Setup

Open the dev tools security tab, reload, check the info. Also use ssllabs.com/ssltest (it seems "A+" is the highest rating), and jitbit.com/sslcheck.

Monitor the Site

Ideally ensure availability monitoring / "uptime monitoring". It should load a file from the domain, not just ping it. That should catch any major HTTPS/SSL/TLS request issues.

Monitor for Mixed-Content Warnings

If there's a risk that there will be non-HTTPS (HTTP) resources requested from your site in the future, do all you can to prevent that.

You also might have to monitor the pages for mixed-content warnings. There's an example described in this post about Moving the Washington Post to HTTPS (archived copy). (In that post see the paragraphs containing "Selenium", "Content-Security-Policy-Report-Only" and "Sentry".)

Also see this page about CSP (Content Security Policy) → reporting.

The Apache line could look like this (untested) example:

Header always set Content-Security-Policy-Report-Only "default-src https:; report-uri /your/secure/and/locked-down/reporting-tool/"

Update the URL everywhere

Update any email signatures, account profiles (eg the URL in the Twitter profile and bio, GitHub profile, Slack profile, etc). Also consider the most important other places where the URL is used.

For each site where you might ref/link/feature the site, make sure that the URL starts with "https:". In each respective dir do this:

(Make sure to replace "example.com" with your domain.)

grep -ri "http:\S\+example.com" *

(Also do this for the site itself.)

If you have a sitemap, update it as well.

Google

If you're using "Google Search Console": See eg this guide → "create a new Google Search Console profile for the HTTPS version" etc. If you're using "Google News Publisher Center": If you're "making use of News sitemaps", contact the News team. If you monitor your Google traffic/ranking: If after 2-3 weeks you're (still) seeing issues, contact Google.

It's a Wrap

That's it! Chrome should be happy now 😃
And your users can enjoy a more secure data transfer.

If you enjoyed this post, follow me on Twitter Twitter

P.S. HTTP/2

Your hosting provider might have automatically switched you to HTTP/2 when you switched to HTTPS. Here's an online checker. Or you can use Chrome's dev tools: network tab, reload the page, right-click (or eg on Mac ctrl-click) on a table header eg Name or Method, make sure Protocol is checked and present, check for protocol "h2".