ACME Challenge Types: Which One Your Setup Can Actually Use

What a challenge actually proves

An ACME challenge proves one narrow thing: that whoever holds a particular account key also controls a particular name, right now. It says nothing about who owns the domain, what organisation stands behind it, or whether the request is a good idea. The certificate authority hands out a token, your client publishes something derived from that token where only a controller of the name could put it, and the authority goes and looks.

Where the client publishes it is the entire difference between the challenge types. RFC 8555 defines two places: a file served over HTTP, and a DNS TXT record. RFC 8737 later added a third, a TLS handshake on port 443 that carries the proof inside the certificate the server presents. All three end in the same place: an authorization object marked valid, good for a while, which lets the account order certificates for that name.

The phrase "good for a while" used to be the boring part. Under the old rules a completed validation could be reused for over a year, so a team could pass a challenge once, forget about it, and renew repeatedly on the strength of that one proof. That is the assumption the current schedule is dismantling, and it is why a decision that felt like a setup detail has become an architectural one.

One more thing worth saying early, because it saves a lot of confusion: ACME is a protocol, not a Let's Encrypt product. Any certificate authority can expose an ACME endpoint, several commercial ones do, and the challenge types behave identically against all of them. What differs at a commercial authority is account setup: usually External Account Binding, where a key identifier and an HMAC key from your account tie ACME requests back to your billing relationship.

HTTP-01, and the redirect rule nobody reads

The http-01 challenge asks you to serve a file at /.well-known/acme-challenge/<token> containing the key authorization, and the certificate authority fetches it over plain HTTP on port 80. The port is not negotiable, ACME does not let a client nominate a different one, because allowing arbitrary ports would let anyone who can bind a high port on a shared host claim the whole name.

That fixed port 80 is the source of most http-01 failures, and it gets blamed for a lot of failures it did not cause. The rule people get wrong is the redirect rule. Let's Encrypt follows redirects from that first request: up to ten hops, only to http: or https: URLs, and only to ports 80 or 443. It refuses redirects to bare IP addresses. And when a hop lands on HTTPS, it does not validate the certificate it finds there, which makes sense once you remember the request exists to obtain a working certificate in the first place.

The practical consequence: a site that redirects every port 80 request to HTTPS generally validates without any special case. The exception rule that so many nginx and IIS configurations carry for /.well-known/acme-challenge/ is, on Let's Encrypt at least, usually doing nothing. Other authorities set their own redirect limits, so read your CA's documentation before you rely on this. What no amount of redirect handling fixes is a port 80 that is closed at the firewall, because there is nothing to redirect from.

http-01 also cannot issue a wildcard, and cannot validate a host that the certificate authority cannot reach, which rules it out for anything behind a VPN, on an internal network, or in a pre-production environment that never sees public traffic. Within those limits it remains the least trouble to run: no API credentials, no propagation delay, and when it fails you can reproduce the exact request with curl.

Multiple servers behind a load balancer add one wrinkle. The authority may connect to any backend, so either every backend has to serve the same token file, or the challenge path has to be routed to one place that does. Sharing a webroot is the usual answer; terminating /.well-known/acme-challenge/ at the balancer and pointing it at a single host is the other. Setups where neither is possible tend to end up on dns-01.

DNS-01: the only route to a wildcard

The dns-01 challenge asks you to publish a TXT record at _acme-challenge.<name> whose value derives from the token and your account key. It is the only challenge that can validate a wildcard identifier, and that is a property of the specification rather than a policy any authority chose. Proving you run the web server at example.com tells nobody anything about who controls anything.example.com.

Two other capabilities fall out of the same design. The certificate authority queries public DNS rather than your host, so dns-01 works for machines with no public address at all, internal services, appliances on a management VLAN, staging environments that never see the internet. And it works before a server exists, which matters when you want the certificate ready ahead of a cutover.

If you are issuing wildcard certificates, dns-01 is not a preference you can revisit later; it is the mechanism, and any automation plan has to start from a DNS provider your client can write to. Our wildcard SSL certificate options cover which products fit that shape.

The costs are real. Your ACME client now needs credentials that can write DNS records, and the typical provider API token can edit every record in the zone. Propagation adds latency and a class of flaky failure that http-01 does not have, particularly with providers whose authoritative servers take their time agreeing with each other. Most clients wait and re-check before telling the authority to look, and most dns-01 problems that look mysterious are really a client that did not wait long enough.

The credential problem has a good answer, and it is under-used enough that it gets its own section further down.

TLS-ALPN-01: when port 80 is closed

RFC 8737 defines tls-alpn-01, which moves the proof into a TLS handshake on port 443. The authority connects with the ALPN protocol acme-tls/1 and an SNI value naming the identifier; your server answers with a self-signed certificate whose only subject alternative name is that identifier and which carries the validation value in an extension. No application data is exchanged, and the connection closes as soon as the handshake has carried the proof.

It exists for one situation: port 80 is unavailable and you cannot change that. Some hosting environments simply do not offer it, some networks block it as policy, and some operators would rather not run anything on 80 at all. Because tls-alpn-01 never touches port 80, it also survives configurations that redirect or drop everything there.

The requirement it brings is stricter than it first looks. Your software has to control the TLS handshake itself, not just sit behind something that terminates TLS for it. That works beautifully in Caddy, Traefik or a Go service using autocert, all of which can swap in the validation certificate for the duration of a handshake. It does not work at all if a CDN or a managed load balancer terminates TLS and you cannot make it speak acme-tls/1. Client support is narrower too: plenty of well-known ACME clients never implemented it.

Like http-01, it cannot issue wildcards, and like http-01 it needs the host to be reachable from the internet. If you were hoping it would solve an internal-hostname problem, it will not; that remains dns-01 territory, or a private CA.

dns-persist-01: validating once, not every time

The three challenges above share an assumption: every validation is a fresh transaction, with a fresh token and a fresh record to publish and clean up. dns-persist-01 breaks that assumption. Instead of a per-issuance TXT record, you publish one long-lived record that names a specific certificate authority and a specific ACME account, and the authority reads it to confirm that authorization still stands.

As of August 2026 the standing of this method is worth stating precisely, because it is newer than most documentation admits. The CA/Browser Forum approved the underlying validation method in ballot SC-088v3 in October 2025, adding it to the Baseline Requirements as method 3.2.2.4.22, "DNS TXT Record with Persistent Value". The IETF ACME working group adopted the corresponding draft the same month. Let's Encrypt published its rollout plan in February 2026, with staging first and production targeted for the second quarter of that year.

What it buys you is the removal of a moving part. A per-issuance record means write access at renewal time, a propagation wait every cycle, and a cleanup step that sometimes does not happen. A persistent record is written once and then read; the ACME client no longer needs standing credentials to change DNS on every renewal. That is a meaningful simplification for anyone whose objection to dns-01 was the credential, and it becomes more attractive the more often validation has to happen.

Treat availability as the open question. The draft is still a draft, support arrives authority by authority, and client support follows behind that. It is worth designing so you can adopt it, and worth checking your certificate authority's documentation for current status rather than assuming from an article, including this one.

Your challenge is now checked from several places

Multi-Perspective Issuance Corroboration changed how every one of these challenges is verified. Certificate authorities must now corroborate domain control, and the CAA check that runs alongside it, from several network vantage points in different parts of the world rather than from a single validator. The challenge you publish is unchanged; the number of parties looking at it is not.

A quorum model governs the result, tolerating a limited number of perspectives that fail to corroborate depending on how many were used. The bar has been rising in phases. DigiCert, for one, updated its implementation in June 2026 to require corroboration from at least four remote network locations spanning at least two Regional Internet Registry regions, in line with the next phase of the CA/Browser Forum requirements.

For most people this is invisible. For a specific and unlucky group it is the reason a setup that worked for years started failing. If your edge allowlists a known validator address range, applies a WAF rule that treats unfamiliar regions as suspicious, geo-blocks countries you do not sell to, or rate-limits aggressively, then a check that used to pass on one connection now has to pass on several from places you were not expecting. Our explainer on multi-perspective issuance corroboration goes through the mechanics in more detail.

dns-01 is not exempt. The lookups are DNS queries rather than HTTP requests, but they still come from multiple perspectives, which means split-horizon DNS, anycast configurations that answer differently by region, and resolvers that disagree during propagation can all produce a non-corroborating result. A record that is visible from your desk is not automatically visible from four other continents.

The reuse window is shrinking faster than the certificate

Ballot SC-081v3, which the CA/Browser Forum passed in April 2025, gets discussed almost entirely in terms of certificate lifetimes: 398 days down to 200 on 15 March 2026, to 100 on 15 March 2027, and to 47 on 15 March 2029. The same ballot cuts a second number on the same dates: how long a certificate authority may reuse a completed domain control validation, and that one falls further, ending at 10 days in 2029.

Follow that to its conclusion. In 2029 a certificate valid for 47 days rests on a proof of domain control that goes stale in 10. Even if you renew only at the last responsible moment, the challenge has to succeed several times inside a single certificate's life. Anything in that path that needs a person (a ticket to the DNS team, an approval, someone remembering to open port 80 for an afternoon) will be triggered often enough to become the thing that breaks.

This is the reason challenge choice deserves an architectural decision rather than a default. A challenge that is merely inconvenient at 398-day reuse becomes an operational liability at 10. It also explains the timing of dns-persist-01: a persistent authorization record is a direct answer to the problem of proving the same fact every week or two, forever.

Worth being precise about one thing, since it causes unnecessary alarm: reuse periods bind the certificate authority, not you. Nothing about your live certificate changes when a validation expires. The effect lands on your next issuance, which will require a fresh challenge, and if that challenge cannot run unattended, your next issuance is where you will find out.

Delegating _acme-challenge safely

The standard objection to dns-01 is that the ACME client needs credentials which, with most DNS providers, can rewrite the entire zone. Putting a token like that on a web server is a genuinely poor trade. The answer is delegation, and it is supported by every certificate authority that follows the DNS standards, because it uses nothing more exotic than a CNAME.

You create a CNAME at _acme-challenge.example.com pointing into a separate zone that holds nothing but challenge records. The ACME client gets credentials for that zone alone. When the certificate authority resolves the challenge name it follows the CNAME and reads the TXT record wherever it lands, exactly as ordinary DNS resolution requires. An NS record delegating the subtree to different nameservers achieves the same thing with more separation.

The security result is worth stating plainly: a compromise of the ACME client lets an attacker rewrite challenge records in a zone containing only challenge records. Your MX records, your production A records and your SPF policy are out of reach. cert-manager documents this pattern for Kubernetes, and the same shape works for certbot, lego, acme.sh and anything else that speaks dns-01.

One constraint to plan around before it bites: only one CNAME can exist at a given name, so each name can delegate its challenge to exactly one solver. If two systems both want to answer challenges for the same hostname, one of them has to lose. Deciding that while you have three delegated names is easy; deciding it when you have two hundred is a migration.

Choosing, in the order the constraints apply

Work down the list and stop at the first line that matches. The order matters, because the earlier constraints are absolute and the later ones are preferences. Almost every real argument about challenge types is resolved by the first three questions, and the remaining choice is usually between something you can automate today and something you would rather run.

Two additions once the choice is made. Set up delegation on day one if you land on dns-01, because retrofitting it across a large estate is far more work than starting with it. And check whether your certificate authority offers an ACME endpoint at all before you plan around one: Certum, for instance, lets you activate an ordered SSL certificate for ACME from the certificate's details, and our SSL certificate range is worth reading with that in mind if automation is part of your requirements.

Nothing stops you using more than one. A fleet where public web servers run http-01 and internal appliances run dns-01 is a reasonable outcome, not a sign of an inconsistent design. What is worth avoiding is a fleet where nobody can say which name uses which, because that is the estate where a shrinking reuse window finds the gaps first.

FAQ