Let's Encrypt Certificates: How ACME Automation Works

A Let's Encrypt certificate is a free, domain-validated X.509 certificate that an ACME client requests, proves control for, and renews without a human in the loop. As of 2026 the default lifetime is 90 days, so a fleet of 10,000 hostnames renewing at day 60 generates roughly 1,170 issuances a week. That volume drives both the rate-limit math and the decision about where a CDN terminates TLS.

Let's Encrypt issues certificates through the ACME protocol defined in RFC 8555, and as of 2026 its default certificates are valid for 90 days, with clients expected to renew when roughly one third of the lifetime remains. Let's Encrypt has announced that default lifetimes shrink to 64 days in 2027 and 45 days in 2028, in line with the CA/Browser Forum schedule that caps public TLS certificates at 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029.

How a Let's Encrypt certificate gets issued through the ACME protocol

ACME issuance is a sequence of signed HTTP requests: create an account, open an order for a set of identifiers, satisfy one challenge per identifier, submit a CSR to finalize, then download the chain. Every request is a JWS (JSON Web Signature) signed with the account key and carries a single-use replay nonce, which is why ACME clients hold state between steps.

The objects matter because failures map to them precisely:

1. Account. A keypair registered once. The account URI can be pinned in CAA records using the accounturi parameter from RFC 8657, which stops any other account from issuing for your zone.
2. Order. A request for a set of identifiers (up to 100 names). The order moves through pending, ready, processing and valid.
3. Authorization. One per identifier, proving control. Valid authorizations are reused across orders for a period, which is why your second certificate for the same name often issues instantly. That reuse window is also shrinking under the CA/Browser Forum schedule.
4. Challenge. The proof itself: HTTP-01, DNS-01 or TLS-ALPN-01.
5. Finalize and download. The client posts a CSR, polls until the order is valid, and fetches the certificate with its intermediate.

Validation is not done from a single vantage point. Let's Encrypt checks each challenge from multiple network perspectives in different regions, and multi-perspective issuance corroboration became mandatory for all public CAs in 2025. A challenge that answers correctly from one region but not another fails.

HTTP-01 vs. DNS-01 vs. TLS-ALPN-01

HTTP-01 serves a token at the .well-known/acme-challenge path over port 80, follows redirects to HTTPS, and cannot issue wildcards. DNS-01 publishes a TXT record at the _acme-challenge label, works for wildcards and for hosts with no public port open, and is the only method that does not care where TLS terminates. TLS-ALPN-01 answers on port 443 with a self-signed certificate negotiated through the acme-tls/1 ALPN value.

That last detail rules TLS-ALPN-01 out behind any CDN that terminates TLS at the edge: the validator's handshake reaches the CDN, not your origin.

Let's Encrypt rate limits in 2026 that bite at scale

The limits that matter most for automated fleets are 50 new certificates per registered domain per 7 days, 5 certificates per identical set of names per 7 days, 300 new orders per account per 3 hours, and 5 failed authorizations per identifier per account per hour. All of them refill gradually rather than resetting at a fixed time.

The limit that takes production down is rarely volume; it is the 5-per-hour failure limit combined with a client that retries blindly.

Two exemptions change the planning. Renewals for an identical set of names do not count against the per-registered-domain limit, and renewals made inside the window suggested by ACME Renewal Information (ARI, RFC 9773) are exempt from rate limits. A client that supports ARI also lets Let's Encrypt pull renewals forward during a mass revocation, which is the single biggest reason to upgrade an older client. For testing, the staging environment has much higher limits and an untrusted root.

Renewal budget: what shorter lifetimes do to your fleet

The useful number is not lifetime but slack: the days between the first renewal attempt and expiry, which is how long a broken pipeline can stay broken before users see an error. The table below is plain arithmetic for 10,000 single-name certificates renewed at roughly two thirds of lifetime (half for the short-lived profile).

Moving from 90 to 45 days doubles issuance volume but halves your time to notice a broken renewal, and the second effect is the one that causes outages.

At 2,330 renewals a week the 300-orders-per-3-hours limit still leaves plenty of headroom (about 2,400 orders a day per account), so throughput is not the constraint. Detection is. Let's Encrypt stopped sending expiry emails in 2025, so a 15-day slack window means your own monitoring must page within days, not weeks. Our estimate: any team whose certificate alert threshold is still "14 days to expiry" will start firing it as a normal state once 45-day certificates arrive, and should alert on renewal age instead.

Using a letsencrypt SSL setup with a CDN: three architectures

A CDN adds a second TLS leg and moves the public endpoint away from your ACME client, so the question is which party answers the challenge. There are three workable patterns, each with a distinct failure mode.

Pattern 1: the CDN manages the edge certificate

The provider runs ACME itself, usually via HTTP-01 answered at the edge or DNS-01 through a CNAME you delegate for the _acme-challenge label. This is the lowest-effort option and the default for most custom-domain setups. The trade-off is visibility: you cannot set CAA accounturi pinning to an account you do not control, so pin by CA (issue "letsencrypt.org") and confirm with the provider which CA it uses. BlazingCDN includes HTTPS and SSL certificates and custom domains on every plan, so the edge certificate is part of the zone set up together with an engineer during roughly one hour of onboarding; the BlazingCDN features list covering TLS 1.3 and custom domains shows what is included per zone.

Pattern 2: you issue, then upload to the CDN

Your ACME client runs DNS-01 centrally and pushes the certificate and key to the CDN through its API. This keeps account pinning and one issuance pipeline across multiple CDNs, which matters for multi-CDN setups where two providers must present the same hostname. The cost is that the upload step becomes a new failure point: a renewal that succeeds at Let's Encrypt but fails to deploy still expires at the edge.

Pattern 3: HTTP-01 proxied to origin

The origin keeps running its own client and the CDN forwards the challenge path. It works only if that path bypasses cache, is exempt from geo or IP restrictions (validators come from several regions), and is not rewritten. A cached 404 on the challenge path burns the 5-failures-per-hour budget in minutes.

Whichever pattern you choose for the edge, the origin leg still needs its own valid certificate if the CDN verifies upstream TLS. That certificate never faces browsers, so DNS-01 with a long-lived automation is the usual choice there.

Trade-offs and failure modes

• Broken IPv6. If a hostname has an AAAA record, validators prefer IPv6. A misconfigured IPv6 path on the origin or load balancer fails HTTP-01 even when IPv4 is fine.
• DNS-01 propagation. The TXT record must be visible on every authoritative nameserver before you trigger validation. Secondary nameservers with slow zone transfers produce intermittent, region-dependent failures under multi-perspective checks.
• CAA drift. A CAA record added by another team that omits Let's Encrypt silently blocks renewals until day 60 turns into day 89.
• Revocation checking. Let's Encrypt ended OCSP in 2025 and publishes revocation through CRLs only. Remove OCSP stapling expectations and any "must-staple" extension from your CSRs.
• Renew-on-boot clients. Ephemeral workloads requesting certificates at startup hit the 5-duplicate limit within a single bad deploy. Persist certificates or issue centrally.
• Observability gap. Most clients log success locally; few export the timestamp of the last successful renewal. Without it you only learn about failure from the expiry date.

Verify this on your own stack

Run an OpenSSL client handshake against each public hostname, with SNI set, from at least two regions, and compare the notAfter date and issuer between the CDN edge and the origin. Export the earliest certificate expiry per hostname (the Prometheus blackbox exporter's probe_ssl_earliest_cert_expiry metric works) and alert when time since issuance exceeds two thirds of lifetime, not when expiry nears. Check that your ACME client logs ARI renewal windows; if it does not, it is not using them.

Who this fits and who it does not

Full ACME automation with Let's Encrypt fits any team serving public hostnames that can tolerate domain-validated certificates and can run DNS-01 or keep a challenge path open. It suits multi-tenant platforms well, provided they plan around the 50-per-registered-domain limit or use a separate registered domain per tenant.

It does not fit organizations that need organization- or extended-validation certificates, certificates for internal names, or lifetimes beyond what Let's Encrypt offers. Teams with change-freeze windows longer than the renewal slack should also reconsider; at 45-day lifetimes a two-week freeze can consume the entire margin.

FAQ: Let's Encrypt certificates and the ACME protocol

How long is a Let's Encrypt certificate valid in 2026?

A default Let's Encrypt certificate is valid for 90 days in 2026. Let's Encrypt has announced that the default drops to 64 days in 2027 and 45 days in 2028, and it already offers a short-lived profile of about six days. Clients should renew at roughly two thirds of lifetime and follow ARI renewal windows when available.

Can I use a letsencrypt SSL certificate behind a CDN?

Yes, a Let's Encrypt certificate works behind a CDN if the challenge can still be answered. DNS-01 works regardless of where TLS terminates, HTTP-01 works if the CDN forwards the challenge path uncached and unrestricted, and TLS-ALPN-01 fails when the CDN terminates TLS. Many CDNs also issue Let's Encrypt edge certificates on your behalf.

Which Let's Encrypt rate limit causes the most ACME renewal failures?

The failed-validation limit causes the most ACME renewal outages: five failed authorizations per identifier per account per hour. A client retrying against a cached 404, a blocked region or broken IPv6 exhausts it quickly. Volume limits such as 50 certificates per registered domain per week rarely bite on renewals, because identical-name renewals are exempt.

Does the ACME protocol support wildcard Let's Encrypt certificates?

Yes, the ACME protocol supports wildcard Let's Encrypt certificates, but only through the DNS-01 challenge. Your client needs API access to the authoritative DNS zone, or you delegate the _acme-challenge label by CNAME to a zone the client controls. Wildcards reduce issuance count but widen the blast radius if the private key leaks.

Audit your renewal slack before 45-day certificates arrive

This week, list every hostname with its issuer, lifetime, issuing pattern (CDN-managed, uploaded or origin HTTP-01) and the timestamp of its last successful renewal. Recompute slack at 45 days for each one, then move your alert from "days to expiry" to "renewal overdue by more than two thirds of lifetime". Any hostname whose challenge path passes through a cache or geo rule is your first candidate for DNS-01. If your workload is heavy static delivery such as video, software builds or large files, the BlazingCDN Anycast CDN with HTTPS certificates included on every plan is a delivery layer you can test against the same hostnames.