How Let’s Encrypt Works

Domain Validation

Let's Encrypt uses a public key to identify the server administrator. The agent software generates a fresh key pair (private and public) and verifies to the Let's Encrypt CA that the server controls one or more domains the first time it communicates with Let's Encrypt.

To begin, the agent asks the Let's Encrypt CA what it has to do to establish its control over a domain. The Let's Encrypt CA will examine the submitted domain name and provide one or more challenges. These are the various methods by which the agent can demonstrate domain control. For instance, the CA might give the agent the option of:

• Provisioning a DNS record, or;
• Provisioning an HTTP resource.

The Let's Encrypt CA also sends a notice that the agent must sign with its private key pair to show that it controls the key pair, in addition to the challenges.

One of the obstacles offered by the agent software is completed. Now, let's imagine it can complete the second task: it generates a file on the domain at a specified path. The agent additionally uses its private key to sign the specified nonce. When the agent has finished these processes, it informs the CA that validation is complete.

The CA's role after that is to ensure that the challenges have been met. The CA verifies the nonce's signature and downloads the certificate’s file from the web server to ensure it contains the expected information.

If the signature over the nonce is valid, and the challenges pass, the public key-identified agent is permitted to control certificates for the particular domain.

Certificate Issuance and Revocation

Requesting, renewing, and canceling certificates is simple once the agent has an approved key pair. The agent creates a Certificate Signing Request (CSR) that requests the Let's Encrypt CA issue a certificate for the particular domain with a specified public key. The CSR includes a signature from the private key that corresponds to the public key in the CSR, as is customary. The agent additionally signs the entire CSR with the approved key for the specific domain, ensuring that the Let's Encrypt CA is aware of it.

The Let's Encrypt CA checks both signatures when it receives the request. If everything looks good, it generates a certificate, using the CSR's public key and sends it back to the agent.

Revocation works in a similar way. The agent signs a revocation request using the approved key pair, and the Let's Encrypt CA validates the request. If it is valid, it publishes revocation information using standard revocation channels (such as OCSP) so that relying parties, such as browsers, are aware that the certificate has been revoked.