Choose an ACME challenge by what the system can control: a public HTTP endpoint on port 80, public DNS records, or a capable TLS endpoint on port 443. Wildcard requirements and the actual CA/client implementation limit the available choices. The chosen path must remain available for renewal as well as initial issuance.
This guide compares HTTP-01, DNS-01 and TLS-ALPN-01 for public domain names, using Let’s Encrypt’s documented behavior where provider rules matter. It covers web servers, CDNs, private origins and Kubernetes, including the difference between a reachable application and a working challenge responder. No challenge guarantees speed, uninterrupted service or permanent unattended operation; verify the prerequisites for your own deployment.
How ACME Validates Domain Control
The client creates an ACME order, proves control of the requested names through supported challenges, and completes issuance when the CA’s other requirements are satisfied. HTTP-01 serves a designated response, DNS-01 publishes a designated TXT value, and TLS-ALPN-01 presents a special temporary certificate in a TLS handshake. Validation success is one stage; CAA authorization, final issuance and deployment remain separate requirements.
The response is tied to the challenge and ACME account. HTTP-01 uses a key authorization derived from the token and account-key thumbprint. DNS-01 uses a base64url-encoded SHA-256 digest of that value. TLS-ALPN-01 puts the expected digest in a critical certificate extension. Let the ACME client construct these values; publishing only the raw token is not generally sufficient.
Identify the network and DNS layers the CA will actually observe. A CDN can terminate the connection before it reaches the origin, a load balancer can choose a different backend on each request, and split-horizon DNS can show the client a different answer from public resolvers. A local self-check does not demonstrate that every external validation perspective can retrieve the same proof.
Choose a supported method whose access can be maintained over time. HTTP routing may be easier to operate for one service, while delegated DNS validation may fit another. A future change of DNS provider, ingress controller or CA can change those assumptions. Record ownership of the challenge path and test again after changes rather than treating the initial certificate as proof of continuing reliability.
HTTP-01: Validation over Port 80
With HTTP-01, the CA starts at http://example.com/.well-known/acme-challenge/<TOKEN> on port 80. The server must return the client-generated key authorization for that challenge. This method can fit a public site without wildcard requirements when the whole path is controllable. A successful ordinary homepage request does not prove the challenge URL is reachable or returns the correct content.
A webroot client can write the response where the existing web server serves it, allowing that server to keep listening. A standalone client instead starts its own HTTP listener and needs the relevant port available. It cannot bind the same address and port already used by Nginx or Apache. Confirm the installed client’s supported mode, permissions and deployment hook before enabling scheduled renewal.
HTTP-01 requires the initial public connection on port 80. Let’s Encrypt follows up to ten redirects, accepts only HTTP or HTTPS destinations on ports 80 or 443, and does not validate the certificate when following an HTTPS redirect. These are provider-specific redirect rules, not permission to close port 80. An unreachable initial endpoint cannot be repaired by a redirect it never receives.
A CDN, WAF or reverse proxy can block the challenge, route it to application authentication, or return an old cached 404. Exempt only the challenge path from behavior that interferes with the correct response. Clearing a previous cached error and preventing new caching are separate actions. Do not disable security controls for the entire site merely to make one validation URL reachable.
Every frontend or address the validator may reach must serve the correct response. Use shared challenge storage or explicit routing to a capable central responder where appropriate. Sticky sessions alone do not ensure all independent validators arrive at a server holding the file. An Ingress controller may route to a solver rather than implement the ACME response itself; verify which component actually owns that function.
Check the requested hostname, its A and AAAA paths, and the exact challenge URL from outside the local network. Global canonical-host or HTTPS redirects can work only if the provider accepts the chain and the destination still serves the intended response. Avoid accidentally sending the challenge to a login page, application route or nonexistent path. A test file confirms routing, not the complete ACME issuance process.
HTTP-01 is a reasonable option when a public website or API has a maintainable challenge route and needs no wildcard coverage. CDN or WAF use does not by itself rule it out; the deciding condition is whether all relevant requests can reach the current response. Schedule renewal checks and verify that the resulting certificate is loaded at the real TLS endpoint rather than assuming webroot setup makes future renewals automatic.
Use another supported path when port 80 is inaccessible, the HTTP route cannot be maintained, or wildcard coverage is required. A CDN that terminates TLS does not inherently prevent HTTP-01: its port-80 routing and challenge support are what matter. Separate that case from TLS-ALPN-01, where the certificate presented during the external handshake is itself the proof.
DNS-01: Validation through Public TXT Records
For example.com, DNS-01 publishes the client-generated value at _acme-challenge.example.com; for api.example.com, the owner is _acme-challenge.api.example.com. The CA must be able to resolve the required TXT publicly. This removes the need for a web challenge request to the origin but still depends on authoritative DNS availability, correct publication and valid authorization for the requested name.
For Let’s Encrypt, DNS-01 is the method among these three that supports wildcard issuance. *.example.com covers one matching label such as app.example.com, not example.com or api.app.example.com. When apex and wildcard authorizations overlap at the same challenge owner, multiple active TXT values may be needed. Keep each active value until its corresponding validation is complete.
DNS-01 can validate a public domain name whose application server is not exposed to the internet. The service may be behind a CDN, tunnel or access gateway, while the required TXT remains publicly resolvable. This does not issue certificates for arbitrary private names or remove normal CA requirements. It also does not configure the resulting certificate at the origin, edge or gateway for you.
Unattended renewal needs a supported way to update the validation records, commonly a DNS API or a delegated zone with such an interface. Manual TXT updates may work for individual challenges but leave a recurring dependency on a person. Restrict credential scope where the provider permits it and verify that the selected client can create, inspect and safely remove the required records.
Wait for authoritative publication and relevant caches before starting validation. Provider propagation, positive TTL and negative caching are separate factors; lowering a TXT TTL does not purge old responses or make the provider update faster. Check all authoritative locations the CA might reach, recognizing that anycast can expose different instances. Use supported propagation checks and suitable timeouts rather than assuming a fixed short delay always works.
For customer-domain SaaS, DNS-01 requires customer authorization to update DNS or a deliberate delegation of the challenge owner. An application CNAME alone does not supply that authorization path. HTTP-01 can also be centralized when tenant names route to a suitable responder; DNS-01 is not inherently the only scalable design. The SaaS custom-domain and DNS-01 guide discusses delegated validation and the associated automation responsibilities.
With multiple DNS providers, the current challenge values must be visible from every authoritative server that can answer for the owner. Coordinate writers and cleanup to avoid one process deleting another active TXT value. The octoDNS multi-provider DNS guide addresses configuration management; confirm how transient challenge updates coexist with that desired state, especially during provider migration.
CAA authorization applies independently of the chosen challenge. A fallback provider must be allowed for every requested identifier, including the applicable wildcard policy. Supported account and method constraints must match the real order. The CAA records guide explains record selection and these limits. Publishing a valid TXT does not override CAA, and changing CAA does not revoke a certificate already issued.
TLS-ALPN-01: Validation at the TLS Endpoint
TLS-ALPN-01 uses a public TCP connection on port 443 with SNI for the domain and the ALPN protocol identifier acme-tls/1. The responder presents a temporary self-signed certificate containing exactly that DNS SAN and a critical acmeIdentifier extension with the expected digest. An ordinary website certificate is not sufficient. The protocol uses TLS 1.2 or later and carries no subsequent application data.
This can fit an environment where port 80 is unavailable, no wildcard is needed and the public TLS endpoint explicitly supports the challenge. Verify both client and proxy capabilities in their current versions. Merely supporting TLS, SNI or ALPN does not imply TLS-ALPN-01 support, and the method does not work through an otherwise closed or inaccessible port 443.
The external endpoint must present the challenge certificate itself or pass the TLS connection through without terminating it to a capable responder. Passing SNI or ALPN metadata to an origin after TLS termination is insufficient. If a managed CDN lacks the required challenge support or passthrough, consider DNS-01 instead. Test the actual production network path; a direct-origin test can miss this difference.
TLS-ALPN-01 does not validate wildcard identifiers. It also needs coordination where many domains or frontends share the listener: every possible validation path must return the appropriate temporary response without allowing one tenant to validate another’s name. Keep normal certificate selection separate from challenge handling and remove temporary challenge material when the operation completes.
RFC 8555 specifies ACME and its HTTP/DNS challenges; RFC 8737 defines TLS-ALPN-01 and the critical certificate extension. Let’s Encrypt’s challenge guide provides its current implementation requirements. Use these alongside the actual client documentation instead of assuming all ACME tools implement the same challenge types or configuration options.
Choosing a Method for Your Architecture
The following scenarios illustrate selection criteria, not guaranteed deployment outcomes. For each one, establish the certificate names, endpoint ownership, challenge reachability and renewal process first. Then verify the issued certificate at the service users connect to. A topology that permits validation can still have a broken deployment hook or an incompatible certificate chain.
For a WordPress site on a VPS with direct public port-80 access, HTTP-01 through a webroot may fit. Keep the challenge URL outside interfering application authentication and rewrite rules. A standalone responder needs a free listening port, so it cannot be assumed to coexist with the active web server. Verify scheduled renewal and the server’s supported reload/deployment behavior after issuance.
For a CDN-backed site, inspect whether the CDN can serve or forward the current HTTP challenge response. If this path cannot be maintained, DNS-01 may separate origin issuance from HTTP handling, provided the DNS automation is authorized and supported. The edge certificate can have a separate owner and lifecycle; renewing the origin does not establish that the browser-facing edge certificate changed.
For tenant names under *.example.com, use DNS-01 with appropriate key scope and automation. Explicitly add the apex or deeper names if needed. A new matching hostname may use the same certificate, but still needs routing and a TLS endpoint that loads it. Protect a shared wildcard key according to its full authority; convenient name coverage does not remove renewal or compromise-response responsibilities.
For a private origin behind a tunnel, do not infer TLS-ALPN-01 support from application reachability. The public port-443 terminator must handle the special certificate or provide real passthrough. Otherwise DNS-01 may fit. The Cloudflare Tunnel private-publishing guide addresses a related application-routing architecture; a tunnel configuration alone is not an ACME challenge implementation.
For customer-domain onboarding, choose between an authorized, reachable HTTP challenge route and explicitly delegated DNS validation. Delegating _acme-challenge.example.com does not automatically cover the different owner _acme-challenge.api.example.com. Keep customer ownership, exact challenge destinations and deprovisioning procedures clear. DNS visibility, CA processing and quotas still affect onboarding time, so do not promise instant certificate issuance.
In Kubernetes, cert-manager’s documented ACME solvers are HTTP01 and DNS01; do not assume TLS-ALPN-01 support. For HTTP01, cert-manager creates temporary acmesolver Pods and Services and configures routing; the Ingress controller routes traffic to that responder. Select the appropriate ingressClassName or controller-specific option and allow the solver path through NetworkPolicy. The redundant ACME automation guide covers a separate client strategy and does not automatically configure cert-manager failover.
Building and Monitoring Renewal Automation
Renewal automation should preserve account and certificate state, report failures promptly and leave time for recovery. Check the selected client’s challenge and provider support, DNS permissions, routing behavior and deployment hooks. Monitor both the automation result and the live endpoint: a successful job can leave an old certificate in service if a reload or external deployment failed.
For HTTP-01, route the exact challenge URL to a current responder without application authentication or response rewriting. Use a maintained shared store or central responder where multiple nodes need consistent access. Accepted redirects are provider-dependent; an outright prohibition on all redirects is unnecessary, while assuming every redirect works is unsafe. Test each externally reachable frontend and both published address families.
For DNS-01, use narrow credentials and keep them outside the application repository. Let’s Encrypt can follow CNAME or NS delegation, but the client must also know where to write. cert-manager does not follow CNAME targets for updates by default; its delegated-CNAME flow requires cnameStrategy: Follow and credentials for the target zone. A delegation at one challenge owner is not a universal subtree solution for differently placed owners. Keep concurrent TXT cleanup precise.
For TLS-ALPN-01, verify the exact public connection path, selected SNI, acme-tls/1 negotiation and required temporary certificate. Test all relevant frontends and preserve tenant boundaries. A CDN or Ingress label does not establish whether this works; its actual termination and routing capabilities do. Never replace the ordinary site certificate with the temporary challenge certificate as a general deployment step.
Use a supported staging environment where the provider offers one. Let’s Encrypt staging has separate accounts, limits and untrusted test chains; do not distribute its certificates to the live service. Production still needs the correct account and deployment checks. A backup CA needs separate preparation, as discussed in the acme.sh fallback guide; shared DNS or validation failures may affect both providers.
Alert on failed renewals and monitor remaining validity at critical endpoints. Record the CA error, account identifier, requested names and deployment result without logging private keys or DNS API secrets. Follow supported ARI guidance or the certificate’s actual validity period with recovery margin. Avoid fixed assumptions about a universal lifetime or an alert only one day before expiry.
Before changing provider, verify the relevant CAA permissions and any account or validation-method constraints. DNS cache timing can delay a policy change even after authoritative publication. A shorter TTL affects new caching, not previously cached positive or negative answers. Check the actual failure category rather than repeatedly changing challenge types or generating more orders in response to a quota error.
Protect and back up ACME account state with appropriate access controls. Rebuilding a client under a new account can change its identity and conflict with an accounturi restriction; a new account does not bypass every issuance limit. Restore the intended state when appropriate and document deliberate account migrations. Certificate private keys have a separate lifecycle and must also be protected and rotated when required.
Questions to Resolve Before Deployment
First determine whether wildcard coverage is needed. Then establish whether public port 80 can serve a correct response, whether authorized public DNS updates are available, and whether the public port-443 terminator explicitly supports TLS-ALPN-01. Restrict the choice to methods actually supported by the CA and installed client. Prefer the route your team can operate and verify consistently.
For DNS-01, confirm the exact TXT owner, any CNAME/NS delegation, credential scope and publication checks. For HTTP-01, examine redirects, CDN caching and all frontends. For TLS-ALPN-01, verify the special certificate at the external TLS boundary. For SaaS, include customer authorization and removal procedures; avoid treating a traffic CNAME or wildcard as unlimited authority to serve unrelated customer names.
Finally, identify who maintains the challenge path and who responds when renewal fails. Keep the issued certificate’s names, expiration, active endpoint and owning account visible. Repeat relevant checks after network, DNS, controller or account changes. The goal is a demonstrably functioning renewal path with recovery time, not an unsupported claim that certificate management will never need attention.
Common Failure Scenarios
A CDN can cache a failed HTTP challenge response and continue returning it after the origin is corrected. Inspect the external result, purge the stale entry where needed and configure appropriate challenge-path handling. DNS-01 is an alternative only when its authorization and update path have been prepared. Switching methods under a deadline can introduce new failures if DNS credentials or propagation behavior are untested.
A policy that closes port 80 rules out HTTP-01 on that path, but does not prove which alternative is compliant or operationally suitable. DNS-01 can work through public DNS; TLS-ALPN-01 requires a capable and reachable public 443 responder. Assess the actual written requirement and topology rather than declaring an unspecified compliance rule satisfied merely because the challenge uses HTTPS-related transport.
A wildcard can simplify coverage for matching tenant labels while leaving important duties intact. Renewal, endpoint deployment, private-key protection and name routing still need owners. The apex and deeper labels may need separate coverage. A compromised wildcard key retains its scope until the affected certificate and trust situation are addressed; issuing another certificate for one name does not erase that authority.
Verify Issuance and the Deployed Certificate
HTTP-01 needs a reachable port-80 response, DNS-01 needs correct public TXT control, and TLS-ALPN-01 needs the special response at public TCP 443. Match these prerequisites to the actual infrastructure and supported client. Use DNS-01 for Let’s Encrypt wildcard issuance, and verify every requested name and applicable CAA condition. Challenge validation is only one part of completing the certificate workflow.
Keep failure reporting, account state and deployment checks aligned with the selected method. The octoDNS multi-provider guide and redundant CA automation guide discuss related designs with their own prerequisites. Neither DNS redundancy nor additional CAA permissions alone creates automatic recovery. Test the paths the production workflow will actually use and allow enough time to correct failures before expiry.
Consider the rollout complete only after the issued certificate matches the requested names and private key, presents the intended chain and is visible at the real TLS endpoint. Retain the evidence needed to investigate the next failure and maintain the challenge path for renewal. Reassess the method when provider capabilities or architecture change, rather than assuming one successful issuance proves the system will remain reliable indefinitely.
