Let's Encrypt - It's happening

Using Lets Encrypt

Today, the Let’s Encrypt team announced beta program launch.

This is a huge step forward for the Internet in general. We are living in a world where a Symantec account manager actually believes a business should sink $2,490 into a certificate that is identical in security level (no, I don’t count “identity” if end users can’t tell the difference) to a $9 alternative.

Costs aside, there have been a lot of excuses used as to why websites aren’t secure. The performance complaint is long debunked, and the maintenance issue is - one Let’s Encrypt also sets out to resolve.

###Clients

Let’s Encrypt introduces the notion of a client product, as opposed to utilising a website. The default client aims to be as “hands off” as possible. For the majority of the Internet - that’s a net gain.

For anyone with any sysadmin experience however, you’ll be extremely cautious of a tool that automatically edits server config files. Or you may just be an nginx user, who found the official client is known to break nginx and thus disables support by default.

For this reason, I have a strong preference for Unixcharles acme-client. This also avoids sudo, although I note this can now be acheived in the official client.

###Running it

Unixcharles stresses that his product is a gem, designed for use as part of a larger project, rather than a standalone client. It happens however, that such a project can be this quite simple Ruby script I’ve written to use said gem.

UPDATE: The acme-client gem has had a significant update. the below gist has been rewritten to compensate.

gist technion/f299433f42dd3ae5dd96

Now you’ve still got a hurdle to overcome. In order for nginx to serve out the right certificate chain, you’ll need to bundle the intermediary. So you should wget that from The official Certificates Download page.

This small script will need to be sudo’ed, right after running the above. Unfortunately there’s no getting out of that to restart nginx, but you can see that it’s much more easily audited and checked.

{% highlight bash %} cat ssl_cert.pem lets-encrypt-x1-cross-signed.pem > /etc/nginx/pki/certificate.pem cp ssl_private_key.pem /etc/nginx/pki/key.pem nginx -t && systemctl restart nginx

{% endhighlight %}

##Why yes, it is running in production

This is definitely a beta trial. That said, I have my ERLVulnscan Tool running a certificate generated by the above script. It looks clean on SSL Labs’ test and will be updated via cron regularly.

Why isn’t this particular blog using it? Because it’s beta.

##Update

Turns out, this blog now actually is running this script in production. There’s still a big TODO about how I might manage HPKP with only a 90 day lifetime on keys that instantly replace themselves, as opposed to letting me pre-generate a CSR.

Oh look, a phone call from a Comodo representative…

##With subjectAltNames !

The gist has had a significant update, to now include alt names. This is necessary for a cert to cover DOMAIN and www.DOMAIN, but you can modify one line and verify as many unrelated domains as needed.