“Greetings from Let’s Encrypt, mail@brokkr.net.”
Greetings to you too. It’s been quite a wait so I guess a bit of formality is in order. Now, can we please stop saying “Let’s” and just encrypt already?
I signed up for the beta a couple of weeks ago and got a pretty quick invitation to paticipate. Then I signed up again because I didn’t think to explicitly include subdomains in my signup. Then I waited another week and here we are. Look up at your address bar and behold my padlock of privacy.
For those not in the know: Let’s Encrypt is an initiative by Mozilla, Cisco, EFF and others to make using https on your web server more accessible and so more widespread. Barriers are supposedly cost and ease of installation for the required certificates so Let’s Encrypt certficates are free and you get them (and start using them) simply by running a Python script.
This is not going to be a howto, just a note on how well it worked for me and some thoughts on how successful it is in terms of it’s mission.
First of all, it is well and truly free, so there’s that, and unlike the only other free certificate solution that I know of – StartSSL – you get more than one subdomain. Not wildcard domains (as in *.mydomain.com) but I listed some five subdomains in addition to the main one and the certificate is now valid for all of them.
You start off gettting the script by cloning the project’s Github repo. At this point I thought to myself: How on Earth is this more accessible than setting up an account with StartSSL? Theirs is a pure webbased authentification which I suspect most people techincally minded enough to have thier own website can deal with. Here the bar of entry starts with knowing git, or at least feeling comfortable copy-pasting git commands into your terminal. At least for the beta – I suspect that might change when they go public but surely whatever they plan to do should get tested too, right?
Once you have the script, you run it telling it a) what domains you have want to get certificates for and b) if the script should try replacing your current, supposedly unencrypted, web server setup with an encrypted one, using your new certificate.
I opted not to let the script change my server setup. I suppose this feature is a large part of the attempt to make certificates easier to use, so this is not a very complete test. Instead I told the script to just download the files and leave it to me to alter my setup. This was due to a number of factors:
- Apache has been the main development focus, nginx seems to come second. The current nginx support is labelled experimental. I use nginx.
- I already have an SSL setup for another of my servers, using certificates from StartSSL, so I kinda know what needs to be included to get it to work.
- My nginx configuration is spread out over a number of files that I have groomed by hand. Even with backups in place I fear the effect of an automatized makeover. This is not to say that those handgroomed configurations are any good but they’re mine and at least I know my way around them. I don’t trust any script not to mess that up something frightful.
The download itself went smoothly. Now, I don’t know how Let’s Encrypt checks that I’m entitled to the certificates I’m asking for. Some sort of reverse DNS check on the machine the script is running on? Maybe? I take it that whatever the magic, it’s legit based simply on the trust I have in their backers. The script turned unresponsive for periods of one to two minutes but when it came back to life, I had my certificates in a directory under /etc/letsencrypt.
Was the procedure easier than setting up with StartSSL? Yes and no. StartSSL like many other CAs requires you to demonstrate that you control postmaster@yourdomain.com. If you already have a working mail setup for your domain that’s the easiest thing in the world. When I applied for my first certificate I hadn’t got to that point so it took me days to get it. For people on shared hosts with email provided by the host but no means to run arbitrary scripts on the server, StartSSL is still the better, actually the only, proposition. For people with virtual hosts who haven’t gotten round to email yet – or who prefer sticking with their webmail provider – Let’s Encrypt’s model should be easier. But making something more accessible to people with their own virtual host is hardly a great levelling, democratic move. Those people usually aren’t the great unwashed.
But then again I didn’t actually make use of that central ‘let us deal with your web server configuration’ feature. I can absolutely understand if people don’t bother with encryption based solely on not wanting to learn the intricacies of web server configuration. If one command can get the certificates and put them to use, then that’s no mean feat. A one-step upgrade. Plug and play encryption. I would have to try setting up a pure test server (as in an nginx server block not as in a physical server) to try and see what it can do.
Now I did spend some time troubleshooting the downloaded certificates once I had reconfigured nginx to make use of them because they resulted in all sorts of nose wrinkling on the part of browsers. It was only when I discovered that the CA was labelled “Happy Hacker FAKE CA” and googled that, that I found out that I was missing a vital parameter for the script. If the script produces junk without it why isn’t it simply the default setting? Or at least warn you that you now have shit on your hands; don’t expect good things if you run round pumping fists?
Which brings me to my next worry about this project. The instructions that they mail you aren’t very good. They are definitely not newbie-friendly even if you discount the Github bit. True, newbies aren’t exactly targeted by the beta program but when are they going to test their documentation then? And even if I know what I’m doing, the instructions falls somewhere in between allautomated, idiotproof ‘fire and forget’ and ‘be sure to include this parameter when you run it’. The reason I had missed the ‘server’ parameter was that there was simply no explanation of what it meant.
Now, I’ve applied to be part of a beta. I know that if things don’t work in a beta, what you do is you tell the developers in whatever manner the project dictates. That way they don’t have to cross the web reading blog posts. But here’s the weird part, I haven’t been given any instructions on where I can report back to them. Yes, there is a support forum but a support forum is not a bug tracker. There’s Github but they aren’t exactly pointing people in that direction. Maybe the beta is more about testing their systems to see if they crumble under the load.
At any rate, I finally got the proper certificates, all properly signed by “Let’s Encrypt” and all. And they obviously work as well as any do. Let’s Encrypt certificates are currently valid only for 90 days (and they have indicated that this will only get shorter) but when renewing is something you could leave to a shell script and a cron job, that is really not an issue.
The long and short of it? Once they leave beta, I expect that I will ditch my StartSSL certificates and go all in on this. I do doubt however that it will mean that everybody and their dog will start using HTTPS. Unless somebody else does some serious work on the frontend.
