Let’s Encrypt is a free, automated, and open certificate by the nonprofit Internet Security Research Group (ISRG).
In May of 2013, SRG was founded to serve as a home for public-benefit digital infrastructure projects, the first of which was the Let’s Encrypt certificate authority. ISRG’s founding directors were Josh Aas and Eric Rescorla. Mozilla, the Electronic Frontier Foundation, the University of Michigan, Cisco, and Akamai were the group’s founding sponsors and partners.
The key principles behind Let’s Encrypt are:
- Free: Anyone who has owned a website name can use Let’s Encrypt to obtain a trusted certificate at free cost.
- Automatic: Web server can interact through software running on server with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
- Secure: Let’s Encrypt serves as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
- Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to check.
- Open: The automatic issuance and renewal protocol will be published as an open standard that others can accept.
- Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community.
The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server, it automatically obtain a browser-trusted certificate, without any human intervention. This is accomplished by running a certificate management agent on the web server.
To understand how the technology works, let’s walk through the process of setting up ex. http://sineweb.in/ with a certificate management agent that supports Let’s Encrypt.
There are two steps to this process. First, the agent proves to the CA that the web server controls a website. Then, the agent can request, renew, and revoke certificates for the website.
Website Validation
Let’s Encrypt identifies the server administrator by public key. The first time the agent software interacts with Let’s Encrypt, it generates a key pair and proves to the Let’s Encrypt CA that the server controls one or more websites. This is similar to the traditional CA process of creating an account and adding websites to that account.
To start the process, the agent asks the Let’s Encrypt CA what it needs to do in order to prove that it controls ex.sineweb.in. The Let’s Encrypt CA will look at the website name being requested and issue one or more sets of challenges. These are different ways that the agent can prove control of the website. For example,
The CA might give the agent a choice of either:
- Provisioning a DNS record under ex.sineweb.in, or
- Provisioning an HTTP resource under a well-known URI on ex. http:// sineweb.in /
- Along with the challenges, the Let’s Encrypt CA agent must sign with its private key pair to prove that it controls the key pair.
The agent software completes one of the provided sets of challenges. Let’s say it is able to accomplish the second task above:
it creates a file on a specified path on the ex. http://sineweb.in website. The agent also signs the provided with its private key. Once the agent has completed these steps, it notifies the CA that it’s ready to complete validation.
Then, it’s the CA’s work to check that the challenges have been satisfied. The CA verifies the signature, and it attempts to download the file from the web server and make sure it has the expected content.
If the signature is valid, and the challenges check out, then the agent identified by the public key is authorized to do certificate management for the website ex.sineweb.in. We call the key pair the agent used an “authorized key pair” for ex.sineweb.in.
Certificate Issuance and Revocation
Once the agent has an authorized key pair, requesting, renewing, and revoking certificates is simple—just send certificate management messages and sign them with the authorized key pair.
To obtain a certificate for the website, the agent constructs a PKCS#10 Certificate Signing Request that asks the Let’s Encrypt CA to issue a certificate for ex.sineweb.in with a specified public key. As usual, the CSR includes a signature by the private key corresponding to the public key in the CSR. The agent also signs the whole CSR with the authorized key for ex.sineweb.in so that the Let’s Encrypt CA knows it’s authorized.
When the Let’s Encrypt CA receives the request, it verifies both signatures. If everything looks good, it issues a certificate for ex. sineweb.in with the public key from the CSR and returns it to the agent.
Revocation works in a similar manner. The agent signs a revocation request with the key pair authorized for ex. sineweb.in, and the Let’s Encrypt CA verifies that the request is authorized. If so, it publishes revocation information into the normal revocation channels (i.e. OCSP), so that relying parties such as browsers can know that they shouldn’t accept the revoked certificate.
***
