How Let's Encrypt Certificates Work

How Let's Encrypt Certificates Work: ACME, Chain, and Rate Limits

Let's Encrypt provides free, automated TLS certificates through the ACME protocol (RFC 8555), eliminating the cost and manual effort of certificate management for most web server operators. Since its launch in 2015, Let's Encrypt has become the world's largest certificate authority by volume, issuing billions of certificates to public websites. Its certificates are trusted by all major browsers and operating systems. Let's Encrypt currently issues certificates with 90-day validity; it announced a reduction to 45-day validity by 2028¹. Consequently, ACME automation is not optional for Let's Encrypt deployments at scale, since manual renewal every 45 days per certificate is operationally untenable for any fleet larger than a handful of servers. This guide covers how Let's Encrypt works, how to verify its certificates, and how to read the specific fields you find in a Let's Encrypt certificate chain.

How Let's Encrypt issues certificates via ACME

Let's Encrypt issues certificates through the ACME protocol defined in RFC 8555. An ACME client on your server requests a certificate, and Let's Encrypt responds with a challenge to prove you control the domain. Two challenge types are commonly used. The HTTP-01 challenge requires the client to serve a specific token at a well-known URL on port 80 of the domain. The DNS-01 challenge requires the client to create a specific TXT record in the domain's DNS zone, which is also the only option for wildcard certificates². After the client satisfies the challenge, Let's Encrypt validates it, issues the certificate, and returns it to the client. Certbot, the official ACME client, handles this automatically and renews the certificate when 30 or fewer days remain.

Furthermore, ACME clients exist for every major web server and cloud platform, including Caddy, acme.sh, Traefik, AWS, and Cloudflare, making ACME integration a standard feature rather than an afterthought. The CapyToolkit Certificate Inspector works with certificates from any of these clients, so you can verify the output regardless of which ACME client your server uses.

How HTTP-01 and DNS-01 challenges differ in practice

The HTTP-01 challenge requires the client to serve a specific token at a well-known URL on port 80 of the domain. The DNS-01 challenge requires the client to create a specific TXT record in the domain's DNS zone, which is also the only option for wildcard certificates. DNS-01 is the better choice when you need wildcard certificates or when your web server cannot be reached on port 80 during renewal.

A practical tip is to pick the challenge that matches your renewal environment before you deploy, because switching later means re-proving control a different way. HTTP-01 works when port 80 is open and the server is publicly reachable, while DNS-01 is the better fit for wildcard certificates and for hosts hidden behind a firewall. The CapyToolkit Certificate Inspector verifies the resulting certificate from any ACME client, so the chain you get is what matters, not which client produced it.

What a Let's Encrypt certificate contains

A Let's Encrypt certificate is a standard X.509 version 3 certificate with specific fields that identify its origin. The Issuer distinguished name contains the intermediate CA name, typically R10 or R11 as of mid-2026, with Organization Let's Encrypt. The certificate is signed by one of Let's Encrypt's active intermediate CAs, which chains to the ISRG Root X1 self-signed root. The validity window is 90 days from issuance, planned to reduce to 45 days by 2028. The SANs extension contains the domain names covered. Key algorithm choices include RSA 2048-bit and ECDSA P-256, both supported by Certbot. The CapyToolkit Certificate Inspector shows all of these fields, so you can confirm your certificate chains to ISRG Root X1, with the chain view labeling the intermediate as INTERMEDIATE CERTIFICATE and the ISRG Root X1 as ROOT CERTIFICATE · self-signed.

How to identify a Let's Encrypt certificate from its fields

The combination of the Issuer Organization field and the ISRG Root X1 root signature is what distinguishes a Let's Encrypt certificate from other publicly trusted certificates. The CapyToolkit Certificate Inspector highlights the issuer chain so you can confirm the certificate chains to ISRG Root X1 rather than to a commercial root, which is useful when auditing whether a deployment has replaced a paid certificate with a Let's Encrypt one.

Rate limits and the staging environment

Let's Encrypt enforces rate limits to prevent abuse and protect CA infrastructure. The primary limit is 50 certificates per registered domain per week, where registered domain refers to the effective top-level domain plus one label, such as example.com rather than www.example.com. Each certificate can cover up to 100 SANs³. Renewal requests for existing certificates do not count against the rate limit as long as the new certificate covers identical or a subset of the same domain names. Consequently, a renewal failure that causes all subsequent renewal attempts to fail as new certificate requests rather than renewals can quickly exhaust the weekly limit. Building on this, the Let's Encrypt staging environment uses a separate, higher rate limit and issues certificates from a test CA not trusted by browsers; using the staging environment for development and testing prevents accidentally exhausting production rate limits during system setup.

When to use staging versus production during automation setup

Use staging when you are first configuring a new ACME client or testing a renewal script against a new server. The staging environment uses a higher rate limit and issues certificates from the Fake Root X1 and Fake Intermediate X1 test CAs, which browsers do not trust. Switching to production once your automation is confirmed working avoids burning through the production 50-certificates-per-domain-per-week limit on what should have been routine test runs.

When to use this

Use this guide when deploying Let's Encrypt for the first time, when troubleshooting ACME renewal failures, when inspecting a Let's Encrypt certificate to understand its chain structure, or when planning a migration to shorter certificate validity windows ahead of the planned 45-day reduction. It also applies when you are choosing between HTTP-01 and DNS-01 challenge types for a new deployment, since the choice determines whether wildcard certificates are available and whether your ACME client needs DNS provider API access for programmatic TXT record management. Furthermore, use this guide to understand the Let's Encrypt intermediate chain structure when configuring OCSP stapling or when verifying that your server sends the correct fullchain.pem file rather than the leaf-only cert.pem, which omits the intermediate that many clients need to complete chain validation.

Examples