You may well know that Let's Encrypt is a not-for-profit organization that provides SSL certificates for free. You may also know there is a huge number of "clients" - small software packages that you need to install on your server to start using Let's Encrypt. There is relatively little information about how it actually works.
I think it's important to bear in mind that Let's Encrypt is funded and managed by Internet Security Research Group (ISRG), aka "abetterinternet.com . Its funding comes from many sponsors but 40% is provided by "platinum" and "gold" level (Mozilla, CISCO, OVHcloud, EFF, Chrome, Facebook, and Internet Society, IdenTrust, and Ford Foundation).
The Let's Encrypt's initial goal was to automate SSL management and provide it for free as a vehicle to push for 100% web encryption. I believe that the availability of free certificates was a significant aspect when Google, Apple, Microsoft, ... started discouraging users from visiting insecure web sites (i.e., web sites without HTTPS).
Let's Encrypt does a great job when you have a few websites or a couple of administrators who can build in-house tools to ensure that all is running smoothly and resolve failures. I have summarised some of the issues to consider before you start using Let's Encrypt in a previous blog post.
Let's Encrypt and Automation
Let's Encrypt has developed its standard defining the API and operational concepts. They called it Automatic Certificate Management Environment (ACME). They built the certificate authority using the initial version but they also created a working group to develop an open standard. This has been finalized (currently RFC-8555 in the "proposed standard" state) in March 2019. Because it has introduced some breaking changes, Let's Encrypt started calling it ACMEv2, possibly because they implemented a new API compliant with the RFC-8555 standard and named it "acme-v02". Although it's simply "ACME" for the rest of the world.
The automation is based on a RESTful API that requires users to create an account identified by a public key. This key is then used to protect all messages sent from clients to an ACME server (= Let's Encrypt).
The protocol is defined around the following terms:
- account - an asymmetric key that identifies a client. It is also used to enforce some of the limits on the API usage, so-called "rate limits". Some of the rate limits are also measured per registered domain or the IP address of the client.
- order - this is an actual request for a new certificate.
- authorization / authz - it's an object with the validation status of an order. Each order has one validation object.
- challenge - the challenge is an object that defines a method and parameters to complete authorizations. Each validation has several challenges - one for each validation method (Let's Encrypt offers HTTP, DNS, and TLS-ALPN).
- certificate - it's an "address" from which you can eventually download a new certificate. This address is pretty much permanent.
The picture below shows the three basic steps of the ACME protocol. A client (e.g., acme.sh, certbot) will initiate an order and obtain back authentication data – step 1. At this point, the only specific information sent by the client is a list of domain names (i.e., no CSR).
This authentication is absolutely crucial as it ensures that only you can request certificates for your servers. In other words, via the authentication, you prove the control over your internet domain name and servers. You can prove this control either by adding the authorization data to your web server (so it can be accessed with the HTTP protocol by the Let's Encrypt service) or by adding the authorization data to your DNS records.
Figure: ACME Issuance Protocol
Step 2 is the actual validation of your domain control. It is also the most difficult step as you need to integrate the certificate renewal with either your web server or your DNS management.
Note: I’m sure you noticed that in the diagram, the data for Step 2 magically appear where it is expected. As no magic, it has to be a sophisticated technology.
Let’s Encrypt will try to collect the authorization data it provides in step 1 using one of the available methods. Once the authorization is completed, Letsencrypt will store a completed autherization for 7 days. This means you have 7 days to request a certificate for the given domain names without a need to repeat the authentication for the domains you specified in step 1.
As you can see all the client provided to the ACME server (i.e., Lets' Encrypt) is its account ID (registered with the server) and a list of domain that is sent in step 1. The key for a new certificate or the CSR hasn't been needed yet. While it simplifies the API, it also gives us huge flexibility in how we can implement the final step - the actual certificate request.What we need for Step 3 is:
- the address for the "finalize" step (it looks like api.letsencrypt.org/acme/finalize/51135296/308109706)
- the account key
- and of course, the domain names that should be in the certificate.
This final step is a simple API request - the client sends a CSR and downloads the new certificate. This means that while the validation has to have access to your DND or web server, the Step 3 can be done from anywhere on the internet.
KeyChest and Let's Encrypt
This flexibility of the ACME protocol is something that KeyChest is exploiting to provide a managed service for companies or those of you who need to manage more than a handful of certificates.
- KeyChest Amp - our open source proxy was the first step that allows collecting logs from all your clients in one place. You can use it as a data source for your own audit systems. KeyChest will add a new web dashboard in the next couple of weeks and you will be able to see the last activity of clients to detect failures and rate limit information. You can download it from GitLab - https://gitlab.com/keychest/keychestamp/wikis
- KeyChest AmpX - is another proxy that fully uses the flexibility of the ACME protocol. It creates its own Let's Encrypt accounts to manage certificate renewals while you still keep control over the operations. But it also unifies Let's Encrypt with long-validity certificates. It can decide whether to request a new certificate from Let's Encrypt DigiCert, Comodo, GeoTrust, etc.