‹ Back
Deploy360 27 November 2015

Let's Encrypt certificates tested in go6lab

Jan Žorž
By Jan ŽoržFormer Operational Engagement Programme Manager

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 go6.si, www.go6.si, mail.go6.si, 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 letsencrypt.org 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 https://acme-v01.api.letsencrypt.org/directory 

To obtain a cert using a “standalone” webserver (you may need to temporarily stop your exising webserver) forexample.com and www.example.com:

  ./letsencrypt-auto certonly -a standalone 
  -d example.com -d www.example.com 
  --server https://acme-v01.api.letsencrypt.org/directory --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 example.com -d www.example.com 
  --server https://acme-v01.api.letsencrypt.org/directory --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 example.com 
  --server https://acme-v01.api.letsencrypt.org/directory --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 go6.si --server https://acme-v01.api.letsencrypt.org/directory  
  /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 😉

go6.si secured

go6.si secured

After obtaining the initial certificate, I had to fix the content on the server https://go6.si/ 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 mx.go6lab.si. 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!

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...

Join the conversation with Internet Society members around the world