ACME (Automated Certificate Management)

ACME (Automatic Certificate Management Environment) is the IETF standard RFC 8555. It is a protocol that a certificate authority and an applicant use to automate verification, issuance and revocation of TLS certificates. ACME is not a certificate authority and never issues a certificate itself. The CA runs the ACME server, your software runs the ACME client, and the two exchange signed JSON messages over HTTPS (RFC 8555, Section 4). ACME is the protocol behind Let's Encrypt. It is what makes free per-domain certificates practical at CDN scale.

ACME is also not an identity check. Certificates obtained this way are domain validated (DV). The only validation the CA is required to perform is that the requester has effective control of the domain. The CA is not required to verify the requester's real-world identity (RFC 8555, Section 1). Whoever can answer a challenge for a name can get a certificate for it. So the challenge method and the credentials that answer it are what you actually have to design.

How it works

The client generates an account key pair, registers an account, and signs every later message with that private key (RFC 8555, Section 3). Issuance is then four steps (RFC 8555, Section 4):

1. Submit an order for the domain names the certificate must cover.
2. Prove control of each name by completing a challenge.
3. Finalize the order by submitting a Certificate Signing Request (CSR).
4. Await issuance, then download the certificate.

Step 3 is a CSR, so the certificate's private key is generated by the client and is never sent to the CA.

The proof is the core of the protocol. RFC 8555 defines an extensible set of challenges. Three are in general use:

• HTTP-01: The client serves the key authorization (the challenge token plus a thumbprint of the account key) at http://{domain}/.well-known/acme-challenge/{token}. The CA dereferences it with a GET. That GET MUST be sent to TCP port 80 (RFC 8555, Section 8.3). Let's Encrypt follows up to 10 redirects, only to http: or https: and only to ports 80 or 443. It does not validate the certificates it meets on the way. So an edge that redirects everything to HTTPS does not break validation (Let's Encrypt: Challenge Types).
• DNS-01: The client publishes the base64url-encoded SHA-256 digest of the key authorization as a TXT record at _acme-challenge.{domain} in DNS. The CA queries for it (RFC 8555, Section 8.4).
• TLS-ALPN-01: The CA opens a TLS connection to TCP port 443. It offers only the ALPN protocol acme-tls/1 and an SNI extension containing only the name being validated. The client answers with a self-signed certificate. That certificate carries a critical acmeIdentifier extension holding the digest of the key authorization (RFC 8737, Section 3).

A completed challenge produces an authorization. The CA will reuse it for a period. So a renewal is normally just a new order for the same names. Let's Encrypt's authorization reuse period is 30 days today (Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days). Revocation is its own signed request to the server's revokeCert URL. Unusually, it may be signed with either the account key pair or the key pair in the certificate (RFC 8555, Section 7.6). Where the server implements ACME Renewal Information (RFC 9773), it suggests to the client when to renew, instead of the client assuming a period.

Why it matters for a CDN

Before ACME, the flow was to cut and paste a CSR into a CA's web page and install the result by hand. RFC 8555 cites informal usability tests in which webmasters often needed 1 to 3 hours per certificate (RFC 8555, Section 1). No CDN can do that per customer domain. Instead the CDN runs the client itself. It answers the challenge and pushes the issued certificate to every edge server, with nobody in the loop. Fastly, for example, reports most certificates fully deployed across its network within 60 seconds, occasionally up to an hour (Fastly: certificates Fastly manages).

Short lifetimes force the automation. Let's Encrypt's default is still 90 days. That is a deliberate choice. Shorter lifetimes limit damage from mis-issuance and key compromise. They also encourage automation, which Let's Encrypt calls essential for ease of use and reliability (Let's Encrypt: Certificate Lifetime Rationale and Plans).

Which challenge you can use is a real architectural constraint. DNS-01 is often the most practical for a CDN. It is the method CAs accept for wildcards. It validates names whose web servers are not exposed to the public internet, so it works while the origin is still private. It also works well with many servers (Let's Encrypt: Challenge Types). With Fastly, it also lets you finish validation before production traffic points at the CDN at all (Fastly). HTTP-01 is easier to automate. It specifically allows hosting providers to issue certificates for domains CNAMEd to them (Let's Encrypt). TLS-ALPN-01 was designed for this industry. RFC 8737 introduces it for hosting providers, CDNs and TLS-terminating load balancers. It lets them validate domain control without modifying the HTTP handling of their backends (RFC 8737, Section 1). But Let's Encrypt is blunt: it is not suitable for most people. It is best suited to authors of TLS-terminating reverse proxies, and ACME client support for it is limited (Let's Encrypt: Challenge Types).

What CDNs do

• Cloudflare: Universal SSL is on by default. It is available on every plan from Free to Enterprise. Cloudflare issues and renews free, unshared, publicly trusted certificates for all domains added to and activated on Cloudflare. It handles issuance, renewal and deployment itself (Cloudflare: Universal SSL). Cloudflare, not the customer, controls the validity period and the CA for these. The CAs listed for Universal certificates are Let's Encrypt, Google Trust Services and SSL.com. RSA Universal certificates, rather than ECDSA, are limited to paid plans (Cloudflare: Certificate authorities). Cloudflare said in July 2024 that it was moving towards only using CAs that follow the ACME protocol (Cloudflare blog, July 2024).
• Fastly: Fastly-managed certificates use the ACME protocol to procure and renew TLS certificates. The default verification method is the ACME DNS challenge. You create a CNAME at _acme-challenge.DOMAIN_NAME pointing to a unique fastly-validations.com target. This is what allows TLS to be set up before production traffic is pointed at Fastly. Wildcard domains require the DNS or the email validation challenge. The CA is the customer's choice: Certainly (Fastly's own publicly trusted CA), Let's Encrypt, or GlobalSign on paid accounts. Free accounts include two managed domains using Certainly or Let's Encrypt (Fastly: certificates Fastly manages).
• AWS Certificate Manager: Since 30 June 2026, ACM has offered a fully managed ACME server endpoint. It works with any ACMEv2-compatible client, such as Certbot, cert-manager or acme.sh, issuing public certificates from Amazon Trust Services. Clients register using External Account Binding credentials. The administrator validates which domains an endpoint may issue for, so application teams get certificates without ever holding DNS credentials. The ACME endpoint is available in all commercial AWS Regions (AWS News Blog). External Account Binding is the RFC 8555 mechanism for binding an ACME account to an existing account in a non-ACME system. An example is a CA customer database (RFC 8555, Section 7.3.4).

Watch out for

• Every challenge needs live access to your infrastructure at validation time. That means the right HTTP-01 token served on port 80, the right TLS-ALPN-01 handshake on 443, or the right DNS-01 TXT record (Let's Encrypt). DNS-01 adds propagation delay. If your DNS API cannot report propagation, you may have to make the client wait as much as an hour before triggering validation (Let's Encrypt: Challenge Types).
• The wildcard restriction is CA policy, not a protocol rule. RFC 8555 permits a wildcard identifier in an order and authorizes it against the base name (RFC 8555, Section 7.1.3). But Let's Encrypt will not issue wildcards via HTTP-01 or TLS-ALPN-01, and Fastly requires the DNS or email challenge for them. TLS-ALPN-01's predecessor, TLS-SNI-01, was removed in March 2019 because it was not secure enough. That is why the ALPN-based method exists (Let's Encrypt: Challenge Types).
• Stale TXT records break DNS-01. Several records under the same name are legal. Validating a wildcard and a non-wildcard at once produces exactly that. But if the response size gets too big, Let's Encrypt starts rejecting it. So clean up after validation (Let's Encrypt: Challenge Types).
• Running one hostname on more than one platform is where multi-CDN setups bite. Fastly warns that if the same domain is managed with ACME both at Fastly and elsewhere, conflicting CNAME or TXT records can break verification (Fastly).
• You cannot always get the certificate before you move traffic. Cloudflare's Universal certificates are issued only after the domain is active on Cloudflare. If you need a certificate before migrating traffic, you need an Advanced or Custom certificate instead (Cloudflare: Universal SSL).
• The account key matters more than the certificate key. The certificate's key stays on the client. But whoever holds the account key can order and revoke certificates for the account. RFC 8555 states this plainly: compromise of an account key has more serious consequences than compromise of a key corresponding to a certificate (RFC 8555, Section 11.1).
• A CAA record that does not list the CA your client or CDN uses blocks issuance. It presents as validation that never completes, rather than as a clear error (Fastly). Cloudflare publishes the exact CAA content each of its CAs needs (Cloudflare: Certificate authorities).
• Rate limits are part of ACME. Servers may rate limit resource creation, and MUST then respond with the rateLimited error type (RFC 8555, Section 6.6). Let's Encrypt allows up to 300 new orders per account every 3 hours, 50 certificates per registered domain every 7 days, and 5 certificates per identical set of identifiers every 7 days. Renewals coordinated by ARI are exempt from all rate limits (Let's Encrypt: Rate Limits).
• Everything you issue is public. Issued certificates appear in the Certificate Transparency logs that crt.sh and Censys search. So an internal hostname placed on a CDN certificate is published (Let's Encrypt: Rate Limits).
• Lifetimes are still shrinking, and fixed renewal schedules are what breaks. Let's Encrypt controls this with ACME profiles. The default classic profile is 90 days. The opt-in tlsserver profile has issued 45-day certificates since 13 May 2026. A 6-day shortlived profile is available to all subscribers. classic moves to 64-day certificates with a 10-day authorization reuse period on 10 February 2027. It moves to 45-day certificates with a 7-hour reuse period on 16 February 2028 (Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days, Let's Encrypt: Certificate Lifetime Rationale and Plans). Industry rules cap lifetimes at 47 days from 15 March 2029. Let's Encrypt is going slightly below that cap, and well ahead of the deadline. Let's Encrypt says plainly that renewing at a hardcoded interval of 60 days will no longer be sufficient. Certbot 4.0.0 and later treat a certificate as ready for renewal when less than a third of its lifetime remains (Certbot documentation).

Best practice

• Automate renewal, and let something other than a calendar decide the timing. Enable ARI if your client supports it. Otherwise, renew at roughly two thirds of the way through the lifetime, rather than at a fixed number of days (Let's Encrypt). Check whether your packaging already installs a certbot renew timer, in the crontab or in systemctl list-timers, before adding another one (Certbot documentation).
• Scope DNS-01 credentials. Full DNS API credentials on a web server significantly increase the impact if that server is hacked. Use narrowly scoped credentials, or delegate _acme-challenge by CNAME or NS to a validation-specific zone (Let's Encrypt: Challenge Types). Leave that delegation in place, because Fastly asks you to keep its _acme-challenge CNAME up to avoid interruptions in service (Fastly).
• Keep each private key only where TLS terminates. Treat the ACME account key as the more sensitive of the two.
• Publish CAA records naming exactly the CAs in play, including your CDN's. Monitor certificates so that a renewal that did not happen alerts you before expiry (Let's Encrypt).
• Develop and test against the CA's staging environment rather than the production API (Let's Encrypt: Rate Limits).
• Track DNS-PERSIST-01, an active IETF ACME working-group Internet-Draft (draft-ietf-acme-dns-persist, last updated March 2026). It proposes a validation TXT record that does not have to change on every renewal, which would remove the need to give an ACME client DNS write access. Let's Encrypt expects it to be available during 2026, but it is not an RFC yet (IETF Datatracker, Let's Encrypt).