In ACME, what does each of http-01, dns-01 and tls-alpn-01 prove, and which one can satisfy a wildcard identifier?

middlemust knowfreq 72%

answer

same value, three places to publish it
token plus account key thumbprint
port 80, the zone, or port 443
underscore label holds the hashed value
wildcard leaves only the DNS type

basics

~20 s

Each ACME challenge proves control of a different layer for one name: http-01 of the HTTP service on port 80, dns-01 of the zone that answers for the name, tls-alpn-01 of the TLS service on port 443. Only dns-01 satisfies a wildcard.

solid answer

~40 s

All three carry the same value, the keyAuthorization — the challenge token joined to a thumbprint of the account key — and differ only in where it is published. http-01 serves it at /.well-known/acme-challenge/<token> over plain HTTP on port 80, so it proves control of whatever answers HTTP for that name. dns-01 publishes a hash of it in a TXT record at _acme-challenge.<name>, proving control of the zone. tls-alpn-01 (RFC 8737) answers a handshake on port 443 negotiated with the acme-tls/1 application protocol, presenting a self-signed certificate carrying the value in the id-pe-acmeIdentifier extension. A wildcard authorization, flagged wildcard: true, is offered only dns-01, because the other two need a service at one exact name.

All three carry the same value, the `keyAuthorization` — the challenge `token` joined to a thumbprint of the account key — and differ only in where it is published. `http-01` serves it at `/.well-known/acme-challenge/<token>` over plain HTTP on port 80, so it proves control of whatever answers HTTP for that name. `dns-01` publishes a hash of it in a TXT record at `_acme-challenge.<name>`, proving control of the zone. `tls-alpn-01` (RFC 8737) answers a handshake on port 443 negotiated with the `acme-tls/1` application protocol, presenting a self-signed certificate carrying the value in the `id-pe-acmeIdentifier` extension. A wildcard authorization, flagged `wildcard: true`, is offered only `dns-01`, because the other two need a service at one exact name.

code

http · 7 lines

http

GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 HTTP/1.1
Host: popup-camden.shop.example

HTTP/1.1 200 OK
Content-Length: 87

LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI

go deeper

for a junior

Recall that there are three ways to prove control of a name and that they differ by layer: a file over HTTP, a DNS record, or a TLS handshake. Know that a wildcard needs the DNS one.

for a middle

Explain the key authorization and why the same value works in all three places, and state precisely where each answer is published, including the port and the underscore label.

for a senior

Show the operational reasoning: which type survives a shared edge, which survives a closed port 80, and why the choice has to be revisited when a name moves rather than only when issuance fails.

for a principal

Weigh giving automation write access to a production DNS zone against keeping validation on the service, and decide which blast radius the estate can live with.

The value they all carry

Every challenge has a token, a random value the server hands out, and the client answers with the key authorization: the token, a dot, and a base64url-encoded thumbprint of the account's public key. This is not a secret — the token travels in a response the client fetched and the account public key is known to the server — and treating it as one is a common misreading. Its job is binding: it ties that token to one account, so a token observed by a third party cannot be answered by a different account's key, and a server validating the answer learns which account proved control.

The three types

Challenge	Where the answer is published	What it proves
`http-01`	`http://<name>/.well-known/acme-challenge/<token>`, port 80	control of the HTTP service the name resolves to
`dns-01`	TXT record at `_acme-challenge.<name>`, value is base64url of the SHA-256 of the key authorization	control of the DNS zone answering for the name
`tls-alpn-01`	a TLS handshake on port 443 negotiated with the application protocol `acme-tls/1`, answered with a self-signed certificate carrying the value in the `id-pe-acmeIdentifier` extension	control of the TLS service on port 443 for that name

The practical consequences follow directly:

http-01 is fixed to port 80 and plain HTTP. If a border blocks port 80, or an edge answers for the name before your service does, it cannot succeed no matter what is configured behind it. Redirects are followed, so a site that redirects to HTTPS still validates.
dns-01 needs programmatic control of the zone and tolerates propagation delay; it is the only type that works when nothing is listening on the name at all, which is exactly the case for a name that has been provisioned but not yet deployed.
tls-alpn-01 keeps everything on port 443 and needs no HTTP path, but the TLS terminator has to be able to answer one specific handshake with a special certificate — which means it only works where you control the terminator itself, not where a shared edge terminates for you.

Wildcards

An order may name *.shop.example. The authorization the server returns carries the identifier without the *. prefix and sets wildcard: true. On that authorization a server offers only dns-01. The reason is mechanical rather than arbitrary: a wildcard covers names that do not exist yet and may never resolve, so there is no HTTP service and no TLS service at which control could be demonstrated. Only the zone that would answer for those names can speak for all of them. A wildcard authorization also does not cover the bare name — shop.example needs its own identifier in the order.

Choosing one, and what changes at renewal

Is anything listening at the name today? If not, dns-01 is the only workable choice.
Who terminates TLS? If a shared edge does, tls-alpn-01 is out of reach and http-01 depends on that edge forwarding the well-known path.
Do you need a wildcard? Then the decision is already made.

The choice is not settled once. A chain of pop-up stores that validates each new name with http-01 while the site is still served directly will find, the first time a name is moved behind a content delivery edge, that the challenge path no longer reaches its own service — and it will find it at renewal, weeks after the deploy that caused it. The failure is not "the certificate expired"; it is "the layer that proved control changed owner", and the fix is to switch the challenge type rather than to retry.

Identifier types

Orders are not limited to DNS names: RFC 8738 adds the ip identifier type for certificates covering an IP address, validated by the same http-01 and tls-alpn-01 mechanisms aimed at the address rather than a name. Wildcards have no meaning there.

A challenge is how an ACME server decides that the account asking for a certificate actually controls the name. All three standard types answer the same question and carry the same value; they differ in which layer of control they demand, and that difference is what makes one of them the right choice for a given deployment. ## The value they all carry Every challenge has a `token`, a random value the server hands out, and the client answers with the **key authorization**: the token, a dot, and a base64url-encoded thumbprint of the account's public key. This is not a secret — the token travels in a response the client fetched and the account public key is known to the server — and treating it as one is a common misreading. Its job is **binding**: it ties that token to one account, so a token observed by a third party cannot be answered by a different account's key, and a server validating the answer learns which account proved control. ## The three types | Challenge | Where the answer is published | What it proves | |---|---|---| | `http-01` | `http://<name>/.well-known/acme-challenge/<token>`, port 80 | control of the HTTP service the name resolves to | | `dns-01` | TXT record at `_acme-challenge.<name>`, value is base64url of the SHA-256 of the key authorization | control of the DNS zone answering for the name | | `tls-alpn-01` | a TLS handshake on port 443 negotiated with the application protocol `acme-tls/1`, answered with a self-signed certificate carrying the value in the `id-pe-acmeIdentifier` extension | control of the TLS service on port 443 for that name | The practical consequences follow directly: - `http-01` is fixed to **port 80** and plain HTTP. If a border blocks port 80, or an edge answers for the name before your service does, it cannot succeed no matter what is configured behind it. Redirects are followed, so a site that redirects to HTTPS still validates. - `dns-01` needs programmatic control of the zone and tolerates propagation delay; it is the only type that works when nothing is listening on the name at all, which is exactly the case for a name that has been provisioned but not yet deployed. - `tls-alpn-01` keeps everything on port 443 and needs no HTTP path, but the TLS terminator has to be able to answer one specific handshake with a special certificate — which means it only works where you control the terminator itself, not where a shared edge terminates for you. ## Wildcards An order may name `*.shop.example`. The authorization the server returns carries the identifier **without** the `*.` prefix and sets `wildcard: true`. On that authorization a server offers only `dns-01`. The reason is mechanical rather than arbitrary: a wildcard covers names that do not exist yet and may never resolve, so there is no HTTP service and no TLS service at which control could be demonstrated. Only the zone that would answer for those names can speak for all of them. A wildcard authorization also does not cover the bare name — `shop.example` needs its own identifier in the order. ## Choosing one, and what changes at renewal 1. **Is anything listening at the name today?** If not, `dns-01` is the only workable choice. 2. **Who terminates TLS?** If a shared edge does, `tls-alpn-01` is out of reach and `http-01` depends on that edge forwarding the well-known path. 3. **Do you need a wildcard?** Then the decision is already made. The choice is not settled once. A chain of pop-up stores that validates each new name with `http-01` while the site is still served directly will find, the first time a name is moved behind a content delivery edge, that the challenge path no longer reaches its own service — and it will find it at renewal, weeks after the deploy that caused it. The failure is not "the certificate expired"; it is "the layer that proved control changed owner", and the fix is to switch the challenge type rather than to retry. ## Identifier types Orders are not limited to DNS names: RFC 8738 adds the `ip` identifier type for certificates covering an IP address, validated by the same `http-01` and `tls-alpn-01` mechanisms aimed at the address rather than a name. Wildcards have no meaning there.

Why does a wildcard authorization show the identifier without the leading `*.`?
Because the identifier being validated is the zone label itself, and the `wildcard` boolean records that the order asked for the wildcard form. Keeping the two separate means the server validates control of `shop.example` once and knows it may issue for `*.shop.example`. It also makes the limit visible: that authorization does not cover the bare `shop.example` name, which needs its own identifier in the order.
A name sits behind a shared edge that terminates TLS. Which challenge types are still available?
`dns-01` always, because it never touches the service. `http-01` only if the edge forwards the `/.well-known/acme-challenge/` path to your origin rather than answering or redirecting it itself. `tls-alpn-01` is unavailable, because answering it means completing a handshake under the `acme-tls/1` protocol with a certificate you mint, and the edge owns that handshake.
What stops one account from answering a challenge token that belongs to another account's order?
The key authorization. The published value is the token joined to a thumbprint of the account key that the challenge was issued to, so republishing only the token proves nothing. A server validating the answer recomputes the expected value from the account it issued the token to, and a value derived from any other account key fails.

A challenge is like being told to hang one numbered card in a shop window: the number is issued to you alone, and the card appearing in that window is what proves the shop is yours to use. A wildcard is a card for shops on a street that have not opened yet, so only the street's landlord can hang it.

saying these in an interview costs you the question

Calls the key authorization a secret only the client knows
Says http-01 can validate a wildcard identifier
Thinks http-01 is fetched over HTTPS on port 443
Believes a challenge proves ownership of the registered domain
Assumes the DNS record name is the bare name, not the underscore label
Treats the three types as interchangeable regardless of deployment

In ACME, what does each of http-01, dns-01 and tls-alpn-01 prove, and which one can satisfy a wildcard identifier?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The value they all carry

The three types

Wildcards

Choosing one, and what changes at renewal

Identifier types

▾common follow-ups3 questions

▾analogy~20 s

▾red flags6 flags

The value they all carry

The three types

Wildcards

Choosing one, and what changes at renewal

Identifier types

answer

go deeper