Review of getting free HTTPS with “Let’s Encrypt”

I was quite intrigued when I first read about Let’s Encrypt, that they wanted to make https available for everybody. It sounded too good to be true.

The normal and proven process

I have been through the process of getting a certificate for a domain many times and it is every time the same process.

1. Generate a private key OR reuse old key from last time (doesn’t matter)
2. Generate a CSR (Certificate Signing Request)
   This is where you specify such things as Company name and domains you want to secure.
3. You go to a website, often old and bad ux, and then try to buy the certificate package you want.
   RapidSSL made this easier to choose because they only have 2 packages.
4. Find your credit card and pay
5. Verify your phone number with an automated call
6. Choose and email, like postmaster@YOURDOMAIN.com where you will receive a confirmation email.
7. Find that email! If you are doing this for a customer, you are in for a nightmare, they often doesn’t have access to that mailbox.
8. You click on that email and your Certificate will be emailed to you.

This process, if you know what you are doing, takes about 30 minutes. However if it is your first time, you have to know how to first get the OpenSSL command line tool. Once you got that you have to figure out how to get the correct arguments to OpenSSL, and that is by no means easy!

And on top of it all, you have to pay $40 for a wildcard certificate. So no wonder why a lot of people go through that hassle if they just have a small site.

So how does Let’s Encrypt work?

Does it make you go through the same treadmill and do all those things?

Let’s encrypt knew the pain and their primary solution was to make some kind of “plugin” infrastructure. Right now there is two plugins, one for Apache and one for Nginx.

The idea is that the plugin will do everything you need to do. There is also a “certonly” option which as indicated gives you the certificates directly. That is what most of us that have tried the previous method want! But Let’s Encrypt explain this step poorly.

First Let’s Encrypt expects you to be able to control the server you want to request certificates on behalf of!

That is both good and bad since you escape the phone and email verification, but in a company, you may not have that kind of access.

When you run “certonly”, LE (short for Let’s Encrypt) expects to be able to visit the domain your are requesting and see a special string. So if you run

$ letsencrypt certonly -d kevinsimper.dk -d www.kevinsimper.dk

LE will automatically start a webserver that binds to port 80 and 443 and then expects to visit:

kevinsimper.dk/.well-known/acme-challenge/QE13vdqwqbk1iru7IT8e9rVlJxxxx-q4U72wr2fqxA

containing:

E13vdqwqbk1iru7IxxxrVlJUrJ0H-q4U72wr2fqxA.5rFKm1NJ0Y43AGmNxxxxx_QCq9KQ4RRB-BH_IQ4Ks

If you are not allowed to run commands directly on the server, or it is load-balanced, so you don’t know which server LE will hit, then you can do it manually.

$ letsencrypt certonly --manual -d kevinsimper.dk -d www.kevinsimper.dk

That will print out information on how to start a Python Webserver and serve the needed HTML for verification. Then you can take that information and make the same in your Node.js or Ruby application.

Take notice that the certificate that is outputted is only valid for 90 days, so you will have to do the step again soon!

LE do have a option called “renew” that you can run automatically every day and then it will automatically renew close to expiring certificates, but that is not for the “certonly” command.

Conclusion

Let’s Encrypt is super cool and it is amazing that they have taken something that cost money and made it free. It is extremely liberating since $40 dollars may not be much for us in Europe or North America, but in Africa and Asia that is a small fortune, so now that can have the same kind of encryption.

It is easy if you have a simple setup with Apache or only have a single webserver. If you, however, have a workflow with a continuous deployment workflow that goes through git, it is a little bit more complicated since it has to be done synchronous and not like the old way that worked fine asynchronous.

Also that you have to renew every 90 days means that you have to have some kind of automated certificate workflow, because doing this every 80 days both get tired and easily forgotten.

Good

• Easy
• Free
• Good for single server

Bad

• Difficult in multi/load-balanced setup
• Sync and not async like old method
• Renewal every 90 days

If you liked this article, hit that ❤ button. You may also like the article that I wrote about why you should not use git for deployment.

Why you should not use git for deployment

Kevin Simper, @kevinsimper