Some off the top of my head brain dump notes, after a quick completion of most of our HTTPS changeover (finishing off work done) following the Chrome and Firefox updates earlier this year:
== Prep ==
-
Get good certificates preferably with an older vendor - or be prepared with links on how to update out of date authority root certificates e.g. https://support.quovadisglobal.com/kb/a54/updating-the-microsoft-windows-root-store.aspx if you get contacted by people reporting they can’t access your site.
-
Know your sites and how they’re templated. You may only have one (congratulations) or you may have hundreds (in which case you have my sympathy and understanding).
We found we needed to test a variety of pages from each site to see what works and what didn’t. Mixed content warnings can be unobtrusive, and nicely telling the site visitor that the browser is helpfully not including images, CSS stylesheets or JS using an HTTP address, which may result in pages not showing as expected.
If you’re lucky you won’t have many hardcoded HTTP links. If you do, you might find it useful use server side tech to address the issues. With mod_subsitute on Apache, you can use substitution to rewrite http links to https as the page content is being served from the server, and we’re using that with earlier non Matrix sites. Nginx has ngx_http_sub_module which I’d hope operates similar. Not 100% sure how mod_sub
If you have any forms with hardcoded action links pointing at older HTTP addresses on your sites & systems, remember to update them.
-
Enable HTTPS as early as possible and test.
-
If you have proxy and caching setups separate from Matrix, figure out what you need to test to make sure everything works as expected. We use a reverse proxy setup using Apache ProxyPass and needed to make updates to point all the proxy configuration lines to the HTTPS addresses of the Matrix sites to ensure Matrix generated links with the HTTPS protocol.
-
Research the Strict-Transport-Security header, and whether / when you can consider enabling it. If you have any content / sites that will remain on HTTP due to any issues, my reading is that you have to leave it un-enabled.
== Changeover ==
A quick webpagetest.org of our https addresses shows that the testing system waiting ~826ms to get the verification for our certificates back from our certificate vendor.
- If you’re using Apache as your HTTPD server, use a redirect on the HTTP instance to point any HTTP requests to the HTTPS addresses per https://wiki.apache.org/httpd/RedirectSSL. You can use a rewrite but it’s not recommended. We’re using one to allow access to some of our subsites via HTTP until we complete work to make them display via HTTPS without mixed content warnings.
I’m sure there will be ways to do that with Nginx, IIS etc as well.
NB: If you do what Bart suggests above:
what I’ve found on some browsers (especially older ones) is that if you enter a url and there’s nothing listening on HTTP, you may not see anything unless you’re running an HTTPS everwhere extension which pushes you to HTTPS by default.
There’s also a little gotcha that’s come out of the woodwork for us post HTTPS changeover - read https://wiki.mozilla.org/Security/Server_Side_TLS and try to develop an understanding. Depending on what SSL ciphers your system is configured to accept and how strongly encrypted you want your HTTPS to be, you may end up creating problems with access to older browsers running on older devices to your HTTPS site.
It may or may not matter to you, depending on who your clients are and what legislation you do or not not need to comply with. It has me looking for an alternative to the HTTP to HTTPS redirect from above that caters to browsers where we can identify that they can’t handle the mozilla intermediate or recommended configurations.
