Deploy360 Domain Name System Security Extensions (DNSSEC) Transport Layer Security (TLS)

Let's Encrypt certificates tested in go6lab

letsencryptSince the announcement of the Let’s Encrypt project, we’ve been enthusiastic about the idea of having an open and transparent Certification Authority (CA) that could show other CA’s that it’s possible to run a certificates business and keep it free for everyone!

So, after the Closed Beta programme was announced, we managed to get involved and secure our web servers with their certificates. Firstly, we had a look at their ACME client that’s needed if you want one of their certificates, as the only way to request a domain certificate is through interaction with a back-end API.

Firstly you need to know that a separate certificate is required for every domain and subdomain you want to secure. For example you need separate certificates for,,, etc…

When you install the ACME tool on your system, you have a few options – or you can use Apache mode that configures your Apache web server automatically, talks to the Let’s Encrypt system to obtain an “auth token”, and publishes it on your website. It then tells the remote system to check for that file and whether it has the right content, and if that check goes through, the system will transfer the signed certificates and install them on your system. In case you are not running Apache (and for now just on Debian systems), you have other options such as Standalone mode that does a similar thing. However, since it sets up its own web server on port 80 in order to authenticate, you need to shut down your primary web server for a period of time which is not entirely ideal.

We chose Webroot mode that does the same authentication as the other methods, except that you need tell the ACME client where your webroot directory is. Then when you request a certificate for a domain, it obtains the authentication file from the remote system and puts it in your web server root directory so the system can access it and verify that you really control the server for that domain.

Here’s a quick how-to from their beta announcements post:

If you’re running Apache on a recent Debian-based OS, you can try the Apache plugin, which automates both obtaining and installing certs:

  ./letsencrypt-auto --apache --server 

To obtain a cert using a “standalone” webserver (you may need to temporarily stop your exising webserver) and

  ./letsencrypt-auto certonly -a standalone 
  -d -d 
  --server --agree-dev-preview

To obtain a cert using the “webroot” plugin, which can work with the webroot of any webserver software:

  ./letsencrypt-auto certonly -a webroot --webroot-path /var/www/example 
  -d -d 
  --server --agree-dev-preview

Note: Currently the webroot plugin can only obtain certs for several domains simultaneously if they share a webroot.

To receive instructions for the (fairly complex) process of obtaining a cert from Let’s Encrypt by manually providing proof you control a domain:

  ./letsencrypt-auto certonly -a manual -d 
  --server --agree-dev-preview

So, after experimenting a bit with the whole thing, the command that worked for us was:

  ./letsencrypt-auto certonly --debug --webroot --webroot-path /var/www/html 
  -d --server  
  /etc/init.d/httpd restart

Why is –debug there? Because their client does not (sort of) support Python 2.6 anymore. This is the default on CentOS 6.x systems and upgrading it creates a high probability that you’ll break many things on your server. So if you end up having to deal with Python 2.6, the letsencrypt client will not do anything other than try to update the dependancies on your system and exit with a message that Python 2.6 is not supported. If you really mean it, you should add that –debug switch to the script. Well okay, so be it, debug it is 😉 secured secured

After obtaining the initial certificate, I had to fix the content on the server as some pictures were referenced with http:// at the beginning of the URL and the verification system began complaining that some content was not secured. Well, now it is and the lock on the left of URL glows green.

So, the first step went quite smoothly and was not that hard at all, but with the understanding that the certificate was only valid for 90 days, we wanted to make the renewal automatic. However, how can we make it automatic if the client requires dialogs for entering email during the initial procedure?

Well, we tried to run it again with same parameters, but it started asking questions and after some research we found out that adding –renew to the script automagically skips all the questions and becomes perfect for automation. So, now we have our cron system ready to renew that certificate on the first day of every month at 00:55, fingers crossed 😉

During the process we encountered some small issues and questions that we’re still awaiting an answer to. One of the issues was that you can’t currently obtain a certificate for a server on an IPv6-only network as Let’s Encrypt seems to have some issues with the data centers where they have their system installed, although they say they’re working to rectify this.

Let’s Encrypt uses DNSSEC validating resolvers (unbound) and this ensures a quite high level of protection during the authentication process for DNSSEC signed zones. For non-signed zones, they are querying geographically sparse DNS resolvers and comparing the results – if results are not consistent, an attack is happening and validation fails. They also plan to rotate the resolving servers, so somebody could not build a sparse enough attack to poison all their DNS servers.

What we’d also hope is that Let’s Encrypt will put a big sign on on every corner of their webpage saying “Please sign your domain with DNSSEC and make the verification for certificate delivery more resilient to attacks, and by the way, your domain and services would be much more secure this way…” in order to encourage people to deploy DNSSEC. This is in the interests of everyone, and we already showed how deploying DNSSEC, signing domains and doing a KSK rollover is not difficult.

Our Conclusion: Let’s Encrypt is a great idea for running a CA that issues free certificates, and their certificate just works. The tools and client do need to a bit of polishing and made a bit more automatic so that every sysadmin will be able to install it with apt-get/yum, run it, and then state which domain they wish to secure.

Our next test will be to obtain a Let’s Encrypt certificate for our mail server sitting on Theoretically it should work, but let’s see next week when that subdomain will be whitelisted on the Let’s Encrypt system.

Important notice: The Let’s Encrypt Open Beta program starts up on 3 December 2015 and then more domains will be whitelisted in a much shorter time. Don’t be afraid to try it out!