Automated TLS certificate issuance looks simple from the outside. An ACME client requests a certificate, a certificate authority creates a challenge, the client proves control of the requested domain, and the CA issues the certificate. Once the process has been automated, certificate renewal can happen without an administrator manually generating a CSR, uploading validation files, or downloading a replacement certificate.
The interesting engineering problem is what happens between those steps.
A certificate authority cannot issue a certificate simply because an ACME client claims to control example.com. The CA needs independently verifiable evidence that the requester controls the identifier for which the certificate is being requested. ACME provides several challenge mechanisms for establishing that control, with HTTP-01 and DNS-01 being two of the most commonly used.
The two mechanisms prove domain control through different infrastructure paths. HTTP-01 places a challenge response into the HTTP serving path, while DNS-01 places a cryptographically derived value into the DNS hierarchy. That difference determines which systems participate in validation, which credentials the automation requires, and where certificate issuance can fail.
This becomes more important in modern environments where the ACME client may run inside Kubernetes, behind a reverse proxy, alongside a load balancer, or on infrastructure that does not directly control the public DNS zone. The certificate request may originate from one system while the proof required to complete that request is controlled by several other systems.
Understanding ACME therefore requires looking beyond the certificate request itself.
ACME Is Really a Domain-Control Verification Protocol
At a high level, an ACME certificate request creates a relationship between an identifier, an ACME account, an authorization, a challenge, and a validation result.
A simplified flow looks like this:
ACME Client
|
| Create Order
v
Certificate Authority
|
| Authorization
v
Challenge Object
/ \
/ \
HTTP-01 DNS-01
| |
v v
HTTP Resource DNS TXT Record
| |
v v
HTTP Validation DNS Validation
\ /
\ /
v v
Authorization
|
v
Certificate
The important property is that the CA performs the validation itself. The ACME client does not simply tell the CA that it created the required resource. Instead, the client changes something externally observable, and the CA checks that change through its own validation infrastructure.
For HTTP-01, that externally observable change is an HTTP resource. For DNS-01, it is a TXT record under _acme-challenge.
Both mechanisms therefore establish domain control, but they expose that proof through different infrastructure layers.
This dependency-oriented view is important because cryptographic behavior rarely exists in only one component. Michael Carter's article on cryptographic dependencies and algorithm agility describes how an application can depend on cryptography through TLS libraries, certificates, providers, infrastructure, HSMs, and other layers without having a single component called "cryptography."
ACME has a similar property. The certificate request may originate from an ACME client, while successful validation depends on a web server, load balancer, DNS provider, authoritative nameserver, network path, or another infrastructure component.
The Cryptographic Value Behind an ACME Challenge
HTTP-01 and DNS-01 are not based on arbitrary values chosen by the ACME client. An ACME authorization contains a challenge token, and the client uses that token together with information derived from its ACME account key to construct the value required by the challenge.
The relationship can be represented conceptually as:
ACME Challenge Token
|
+
|
ACME Account Key Thumbprint
|
v
Key Authorization
For HTTP-01, the resulting key authorization is made available through the HTTP challenge resource.
For DNS-01, the key authorization is hashed with SHA-256 and encoded using base64url before being published as the TXT record.
The simplified difference is:
HTTP-01
token + account-key-thumbprint
|
v
key authorization
|
v
HTTP response
DNS-01
token + account-key-thumbprint
|
v
key authorization
|
v
SHA-256
|
v
base64url
|
v
DNS TXT record
This is why the DNS-01 record is not simply a random secret associated with a certificate request. The value is derived from the ACME challenge and the account's cryptographic identity, allowing the CA to independently determine what value should be present.
That cryptographic relationship also makes the ACME account key part of the certificate automation architecture. It is not just another application credential that happens to be stored next to the certificate configuration.
How HTTP-01 Works Internally
Suppose an ACME client requests a certificate for:
example.com
The CA creates an authorization for that identifier and provides an HTTP-01 challenge containing a token. The ACME client calculates the corresponding key authorization and makes it available through the standardized challenge location:
http://example.com/.well-known/acme-challenge/<TOKEN>
The validation process then looks roughly like this:
ACME Client
|
| receives challenge
v
Calculate key authorization
|
v
Expose challenge response
|
v
/.well-known/acme-challenge/TOKEN
|
| HTTP request
v
CA Validation Server
|
v
Read response
|
v
Compare expected value
|
v
Authorization succeeds
The important part is that the CA retrieves the resource itself. The ACME client cannot satisfy the challenge merely by submitting the expected value through the ACME API.
The CA needs to see the proof through the domain's externally reachable HTTP path.
This means HTTP-01 creates a dependency between certificate issuance and the web infrastructure responsible for serving that domain.
Why /.well-known/acme-challenge/ Matters
The challenge location is standardized so that the CA knows where to retrieve the proof.
The ACME client cannot arbitrarily choose an endpoint such as:
https://example.com/my-acme-token
Instead, the expected location is:
http://example.com/.well-known/acme-challenge/<TOKEN>
An ACME client can implement this using a temporary file, a dynamic HTTP handler, an ingress route, a dedicated challenge server, or another mechanism appropriate to the environment. The implementation can vary, but the externally visible behavior must remain compatible with the CA's validation process.
This becomes more complicated when the web server is not actually the first system receiving the request.
A production request path might look like:
Internet
|
v
CDN / WAF
|
v
Load Balancer
|
v
Reverse Proxy / Ingress
|
v
Application or Challenge Handler
The ACME client may control only the final component.
Every layer above it can influence whether validation succeeds.
What Happens When HTTP-01 Meets a Load Balancer?
Consider a cluster with three application nodes:
Load Balancer
/ | \
/ | \
Node A Node B Node C
The ACME client creates the challenge on Node A. The CA sends an HTTP request to the public hostname, but the load balancer routes that request to Node C.
If Node C does not have access to the challenge response, the CA receives the wrong result and the authorization fails.
Nothing necessarily has to be wrong with the ACME client.
The problem is that the externally visible HTTP path does not correspond to the location where the challenge was created.
Distributed environments therefore need a consistent challenge-serving mechanism. That might involve shared challenge state, centralized routing, an ingress controller, or a dedicated validation handler that is available independently of individual application instances.
This is one reason certificate automation becomes an infrastructure problem rather than merely a certificate-management task.
HTTP-01 Depends on the Complete HTTP Path
The same dependency exists at other layers.
A CDN can cache an incorrect response. A WAF can block the validation request. A reverse proxy can rewrite the challenge path. An authentication layer can return 401 Unauthorized. An ingress controller can route the request to an application that has no knowledge of the challenge.
The resulting dependency chain can look like:
CA Validator
|
v
DNS
|
v
CDN
|
v
WAF
|
v
Load Balancer
|
v
Ingress
|
v
Challenge Handler
The certificate request can therefore appear to be failing at the ACME layer when the actual problem exists several network layers below it.
This is similar to the dependency problem discussed in Michael Carter's article about designing applications for cryptographic agility. A source-code or configuration view often does not reveal the complete cryptographic dependency chain.
For ACME, the equivalent mistake is checking only whether the client created the challenge instead of checking whether the CA can retrieve it.
Why HTTP-01 Uses HTTP
HTTP-01 has an important practical characteristic: the proof is delivered over HTTP.
That means an environment that is designed around HTTPS-only traffic still needs to account for the HTTP validation path during certificate issuance.
There is an apparent circular dependency:
Need certificate
|
v
Need domain validation
|
v
HTTP-01 challenge
|
v
Certificate not yet available
The solution is that the ACME challenge does not depend on the new certificate already being installed. The CA needs to retrieve the challenge response through the HTTP path before the certificate is issued.
An infrastructure policy that redirects or blocks every HTTP request without considering the ACME challenge can therefore interfere with certificate issuance.
The important question is not whether a site normally redirects HTTP traffic to HTTPS. It is whether the CA can reach the required challenge endpoint and receive the expected response.
DNS-01 Moves the Proof Into DNS
DNS-01 solves the same domain-control problem through a different infrastructure layer.
Instead of asking the CA to retrieve a resource from the web server, the ACME client creates a TXT record under:
_acme-challenge.example.com
The process looks like:
ACME Client
|
| receives DNS-01 challenge
v
Calculate key authorization
|
v
SHA-256 + base64url
|
v
Create TXT record
|
v
_acme-challenge.example.com
|
v
Authoritative DNS
|
| DNS query
v
CA Validation System
|
v
Authorization succeeds
The web server is no longer part of the domain-control proof.
That makes DNS-01 particularly useful when the certificate endpoint cannot expose an HTTP challenge, when certificate issuance is separated from application infrastructure, or when wildcard certificates are required.
But the complexity has not disappeared.
It has moved into DNS.
Why DNS-01 Uses a TXT Record
The TXT record contains the base64url-encoded SHA-256 digest of the key authorization.
Conceptually:
Token
+
Account Key Thumbprint
|
v
Key Authorization
|
v
SHA-256
|
v
Base64url
|
v
TXT Record
The record is placed beneath the _acme-challenge namespace associated with the identifier.
The CA then performs DNS resolution and checks whether the expected value is available.
The difference from HTTP-01 is therefore not simply that one uses HTTP and the other uses DNS. The proof is exposed through different control planes.
HTTP-01 requires control over the web-serving path.
DNS-01 requires control over the DNS namespace.
The DNS Validation Path Is Longer Than It Looks
A DNS-01 validation request does not necessarily travel directly from the CA to the system that created the record.
A simplified path is:
CA Validation System
|
v
Recursive Resolver
|
v
Authoritative Nameserver
|
v
_acme-challenge.example.com
The ACME client may successfully call the DNS provider API and receive a successful response. That only establishes that the provider accepted the API operation.
It does not necessarily mean that every DNS resolver involved in the validation path will immediately return the new TXT record.
This is one of the reasons DNS-01 failures can be confusing.
The automation may report:
TXT record created
while the CA still observes:
TXT record not found
Those statements can both be true at different points in the DNS resolution path.
Authoritative DNS and Recursive DNS Are Different Dependencies
Suppose the ACME client creates:
_acme-challenge.example.com
TXT "challenge-value"
The authoritative nameserver may already return the new record, while a recursive resolver still has a cached response from before the record was created.
The validation path therefore contains several independent components:
DNS API
|
v
Authoritative Zone
|
v
Authoritative Nameserver
|
v
Recursive Resolver
|
v
CA Validator
The record needs to become visible through the validation path used by the CA.
This means checking the DNS provider dashboard is not always sufficient when troubleshooting DNS-01. The more useful test is whether the authoritative DNS infrastructure and the resolver path expose the expected TXT value.
DNS Delegation Changes the Security Boundary
DNS-01 automation can also create a permissions problem.
An ACME client that has permission to modify the entire DNS zone may have considerably more authority than it actually needs.
For example:
ACME Client
|
| DNS API credential
v
example.com
|
+-- A
+-- AAAA
+-- MX
+-- CNAME
+-- TXT
+-- Other records
The ACME client only needs to establish domain control through the challenge namespace.
An organization can instead delegate _acme-challenge to a separate DNS zone:
example.com
|
+-- _acme-challenge
|
v
Dedicated DNS zone
|
v
ACME automation
This creates a narrower permission boundary and reduces the amount of DNS authority that needs to be granted to the certificate automation system.
At larger scale, that distinction becomes significant. Certificate automation may run across development, staging, production, multiple cloud environments, and hundreds or thousands of domains. Giving every ACME process unrestricted access to the primary DNS infrastructure increases the consequences of a compromised credential.
Why DNS-01 Can Validate Wildcard Certificates
One of the major technical differences between HTTP-01 and DNS-01 is wildcard support.
A wildcard identifier can look like:
*.example.com
A wildcard represents potentially many hostnames:
api.example.com
mail.example.com
app.example.com
service.example.com
There is no single application endpoint that inherently represents control over every hostname covered by that wildcard.
DNS provides a more appropriate control boundary because the proof is associated with the domain namespace rather than one specific HTTP service.
This is why DNS-01 is used when wildcard certificate issuance is required.
The important point is not simply that DNS-01 "supports wildcards." It is that the validation mechanism operates at a namespace level that is compatible with proving control over a wildcard identifier.
HTTP-01 and DNS-01 Create Different Dependency Graphs
The two mechanisms can therefore be represented as separate infrastructure graphs.
HTTP-01:
ACME Client
|
v
Challenge Handler
|
v
Ingress / Reverse Proxy
|
v
Load Balancer
|
v
CDN / WAF
|
v
CA Validator
DNS-01:
ACME Client
|
v
DNS Provider API
|
v
Authoritative DNS
|
v
DNS Delegation
|
v
Resolver
|
v
CA Validator
Neither mechanism is universally simpler.
They move complexity into different parts of the infrastructure. HTTP-01 makes web routing and public reachability part of certificate issuance, while DNS-01 makes DNS authority and record management part of certificate issuance.
That makes challenge selection an architectural decision rather than merely a configuration preference.
ACME Validation Is Only One Part of Certificate Automation
A successful ACME challenge does not mean that the new certificate is already protecting production traffic.
The broader lifecycle looks more like:
Domain Validation
|
v
Certificate Issuance
|
v
Certificate Storage
|
v
Certificate Deployment
|
v
TLS Endpoint Reload
|
v
Certificate Served
|
v
Renewal
Each stage can fail independently.
The CA can successfully validate the domain while certificate deployment fails. The certificate can be stored correctly while the load balancer continues serving the previous certificate. A new certificate can reach one production node while another node continues serving the old certificate.
This is why certificate issuance and certificate deployment should be treated as separate operational events.
A useful supporting reference is CompareCheapSSL's discussion of certificate lifecycle management, which separates issuance, deployment, monitoring, renewal, and revocation rather than treating certificate issuance as the entire lifecycle.
That is the only CompareCheapSSL link needed in this article.
The ACME Account Key Is Another Cryptographic Dependency
The ACME account itself has cryptographic state.
The account key is used to authenticate operations associated with the ACME account and participates in the construction of the key authorization used during challenges.
The relationship can be simplified as:
ACME Account
|
v
Account Key
|
v
Key Thumbprint
|
v
Key Authorization
|
+----------+
| |
v v
HTTP-01 DNS-01
This means certificate automation has cryptographic credentials with their own lifecycle.
The ACME account key should therefore be distinguished from the private key associated with the certificate being issued.
Conceptually:
ACME Account Credentials
|
+-- Account Private Key
TLS Certificate Credentials
|
+-- Certificate
+-- TLS Private Key
The account key participates in ACME protocol operations, while the TLS private key is used by the TLS endpoint to authenticate the service.
Treating these as the same category of secret can make certificate automation harder to reason about and harder to secure.
What Can Break HTTP-01?
The most useful way to troubleshoot HTTP-01 is to follow the validation path from the CA toward the challenge handler.
DNS can point the domain to the wrong infrastructure. Port 80 may be unreachable. A CDN may cache an old response. A WAF may block the request. A reverse proxy may rewrite the path. A load balancer may route the request to a node that does not contain the challenge. An authentication layer may intercept the request before it reaches the ACME handler.
The resulting diagnostic path is:
DNS
|
v
Public IP
|
v
HTTP Reachability
|
v
Proxy / CDN
|
v
Load Balancer
|
v
Challenge Route
|
v
Expected Key Authorization
Checking only whether the ACME client generated the challenge does not test this entire path.
The useful question is whether the CA can retrieve exactly the response it expects from the public endpoint.
What Can Break DNS-01?
DNS-01 has an equivalent dependency chain.
The DNS API credential may lack permission to modify the required zone. The TXT record may be created under the wrong name. DNS delegation may point _acme-challenge somewhere unexpected. Authoritative nameservers may return inconsistent data. Recursive resolvers may still contain cached responses.
The diagnostic path is:
ACME Client
|
v
DNS API
|
v
DNS Zone
|
v
Authoritative Nameserver
|
v
Resolver
|
v
CA Validator
The ACME client receiving a successful API response proves only that the DNS provider accepted the change. It does not prove that the CA can observe the expected value.
That distinction is fundamental when debugging automated certificate issuance.
Supporting ACME Is Not the Same as Operating ACME Reliably
An ACME client can correctly implement the protocol and still operate unreliably in production.
The protocol defines how the client and CA interact, but it does not eliminate the infrastructure dependencies around the challenge.
A production ACME deployment therefore needs visibility into several layers:
ACME Protocol
|
+-----------+-----------+
| |
HTTP-01 DNS-01
| |
Web Infrastructure DNS Infrastructure
| |
+-----------+-----------+
|
Certificate
|
Deployment
|
TLS Endpoint
This is the same architectural principle that appears in Michael Carter's discussion of post-quantum TLS and cryptographic implementation dependencies. The protocol can remain recognizable while the underlying cryptographic and infrastructure dependencies change significantly.
With ACME, the protocol remains relatively straightforward, but the environment through which the proof travels determines whether automation succeeds.
Designing ACME Automation Around Failure
A basic implementation usually focuses on the successful sequence:
Request
↓
Validate
↓
Issue
↓
Deploy
A production implementation needs to model failure at every stage.
For HTTP-01, that means observing DNS resolution, HTTP reachability, challenge routing, response correctness, and authorization status.
For DNS-01, it means observing DNS API operations, record creation, authoritative visibility, delegation, resolver behavior, and validation status.
After issuance, the monitoring needs to continue into deployment:
Challenge
|
v
Validation
|
v
Issuance
|
v
Storage
|
v
Deployment
|
v
TLS Endpoint
|
v
External Verification
The final verification is particularly important because a CA can confirm that it issued a certificate without guaranteeing that every production TLS endpoint is actually serving it.
The operational objective is therefore not simply:
Certificate issued
It is:
Certificate issued
+
Certificate deployed
+
Correct certificate externally verified
That is the difference between certificate automation that works during initial setup and certificate automation that remains reliable throughout the certificate lifecycle.
HTTP-01 and DNS-01 Are Two Different Proof Paths
HTTP-01 and DNS-01 are often introduced as two choices inside an ACME client configuration.
Internally, they represent two different ways of making domain-control evidence observable to a certificate authority.
HTTP-01 places the proof into the HTTP request path:
Cryptographic Proof
|
v
HTTP Resource
|
v
Web Infrastructure
|
v
CA Validation
DNS-01 places the proof into the DNS namespace:
Cryptographic Proof
|
v
DNS TXT Record
|
v
DNS Infrastructure
|
v
CA Validation
The cryptographic relationship behind the challenge remains tied to the ACME account, but the infrastructure carrying that proof changes.
That distinction explains why HTTP-01 can become difficult behind load balancers, why DNS-01 can become difficult with complex DNS delegation, why wildcard certificates require DNS-01, and why certificate automation needs to be designed around the infrastructure surrounding ACME rather than around the ACME client alone.
Final Thoughts
ACME transformed certificate issuance by turning domain validation and certificate requests into an automated protocol. But automation does not remove the underlying trust relationships. It turns those relationships into an executable workflow.
HTTP-01 requires the CA to reach a predictable HTTP endpoint and retrieve the expected key authorization. DNS-01 moves the proof into a DNS TXT record and allows the CA to verify domain control through the DNS hierarchy. Both mechanisms ultimately connect externally observable evidence to the cryptographic identity of the ACME account.
The engineering complexity appears in the systems surrounding those proofs.
With HTTP-01, the important dependencies include DNS, HTTP reachability, CDNs, WAFs, load balancers, reverse proxies, ingress controllers, and challenge handlers. With DNS-01, the dependency chain moves toward DNS APIs, authoritative nameservers, delegation, resolver behavior, permissions, and record visibility.
That is why ACME should not be viewed simply as a command that obtains an SSL certificate.
It is a protocol operating inside a larger infrastructure dependency chain.
A reliable implementation needs to answer where the challenge is created, where the proof is published, how the CA reaches it, which systems can modify or block the validation path, which credentials are involved, and what happens after the certificate has been issued.
The certificate request is only one part of the system.
The real engineering problem is making the entire validation and deployment chain observable, repeatable, and resilient to failure.
Top comments (0)