Letsencrypt: challenging challenges

On December 3rd 2015 the Letsencrypt project went to public beta and this is a good thing! Having more and more websites running on good and valid SSL certificates for their HTTPS is a good thing, especially because Letsencrypt takes care of renewing the certs every now and then. But there are still some issues with Letsencrypt. Some people criticize the Python client needing root priviledges and such. Others complain that Letsencrypt currently only supports webservers.

Well, I think for a public beta this is what we could have expected from the start: the Letsencrypt project focussed on a reference implementation and there are already other implementations being available. But one thing seems to a problem within the design of how Letsencrypt works as it uses a challenge response method to verify that the requesting user is controlling the domain for which the certificate shall be issued. This might work well in simple deployments, but what about a little more complex setups like multiple virtual machines and different protocols involved.

For example: you’re using domain A for your communication like user@example.net for your mail, XMPP and SIP. Your mailserver runs on one virtual machine, whereas the webserver is running on a different virtual machine. The same for XMPP and SIP: a seperate VM as well. 

Usually the Letsencrypt approach would be that you configure your webserver (by configure /.well-known/acme-challenge/* location or use a standalone server on port 443) to handle the challenge response requests. This would give you a SSL cert for your webserver example.net. Of course you could copy this cert to your mail-, XMPP- and SIP-server, but then again you have to do this everytime the SSL cert gets renewed.

Another challenge is of course that you are not only have one or two domains, but a bunch of domains. In my case I host approximately >60 domains. Basically the mail for all domains are handled by my mailserver running on its own virtual machine. The webserver is located on a different VM. For some domains I offer XMPP accounts on a third VM.

What is the best way to solve this problem? Moving everything to just one virtual machine? Naaah! Writing some scripts to copy the certs as needed? Not very smart as well. Using a network share for the certs between all VMs? Hmmm… would that work?

And what about TLSA entries of your DNSSEC setup? When a SSL cert is renewed than the fingerprint might need an update in your DNS zone – for several protocols like mail, XMPP, SIP and HTTPS. At least the Bash implementation of Letsencrypt offers a “hook” which is called after the SSL cert has been issued.

What are you ways to deal with this kind of handling the ACME protocol challenges and multi-domain, multi-VM setup?

Uncategorized

6 thoughts on “Letsencrypt: challenging challenges

  1. same here
    Hah! Was looking into this myself just now. As mentioned by https://blog.josefsson.org/2015/12/17/lets-encrypt-clients/ there is letsencrypt-nosudo, which is an improvement, but designed to pause while you carry out some operations manually. Shouldn’t be too hard to make it do the signing itself (perhaps via sudo); and connect to VMs via SSH to do the necessary stuff there? (e.g. create ~/public_html/.well-known/acme-challenge/index.txt, containing the challenge response and may an .htaccess rewrite rule to it.)

    1. As I said: there are several

      As I said: there are several possible ways of which copying the keys is only one of them. I think that copying files are maybe one of the easiest but not the smartest ways.

  2. ACME supports HTTP Redirects
    Let’s Encrypt and ACME protocol is perfectly fine with HTTP Redirects. One issue you might have is that you need to install a webserver on hosts that don’t usually serve webpages, like a mail or XMPP host, but it’s then perfectly fine to configure these webservers to redirect /.well-known/acme-challenge/ requests to a specific location on a central server. There, you set up the ACME client which handles the challenges, gets the certificate, publishes it on a known HTTP location (or in LDAP, or whatever your choice is), and your other hosts periodically check that known location for updates. Remember that certificates are issued with a long valid time (90 days is long, trust me), so checking the central location every couple of weeks after making sure all is working fine is OK.

  3. mx records
    For the mail case, I would probably set the MX for all domains to just one domain, and only worry about a certificate for the MX domain. Actually I do this, but with far fewer than 60 domains.

    1. Hmmm, yes, the is maybe a

      Hmmm, yes, the is maybe a good idea to make it a little more simple to handle, at least for maildomains. Basically this is already the case for most domains of mine, but I have to check all domains again, of course. Thanks!

Comments are closed.