So, letsecnrypt has gone public beta, and I decided to give it a try. If you don't know what's letsencrypt, let's say it makes it easier and gratis to have someone else tell your public that your content is yours. Doesn't make sense to you. It doesn't make sense to me either. That is, I don't believe this as a good security model.

You will notice there is a tag intermediate in this post. This means that I assume the reader knows what a TLS X.509 certificate is, what letsencrypt is all about, but would like to know one possible way to use it. So, I would love to tell a novice what a certificate is, why I don't believe this is a good security model (others would disagree), but that's not the time when I will do it. Maybe next time.

Once again, as a disclaimer, I don't like the security model of Certificate Authorities, and I would love to see Mozilla Foundation challenging it. Unfortunately, that's not what letscrypt does. It challenges their business model, their prices, the way certificates are issued, but not the certificate security and trust model. I will leave this discussion for another time. Meanwhile, you can read about it somewhere else.

But let's get to business. The letsencrypt client is supposed to help you by writing your Apache httpd configuration files. Sorry, but I won't run a beta software on my production server. And I would suggest you don't do it either. As you may notice, it's Public Beta. The project is aware they need to improve the client, and testing and using it is a good way to do it, but don't try it on a production server. However, you may want to get a certificate for your production server, and here is one way to do it.

So, letsencrypt is packaged for Debian, in the experimental suite. And you don't want to install experimental packages on your production server, do you? So, install it on another host, but one that could be reached through the Internet somehow.

The client wants to run as root too. That's bad, right, but it's possible to run it as any other user, no problem. The only real thing it needs to be able to do is serve some files over HTTP port 80 under your domain. And it should not need to be root to do that. You may need to give it a hand. We could claim it's already a stretch that we should give this client the power to serve files under our domain, and unencrypted. But well, you already allow it to create a certificate that will tell your users they should trust it, so a temporary access to your content is no problem. By the way, you could limit it to serving only files under the /.well-known/ location.

OK, so how did I do it? My machine has a public IPv6 address and I was doing it for a new subdomain I had just added to my DNS setup. My home server was already running Apache httpd, and I added to my user access to write files to the DocumentRoot of the web server, /var/www/, for example. My surprise? The letsencrypt server expects your web server to be accessible over IPv4! That's a bummer! OK, I have a public IPv4 available, lucky me.

OK, so here you have some options. If your home Internet access gives you IPv4, you can do some DNAT from your home router. But sometimes, your ISP does not allow incoming access to port 80. Mine doesn't. So, lucky me again, I have a public IPv4 address available on my production server. And I know how to configure Apache httpd to work as a reverse proxy. If you don't, you can read the documentation, or just add a ProxyPass / http://[2001:db8::cafe]/ for your VirtualHost.

So, for a working domain, this means a temporary downtime. Try it on a new subdomain if you are able to, in order to get some confidence, and try to minimize downtime. Or just proxy requests for the /.well-known/ Location, or try to use the manual option of letsencrypt (more below).

OK. So after that, you run letsencrypt with a lot of options. As mentioned, no need to be root, even though the client will tell you it needs to run as root.

letsencrypt -t --config-dir ~/letsencrypt/ --work-dir ~/letsencrypt/ --logs-dir ~/letsencrypt/ certonly --webroot --webroot-path /var/www/html/ -d subdomain.example.com

So, -t means it won't use the curses interface, but a simple text interface. The dir options prevent the client from trying to access directories that would require other permissions, like /etc/, /var/, etc. certonly means it will only generate the certificates, but not change your web server configuration. The webroot options specify the method which is going to use to verify you have access to your domain. It means it will create files under that path in order to serve them over HTTP port 80 for your domain. And -d options specify the domain for which you want to generate your certificate.

Some notes here. It will ask for your email address, which it will use to create an account. Some files will be saved under your working dir, in this case, ~/letsencrypt/, that you should keep in order to revoke your certificate, for example. It might fail because it couldn't create some directory, but it's just a bug in the software, and running it again should fix that (it has created the directory but aborted, or something like that, I don't recall exactly). It will also ask you to accept the Subscriber Agreement (more on that below), you should go to the link, read it, and only go ahead if you find the agreement acceptable. Think about the circumstances, maybe it's acceptable for some testing or your special case. If everything has gone right, the certificate, full chain and private key will be under your working directory.

Now, you just need to push the full chain and private key to your production server in a safe way (with confidentiality because of the private key, and non-tempering), then secure those files (only the web server should be able to read the private key, for example), and configure your web server to use them. I used Apache httpd directives SSLCertificateFile and SSLCertificateKeyFile. If you want other details, go check the documentation. The nice thing is you are not restricted to Apache httpd. Not even to serve the verification files.

Now, for the manual approach. I tried it, but I didn't got exactly through it. So I can't give many details. Just read the manpage and try the --manual option instead of --webroot, then follow the instructions the client gives you. If you are lucky, it might just work for you.

So, what do I take from this experience? Well, the client is Beta, there are many small bugs, but it works in the end. It's a pity that the only instruction I found on how to contribute was to send a "PR" (as in Github pull request). I don't have and don't intend on having a Github account, so there is that. The webroot process only requires access to serving some files for your domain. That is doable without root, but with some downtime, using some temporary proxying. So, yeah, don't forget to disable the proxying after you are done getting your certificate. It requires IPv4, which is very sad. And, last but not least, you have to agree to idemnify this Internet Security Research Group under some circumstances.

The agreement is not the end of the world. But we should not need to accept such an agreement and make our email address available to any third-party, no matter how much you trust them, just so your friend may choose to trust you. So, please, go ahead and read the texts mentioned above about other trust models we should be using instead.

Meanwhile, if you have an application that requires you to use this model, or you have users that can't or are not able somehow to trust your certificate some other way, there is this temporary hack called letsencrypt you can use. But we should not stop pushing for this to be really temporary and fix the real issues that are not solved by the certificate trust model or where TLS confidentiality is not necessary or sufficient.