Archive: September 12th, 2014
Worried that @SlightlyLate sometimes doubts my commitment to Sparkle Motion.
Going for a beer on the beach.
Ian Paisley’s death reminds me of the graffiti scrawled under “Ulster Says No!”:
“The Man From Del Monte Says Yes! And He’s An Orangeman”
Want Forward Secrecy on Apache? You need to upgrade to version 2.4.
Want SPDY on Apache? You need to downgrade to version 2.2.
Publishing a somewhat epic walkthrough of the steps I took switching to https:
As promised at Indie Web Camp, here are the steps I took to make my site
Now, here’s the thing with any of these walkthroughs; they’re all very specific to host/server combo in question. My particular combination is:
- Hosting on a Digital Ocean virtual machine running Ubuntu 14.04 (typing
lsb_release -aon the server will tell you which version of Ubuntu you’re running).
- Running Apache 2.4.7 (typing
apache2 -vwill tell you which version of Apache is running).
If you’re using another flavour of Linux, or running Nginx, this walkthrough will probably not help you. You’ll also need admin access to the server. If you’re on shared hosting, you may well be screwed from the get-go.
To start with, you need to get your magic certificates from a Certificate Authority. So the first question is: who is a good Certificate Authority?
Choose a Certificate Authority
There is no such thing as a good Certificate Authority.
It’s a racket.
The best you can hope for is to deal with a Certificate Authority that doesn’t charge too much and doesn’t make the process as painful as applying a power drill to your teeth.
My pain was mitigated by my DNS provider, DNSimple. They have a one-clickish process for applying for a certificate. They charge $20 a year for a single hostname, which is not too bad. If that’s still too rich for your blood, you can look into navigating the interface at StartSSL. Good luck with that.
Until last week, DNSimple were using RapidSSL to issue those single-hostname certificates. RapidSSL still issues SHA-1 certificates by default, which is not good. But after a little prompting, DNSimple switched to Comodo for their single-hostname certificates, which means you can get yummy SHA256 encryption.
Make a private key and CSR
DNSimple can even take care of generating a private key and a Certificate Signing Request (the two chunks of encrypted gibberish you need to send to the Certificate Authority to get your certificate). Otherwise you’ll need to generate those for yourself. To do that,
ssh into your server and run this, swapping out
yourdomain_com for, you guessed it, your domain:
openssl req -new -newkey rsa:2048 -nodes -keyout /etc/ssl/private/yourdomain_com.key -out /etc/ssl/certs/yourdomain_com.csr
..and answer the probing questions that your nosy server will ask of you. You’ll then have two files:
You can then copy and paste the contents of those files when you’re applying for a certificate from your CA of choice. I can’t walk you through that process because, like I said, I managed to skip over it completely by having DNSimple do all the work.
I still had to put the private key on my server so I created the file:
And then I pasted the private key in there, hit
ctrl o and then hit enter to write out the file, followed by
ctrl x to close it.
(If some of these command line things don’t work for you, try prefixing them with
sudo, try again, and enter your password when prompted.)
See how this is getting more and more specific to my particular combination? Now I’m talking about installing a Comodo certificate (acquired through DNSimple) on Apache 2.4 on Ubuntu 14. If you’re using a Certificate Authority other than Comodo, the next step won’t mean much to you.
Install your certificate on your server
There’s some documentation on the Comodo site for this step. At this point, you should have received a zip file from Comodo with four files:
Open a text editor on your computer and create a new file by copying and pasting the contents of these files in this order:
- COMODORSADomainValidationSecureServerCA.crt followed by
- COMODORSAAddTrustCA.crt follwed by
On your server, create a new file by typing:
Paste in the combined contents of the text file from your computer. Hit
ctrl o (followed by enter) to write out the file and
ctrl x to close it.
That leaves one file, which is your actual certificate, yourdomain_com.crt
On your server, type:
Copy and paste the contents from the certificate file (yourdomain_com.crt) in there. Hit
ctrl o to write out the file and
ctrl x to close it.
Set up https on Apache
Remember, this is for Apache 2.4. Things will be subtly different on previous versions. For instance, on Apache 2.4, all the files in
/etc/apache2/sites-available must end with
.conf; that wasn’t the case with previous versions.
First things first. You need to enable the
ssl module for Apache. On your server, type:
(Again, if that doesn’t work straight away, try prefixing it with
Now restart Apache:
service apache2 restart
Your Apache server is now capable of serving over
https, but you still need to give it more details.
Go into the
sites-available directory by typing:
You can see all the files in this folder by typing
ls. I’m going to assume that you’ve got the server serving up just one site and that the details of that site are in the
000-default.conf file which serves up your site over port 80. You’ll want to copy any details you have set up in
000-default.conf over to
default-ssl, but with the difference that the port number is 443. The top of your
default-ssl file should look something like this:
<IfModule mod_ssl.c> <VirtualHost *:443> ServerAdmin firstname.lastname@example.org ServerName yourdomain.com ServerAlias www.yourdomain.com DocumentRoot /var/www
It might be that your
/var/www/html. That’s fine (as long as that’s where your website’s files are actually sitting).
Oh, I should have mentioned: the way that you can examine (and edit) that
default-ssl.conf is by typing:
Comment out these two lines by placing a
# at the start of each line:
#SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem #SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
Right under those lines, add these:
SSLCertificateFile /etc/ssl/certs/yourdomain_com.crt SSLCertificateKeyFile /etc/ssl/private/yourdomain_com.key
Now you’re pointing at your hard-earned certificate and your private key. You still need to point to that bundle file you created earlier.
Comment out this line by putting
# at the start of it:
Right underneath it type:
Now page down to near the end of the file by hitting
ctrl v. Right before the closing
/VirtualHost tag, add these lines:
SSLProtocol All -SSLv2 -SSLv3 SSLHonorCipherOrder On SSLCompression off SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'
That line beginning with
SSLCipherSuite needs to be all one line so watch out for line breaks if you’re copying and pasting. It’s quite an impressive bit of unintelligible gibberish, isn’t it?
Write out the
default-ssl.conf file by hitting
ctrl o, followed by enter, and exit this hellish text editor by hitting
Type this (you might need to
Do the Apache restart dance by typing:
service apache2 reload
You might see a message like “Could not reliably determine the server’s fully qualified domain name…” Don’t worry about it. If, on the other hand, you see an error message that Apache can’t restart, worry about it.
Open your website in a browser;
http://yourdomain.com — you should see no difference whatsoever. But now type
https://yourdomain.com (but, y’know, swapping out
yourdomain.com for your domain). Again, everything should look exactly the same but with one crucial difference: a shiny green lock in the corner of the URL bar indicating that the site is secure.
Redirect http to https
Once you’re happy with the way the
https version of your site is working, you can make it the default.
Before doing this, it’s worth making sure that you haven’t hardcoded any images, scripts, or other external files with
http:// URLs. If you’re pointing to third-party resources, most of them should also be available over
https. Don’t forget that you can use protocol-relative URLS:
//fontdeck.com/etc instead of
http requests for your site over to
https, you’ll need to edit the file that has your port 80 details. That’s probably
Open up that file:
The top of the file should look something like this:
<VirtualHost *:80> ServerAdmin email@example.com ServerName yourdomain.com ServerAlias www.yourdomain.com DocumentRoot /var/www
Again, the details might be slightly different for you: your
DocumentRoot might by
/var/www/html. Either way, add this line right after that
Redirect / https://yourdomain.com/
yourdomain.com for your domain.)
Do the keyboard shortcut mambo:
ctrl o, enter,
Do the Apache restart shuffle:
service apache2 restart
Now try visiting
http://yourdomain.com in a browser. You should be automatically redirected to
https://yourdomain.com …I really hope it works for you.
If you’ve made it this far and everything is working, well done! You have patience and fortitude in equal measure.
Go to ssllabs.com/ssltest and paste in your site’s domain name to see how well your site is doing in the security stakes. You’ll be given a grade, which will bring back all sorts of horrible memories of school tests.
If you’ve been given an A grade, there’s a way to level up to A+. You can enable HTTP Strict Transport Security. No, I don’t understand what it means either.
Go back to the command line on your server. You need to enable the
headers module for Apache. Again, you may need to
sudo this one:
service apache2 restart
Now dive back into that
ctrl v to page down to right before that closing
/VirtualHost tag. Add this line right after the gobbledygook you added previously:
Header always set Strict-Transport-Security "max-age=63072000"
You know the drill:
ctrl o, enter,
Command Apache to restart before Zod!
service apache2 restart
I hope that this walkthrough will be of some use to you. But the chances are that unless you are also using Comodo as your Certificate Authority and you’re running Apache 2.4 on Ubuntu 14, there will be some sort of difference between your setup and mine that could render all of this null and void.
If you run into problems, I probably can’t help you. I’m a complete n00b at this stuff, and if it hadn’t been for Tim’s hand-holding, I doubt I ever would’ve managed.
The https page on the Indie Web Camp is a handy resource that links off to other tutorials.
If you’re serving your site on Cloudfront, Josh’s walkthrough should be very helpful.
If you do make the switch from
https, please, please, please document each step along the way, and then publish it. There are plenty of articles and blog posts telling us why we need to switch on TLS, but not nearly enough articles and blog posts telling us how.
Saying “You should enable TLS—it’s easy!” can be damaging on two counts:
- The first part is redundant: we all know that we should be doing this.
- The second part just makes us feel bad. It’s like telling someone “You should play guitar—it’s easy!” Yeah, it’s easy if you already know how to play guitar.
If you’re a l33t server wizard and you care about this
https stuff—which you almost certainly do—I urge you to divert the time and energy you might consider putting into advocacy and instead put that time and effort into helping n00bs like me. If you can gather willing web developers in the same physical space—like Tim did at Indie Web Camp—I think you can achieve maximum knowledge dispersement. (Perhaps Google/Mozilla/Opera/Microsoft dev rels could sponsor TLS days in various cities and towns?)
The issue with
https is not that web developers don’t care or understand the importance of security. We care! We understand!
The issue with
https is that it’s really bloody hard.
But it’s worth persevering with it.
Indie Web Camp UK 2014
It was a problem because I’m no good at multi-tasking, and I focused all my energy on dConstruct (it more or less dominated my time for the past few months). That meant that something had to give and that something was the organising of Indie Web Camp.
The event itself went perfectly smoothly. All the basics were there: a great venue, a solid internet connection, and a plan of action. But because I was so focused on dConstruct, I didn’t put any time into trying to get the word out about Indie Web Camp. Worse, I didn’t put any time into making sure that a diverse range of people knew about the event.
So in the end, Indie Web Camp UK 2014 was quite a homogenous gathering. That’s a real shame, and it’s my fault. My excuse is that I was busy with all things dConstruct, but that’s just that; an excuse. On the plus side, the effort I put into making dConstruct a diverse event paid off, but I’ll know better in future than to try to organise two back-to-back events. I need to learn to delegate and ask for help.
But I don’t want to cast Indie Web Camp in a totally negative light (I just want to acknowledge how it could have been better). It was actually pretty great. As with previous events, it was remarkably productive. The format of one day of talks, followed by one day of hacking is spot on.
I’m looking forward to switching my website over to
https://but I’m not going to do it until the potential pain level drops.
Well, I’m afraid that potential pain level has not dropped. In fact, I can confirm that get TLS working is massive pain in the behind. But on the first day of Indie Web Camp, Tim Retout led a session on security and offered up his expertise for day two. I took full advantage of his generous offer.
With Tim’s help, I was able to get adactio.com all set. If I hadn’t had his help, it probably would’ve taken me days …or I simply would’ve given up. I took plenty of notes so I could document the process. I’ll write it up soon, but alas, it will only be useful to people with the same kind of hosting set up as I have.
By the end of Indie Web Camp, thanks to Tim’s patient assistance, quite a few people has switched on TSL for their sites. The https page on the Indie Web Camp wiki is turning into quite a handy resource.