It was recently discovered that Cogneato websites’ HTTPS certificates were cross-signed by an expired AddTrust certificate, and were showing security warnings in old versions of Safari.Continue reading post "#2949"
I had to manually force renew the TLS certificate for my site (the thing that makes it encrypted over HTTPS) because of a bug in LetsEncrypt’s software.Continue reading post "#2674"
I use Letsencrypt with certbot for the HTTPS certificates of my personal sites. I use the
certonly method to allow full control over my server configuration. This means specifying one or more web-roots for each certificate.
In the interest of progressive enhancement, my site doesn’t force browsers to connect over HTTPS unless they demonstrate support for it.Continue reading post "Forcing HTTPS and progressive enhancement"
Gah. Apparently wordpress.com is discouraging ‘https’ for self-hosted blogs: Their redirection service does not allow any protocol but ‘http’. I could swear it did when I first set it up, as I remember typing in my URL with ‘https’ and I thought I tested it with
curl -I to make sure it works, but the docs have an explicit note saying:
Note: Site redirects will only point to a non-ssl ( http:// ) url.
I don’t remember seeing it before, but the wayback machine suggests it was there since 2013, well before I switched to self-hosted.Continue reading post "WordPress.com redirects don’t support HTTPS"
Jetpack’s sitemap plugin has gotten an update or two since I found it listing the wrong protocol for my URL’s, so I decided to give it another try. Now the protocol seems to be correct, so I am leaving it enabled and hoping it helps Google to get my URL’s indexed as ‘https’ instead of ‘http’.
In playing with service workers, I set up a self-signed SSL certificate for my local development environment. I used instructions from debian.org. It was very simple, since I didn’t need the security involved with a real operating site. Creating the certs took a single command:
openssl req -new -x509 -days 365 -nodes -out /path/to/server/config/certs/sitename.pem -keyout /path/to/server/config/certs/sitename.key
You then just need to set things up in the server configuration (Apache in my case).
mod_ssl must be installed and enabled, which looks something like:
On my site, I’m using Apache’s ‘mod_deflate’ and ‘mod_filter’ to compress my compressible responses (mostly text), with a setup based on h5bp’s server config. I got my sites running over HTTPS recently, and today, when looking at my site performance with webpagetest.org, I noticed that my content wasn’t compressing. It was still working fine over HTTP. I noticed in h5bp’s comments that
<IfModule mod_filter.c> could be removed in Apache versions below 2.3.x. I removed it, and sure enough, compression was working again. I’m not sure why it’s different depending on what protocol I use. Perhaps Dreamhost has separate versions of Apache running for the two protocols. Or perhaps it’s just something different about the configuration in the virtual hosts. Regardless, it’s working now. I just hope this doesn’t cause problems whenever they move to Apache 2.4.
My sites are now HTTPS-enabled with LetsEncrypt. It was easy to set up with Dreamhost’s panel. It was just a few clicks and some waiting. This is the first time my own sites have been available over HTTPS. I’ve been wanting to do it for a while, but it was kind of costly until the free LetsEncrypt became available. This brings my sites in line with the “HTTPS Everywhere” movement. I’ve also been wanting to play with the new installable apps forming standard for making web apps installable almost like native apps.
I had written a post before about how I’m setting my security-related headers. I’ve now added an HTTPS related header in a similar manner:
Dreamhost now supports LetsEncrypt even with shared hosting. LetsEncrypt provides free SSL certificates. I’m going to have to try it out on my domains. My plan is to make my visitor targeted domains have https as the canonical protocol but still support http for older browsers.