ACME validation: HTTP-01, DNS-01 and TLS-ALPN-01
The ACME protocol (RFC 8555) defines three methods for proving domain control. This guide explains when to use which, security considerations, and how DNS delegation and FairSSL AutoDNS simplify the setup.
Three validation methods
When you order a certificate via ACME, the CA must verify that you control the domain. This happens via one of three challenge types. The CA sends a challenge, your ACME client answers it, and the CA verifies the response.
| Method | What is proven | Port | Wildcards | Behind firewall |
|---|---|---|---|---|
| HTTP-01 | HTTP access to the domain | 80 (TCP) | No | No |
| DNS-01 | Control over DNS zone | None | Yes | Yes |
| TLS-ALPN-01 | TLS control over the domain | 443 (TCP) | No | No |
HTTP-01: file on port 80
The CA gives your ACME client a token. The client places a file with the token at
http://your-domain/.well-known/acme-challenge/TOKEN. The CA fetches the file via HTTP (port 80) and verifies the content.
How it works
- 1 The ACME client requests a certificate for
www.example.com - 2 The CA returns a token (random string)
- 3 The client places the file under
/.well-known/acme-challenge/ - 4 The CA fetches
http://www.example.com/.well-known/acme-challenge/TOKEN - 5 Content matches? Certificate is issued.
Important limitations
No redirects. The CA does not follow HTTP-to-HTTPS redirects during validation. If IIS or Nginx redirects all traffic from port 80 to 443, validation fails. Disable redirect rules for the /.well-known/acme-challenge/ path.
All SAN names must respond. If the certificate has 5 domain names (SAN), all 5 must answer HTTP-01 from the same server. One domain pointing elsewhere causes the entire validation to fail.
Load balancers. Behind a load balancer, the file must be available on all backend servers, or the load balancer must route /.well-known/acme-challenge/ to the server running the ACME client.
HTTP-01 is the simplest method for single-server setups where port 80 is available. For everything else, we recommend DNS-01.
DNS-01: TXT record in DNS
DNS-01 is the most flexible validation method. The ACME client creates a TXT record _acme-challenge.your-domain
in your DNS zone. The CA looks up the record via DNS and verifies the content. No ports need to be opened, and the server does not need to be exposed to the internet.
How DNS-01 works
- 1 The ACME client requests a certificate and receives a token from the CA
- 2 The client computes a SHA-256 hash of the token and account key
- 3 The client creates the TXT record:
_acme-challenge.example.com TXT "hashed-token-value" - 4 The CA performs DNS lookups (from multiple geographic locations via MPIC)
- 5 TXT record matches? Certificate is issued. The client cleans up (removes the TXT record).
Example: DNS-01 lookup
# Check if the TXT record has been created correctly nslookup -type=TXT _acme-challenge.example.com _acme-challenge.example.com text = "gfj9Xq...Rg85nM" # On Linux/Mac dig TXT _acme-challenge.example.com +short "gfj9Xq...Rg85nM"
TTL and propagation
The TXT record must propagate to the CA's DNS resolvers before validation can complete. A short TTL provides faster propagation and faster cleanup after validation.
Recommendation: Set TTL on _acme-challenge records to 60 seconds or lower.
Most ACME clients wait 30 seconds after creation (configurable). With 47-day certificates from 2029,
validation happens more frequently, and a short TTL ensures fast propagation every time.
DNS CNAME delegation (FairSSL AutoDNS)
Without delegation, DNS-01 requires the ACME client to have full access to your DNS API. This means API keys to your primary DNS provider on every server that needs to renew certificates. If one server is compromised, the attacker has access to modify all DNS records for your domain.
CNAME delegation eliminates that risk. You create a CNAME record pointing _acme-challenge
to a separate validation zone, dedicated to certificate validation. The server only has access to that zone,
not to your primary DNS. With FairSSL AutoDNS,
you do not even need that zone: FairSSL manages it for you.
How it works
The CA follows the CNAME chain automatically. It looks up _acme-challenge.your-domain,
sees the CNAME, follows it to the validation zone, and finds the TXT record there. Your primary DNS zone
is never involved beyond the single permanent CNAME.
Example: CNAME delegation
1. Create CNAME (one-time setup in your DNS)
_dnsauth.example.com CNAME your-unique-id.autodns.fairssl.dk.
2. During validation, FairSSL creates the TXT record
your-unique-id.autodns.fairssl.dk TXT "validation-token"
3. The CA resolves the chain
# CA looks up: _acme-challenge.example.com # → CNAME → your-unique-id.autodns.fairssl.dk # → TXT "hashed-token" ✓
Benefits of delegation
- No DNS API keys on the server
- Compromised server cannot modify your DNS
- Works with all DNS providers (including those without an API)
- CNAME is created once, then automatic
FairSSL AutoDNS
FairSSL AutoDNS is CNAME delegation as a managed service. You create one CNAME record, and FairSSL handles all TXT records automatically on each validation. No scripts, no API keys, no manual setup.
acme-dns: self-hosted alternative
acme-dns is an open source project that runs your own validation zone. Simple-acme, Lego and Certbot all have built-in acme-dns support. The downside is that you are responsible for operating and monitoring the DNS server.
TLS-ALPN-01: certificate on port 443
TLS-ALPN-01 (RFC 8737) is the newest validation method. The ACME client presents a self-signed certificate with a special ALPN extension on port 443. The CA makes a TLS connection and verifies the certificate.
The method was introduced as an alternative to the original TLS-SNI challenge, which was withdrawn in 2018 due to security issues with shared hosting environments.
Limited use in practice. TLS-ALPN-01 requires the ACME client to temporarily control port 443. This typically means the web server must be stopped during validation, causing downtime. In simple-acme, selfhosting mode binds port 443 directly. The main use case is servers where port 80 is blocked by policy but port 443 is available. For most scenarios, DNS-01 is a better choice.
Which method should I use?
Single web server, port 80 open
Use HTTP-01 if the server is already accessible from the internet on port 80.
It is the simplest setup. Note that all SAN names in the certificate must point to the server,
and HTTP-to-HTTPS redirect rules must exclude /.well-known/acme-challenge/.
Disallowed redirects on that path cause validation to fail.
Behind firewall, load balancer, or wildcard
Use DNS-01. No ports needed, works behind any firewall configuration. With FairSSL AutoDNS, you do not even need DNS API access.
Multiple servers / web farm
Use DNS-01. HTTP-01 requires all servers to serve the challenge file, which is cumbersome in a web farm. DNS-01 with CNAME delegation runs from a single central server.
Network equipment (firewalls, load balancers)
Use DNS-01 from an existing server. Network devices cannot run ACME clients, so a central server handles validation and deploys certificates via API/script. See ACME clients for setup strategy.
Port 80 blocked, port 443 available, no DNS access
Use TLS-ALPN-01. A rare scenario, but the only choice when HTTP is unavailable and DNS delegation is not possible.
Troubleshooting validation issues
DNS-01: "Timeout waiting for DNS propagation"
The TXT record is not yet visible to the CA. Check manually with nslookup -type=TXT _acme-challenge.your-domain 8.8.8.8
(use an external DNS resolver, not your local one). Typical causes: TTL too high on existing records, DNS provider with slow propagation,
or incorrect zone file. Increase DnsPropagationDelay in the client's configuration.
DNS-01: "Incorrect TXT record" (CNAME delegation)
The CNAME record is pointing incorrectly. Check: nslookup -type=CNAME _acme-challenge.your-domain. It should return the correct
delegation target. CNAME cannot coexist with other records on the same name. If you have an existing TXT record
on _acme-challenge, delete it before creating the CNAME.
HTTP-01: "Invalid response from [domain]"
The CA cannot fetch the challenge file. Possible causes: firewall blocking port 80,
domain pointing to the wrong IP (typical after a DNS change), or the web server returning an error page instead of the challenge file.
Test locally: curl -v http://your-domain/.well-known/acme-challenge/test.
HTTP-01: Redirect on the challenge path
Many web servers have a global HTTP-to-HTTPS redirect. This also catches requests to
/.well-known/acme-challenge/, and the CA rejects redirects on the challenge path.
Make sure your redirect rule excludes that path. In IIS: add a URL Rewrite condition.
In Nginx: place the location /.well-known/acme-challenge/ block before the redirect rule.
HTTP-01: Not all SAN names validate
HTTP-01 validates each SAN name individually. If the certificate contains your-domain.com
and www.your-domain.com, both names must respond on port 80 with the challenge file.
If www redirects to the apex domain (or vice versa), validation fails for that name.
Use DNS-01 instead if you have SAN names that do not all point to the same server.
CAA record blocks issuance
An error message mentioning "CAA" means your CAA DNS records do not allow the CA issuing the certificate.
FairSSL uses DigiCert (digicert.com), GlobalSign (globalsign.com) and Sectigo (sectigo.com).
Use our CAA Record Generator
to generate correct records. If you have no CAA records, all CAs are allowed.
MPIC failure: validation from one location but not others
From March 2025, CAs verify from multiple geographic locations (MPIC). If DNS or HTTP responds correctly from one location but not from others, it may be caused by geo-DNS, CDN configuration blocking certain regions, or asymmetric routing. Ensure the validation response is available globally, not just from your local network.
Related content
FairSSL AutoDNS
Automatic DNS validation with permanent CNAME. No DNS API keys.
Simple-ACME guide
Complete Windows guide with DNS validation, IIS and Task Scheduler.
CAA Record Generator
Generate CAA DNS records that control which CAs may issue certificates.
ACME clients
Comparison of all recommended ACME clients with DNS validation support.
Domain validation
Non-ACME domain validation: email, DNS TXT, HTTP file for DV certificates.
What is SSL?
Certificate chains, CAA records, HSTS and other security measures.
Frequently asked questions about ACME validation
Find answers to the most common questions about SSL certificates and FairSSL.
_acme-challenge.your-domain to a validation service (e.g. FairSSL AutoDNS or acme-dns). The server never touches your DNS zone directly. Even a compromised server cannot modify your DNS records.dig CAA your-domain and make sure the allowed CAs include those used by FairSSL (DigiCert, GlobalSign, Sectigo). Use our CAA Record Generator to generate correct records.Get started with SSL automation
Create a free account and issue your first certificate in under 10 minutes.