Bridge SSL
Let's Encrypt: what your client runs and what the authority checks
Let's Encrypt is a certificate authority that issues ACME certs: software on your side asks for a certificate, proves control of each name and receives the certificate, without a person in the loop [2]. Its SSL/TLS certificates are free, with no fee charged, and it is a project of the nonprofit Internet Security Research Group (ISRG) [1][3]. This page covers how Let's Encrypt runs the protocol: the endpoint your client talks to, how each challenge is checked from the authority's side, and what your network has to let through.
- Operator
- Internet Security Research Group (ISRG), a nonprofit [1]
- Fee
- none for the certificate [3]
- Validation
- domain validation only; no organisation or extended validation [3]
- Challenges
- HTTP-01, DNS-01, TLS-ALPN-01 [5]
- Private key
- generated and kept on your side, never on Let's Encrypt's servers [3]
Two routes to a Let's Encrypt certificate
There are two routes: a hosting provider runs an ACME client for you, or you run one yourself [4]. Nothing is issued on the Let's Encrypt website itself; every certificate comes through its ACME API, so the question is who operates the client [4].
Your hosting provider or platform runs it. The provider gets the SSL certificate from Let's Encrypt and renews it for you, either automatically or once you switch on a setting [4]. Let's Encrypt treats whoever holds the private key as the Subscriber, and for a hosting provider that is the provider, not its customer [6].
You run it on your own server. This needs the right to run commands with sufficient privileges [4]. For most people Let's Encrypt recommends Certbot [4]; how to generate a Let's Encrypt certificate with Certbot, command by command, is a walkthrough of its own. Other clients exist for setups Certbot does not fit, so choose an ACME client by class, not by name before you pick one.
The route decides what you maintain. With a provider, the client, the key and the renewal schedule are its problem. On your own server, all three are yours, together with the firewall rules below.
What your client does, in order
A client runs the RFC 8555 sequence against Let's Encrypt in this order.
Reads the directory. The client is configured with the production URL
https://acme-v02.api.letsencrypt.org/directory[4], and the directory gives the URL for each ACME operation (RFC 8555 §7.1.1) [9].Creates an account key pair. Let's Encrypt identifies the client by this public key [2]. It is a different key from the one in the certificate, and an account key cannot be reused as a certificate key [6].
Orders a certificate and receives challenges. For each name the authority returns one or more sets of challenges, and the client completes one set [2].
Sends a certificate signing request. Once authorised, the client submits a PKCS#10 CSR carrying the public key to be certified, and signs the request with the account key [2].
Downloads the SSL certificate and its chain. Intermediates are likely to change, so Let's Encrypt asks clients to build the chain from the
Link: rel="up"header instead of hardcoding an intermediate [6][9].
How Let's Encrypt checks each challenge
Each challenge is checked by Let's Encrypt's servers, from multiple network perspectives in parallel, which makes subverting validation much harder than fooling a single vantage point [2].
| Challenge | What the client publishes | Where Let's Encrypt looks | Wildcard |
|---|---|---|---|
| HTTP-01 | a file holding the token and a thumbprint of the account key | http://<domain>/.well-known/acme-challenge/<token>, on port 80 only; redirects are followed only to ports 80 or 443 | no |
| DNS-01 | a TXT record derived from the token and the account key | _acme-challenge.<domain>; CNAME or NS delegation to another zone is followed | yes |
| TLS-ALPN-01 | a validation certificate, offered under the acme-tls/1 protocol | a TLS connection on port 443 | no |
When unsure, Let's Encrypt advises the client's defaults or HTTP-01 [5]. DNS-01 makes sense for automation only where the DNS provider has an API, and full DNS credentials on a web server raise the cost of a breach: narrowly scoped credentials, or validation from a separate server, are the pattern it recommends [5]. TLS-ALPN-01, standardised as RFC 8737, suits TLS-terminating reverse proxies more than ordinary sites [5][10].
A Let's Encrypt wildcard SSL certificate therefore always goes through DNS-01 [3][5]; setting one up, zone access included, is a topic of its own.
Ports and firewall rules
What has to be open depends on the challenge, and some of it applies to every challenge.
Outbound 443 from the machine running the client, to reach the ACME API [6].
Inbound 80 for HTTP-01 [6]. Let's Encrypt recommends keeping plain HTTP open with a redirect to HTTPS rather than refusing port 80 [6].
Inbound 443 for TLS-ALPN-01, where the validation connection arrives [10].
Inbound 53, TCP and UDP, to your authoritative DNS servers, for every challenge type [6].
Allow-listing the authority does not work. Let's Encrypt publishes neither the addresses of its ACME service nor the addresses it validates from, and both change without notice [3][6].
Test against staging before production
Let's Encrypt asks for tests against its staging environment before production [7]. The staging directory is https://acme-staging-v02.api.letsencrypt.org/directory [8], and three things differ from production.
A separate account. ACME accounts are scoped to each environment, so staging needs its own; Certbot creates it for you [7].
Untrusted roots. Staging certificates chain to roots that are not in browser or client trust stores and carry a "(STAGING)" prefix, so a browser warning on a staging certificate is the expected result [7].
A client switch. In Certbot the switch is
--test-certor--dry-run; other clients document their own [7].
Do not add a staging root to a trust store you browse with. Let's Encrypt states those roots are not audited or held to the standards of its production roots [7].
What happens after issuance
After issuance the certificate is public, and your client still owns revocation and renewal.
The name becomes public. Let's Encrypt submits each certificate to public Certificate Transparency logs [2]. Crawlers read those logs, find the name and visit it, so new traffic in your server logs right after issuance is expected [3].
Revocation is signed like issuance. The client signs a revocation request with the account key authorised for the name, and Let's Encrypt publishes the revocation in a Certificate Revocation List [2].
Renewal should not run on the hour. Let's Encrypt asks clients to renew at random times, not at midnight UTC or the first second of an hour; when the service is busy, clients are told to try again later [3]. A failed renewal is not fatal: retry with exponential backoff and report the error to an administrator [6].
Renewing a Let's Encrypt SSL certificate repeats the sequence: validation, then a new certificate [2]. Let's Encrypt may skip the validation, though, while an earlier authorization is still valid [3]. Let's Encrypt also suggests a renewal window for each certificate through ACME Renewal Information, defined in RFC 9773, and recommends that clients check it [6][11]. Keeping that loop alive is covered in ACME certificate renewal automation that does not fail quietly.
What Let's Encrypt does not issue
It issues domain-validated certificates and nothing else [3].
No organisation or extended validation. Let's Encrypt says it cannot automate those checks and has no plans to offer them [3].
No email or code signing certificates. Those need a different type of certificate. The domain-validated certificate itself works for any server with a domain name: web, mail, FTP [3].
No direct support. Help comes from the documentation and the community forums [3].
Where a requirement names organisation or extended validation, the answer is a different authority, not a different setting.
FAQ
Is Let's Encrypt free?
Yes. Let's Encrypt charges no fee for its certificates; it is a nonprofit and relies on sponsors, grantmakers and individuals to fund the service. [3]
Do browsers accept a Let's Encrypt certificate?
For most browsers and operating systems, yes. Let's Encrypt publishes a compatibility list with the details. [3]
Does Let's Encrypt keep my private key?
No. The private key is generated and managed on your own servers, not by Let's Encrypt. [3]
Can one Let's Encrypt certificate cover several names?
Yes. A certificate can list several names through the Subject Alternative Name mechanism, and a wildcard name needs the DNS-01 challenge. [3]
Sources
Let's Encrypt home page and About: a free, automated and open certificate authority; a project of the nonprofit ISRG.
Let's Encrypt, How It Works: account key, challenges, network perspectives, CSR, CT logs, CRL, renewal.
Let's Encrypt, FAQ: fee, funding, DV only, certificate types, support, private keys, SAN, wildcards, compatibility, CT traffic, validation addresses, renewal times, reuse of an earlier authorization.
Let's Encrypt, Getting Started: provider or own client, Certbot, production endpoint.
Let's Encrypt, Challenge Types: HTTP-01, DNS-01, TLS-ALPN-01.
Let's Encrypt, Integration Guide: Subscriber, keys,
Link: rel="up", firewall, ARI, retries.Let's Encrypt, Staging Environment: accounts, staging roots, Certbot flags.
Let's Encrypt, ACME Protocol Updates: production and staging endpoints.
RFC 8555, Automatic Certificate Management Environment (ACME): §7.1.1, §7.4.2.
RFC 8737, ACME TLS-ALPN-01 challenge: port 443,
acme-tls/1.RFC 9773, ACME Renewal Information (ARI) Extension.