ACME Certificate Validation: tls-alpn-01 vs. DNS Challenges
ACME uses different domain-control validation methods. tls-alpn-01 works on shared hosting without DNS access; DNS challenges suit wildcard certificates but require external DNS control.
Fly.ioExplainer
Fly describes how its CDN automatically generates TLS certificates for customer hostnames with Let’s Encrypt and ACME, focusing on why the older tls-sni-01 validation method was unsafe on shared hosting. ACME authenticates an account with an ECDSA/EdDSA key, creates an order, and verifies domain control through challenges; Fly uses tls-alpn-01, which avoids requiring DNS access or port 80. For validation, Fly requests a challenge, creates a self-signed certificate containing Let’s Encrypt’s token, stores it in distributed certificate storage, and signals the CA to connect with a ClientHello selecting acme-tls/1 via ALPN. The Rust proxy recognizes that ALPN case, retrieves the challenge certificate, and serves it to Let’s Encrypt, which completes the challenge and permits certificate issuance. Fly assigns each application a unique routable IPv6 address and requires CNAME resolution to it for ALPN validation; wildcard certificates instead use DNS challenges.
Fly needs to generate certificates automatically for applications and customer domains. The post also explains that tls-sni-01 became unsafe because shared hosting providers could let users claim arbitrary names and upload certificates, enabling validation attacks against other hosted customers.
Fly uses Let’s Encrypt’s ACME tls-alpn-01 challenge. It embeds the issued token in a self-signed certificate, stores that certificate in distributed storage, and has a Rust proxy serve it when Let’s Encrypt connects with the acme-tls/1 ALPN protocol. Unique routable IPv6 addresses and CNAME checks mitigate domain-validation risks; DNS challenges support wildcard certificates.
The tls-sni-01 challenge was deprecated and removed after shared-hosting configurations allowed attackers to claim .invalid names and present token-bearing certificates for other customers’ domains.
The tls-alpn-01 flow uses a self-signed certificate containing Let’s Encrypt’s token; Fly’s proxy serves it specifically when the validation connection selects acme-tls/1 through ALPN.
Fly requires a hostname to resolve by CNAME to an application’s unique routable IPv6 address for ALPN validation. Wildcard certificate requests use DNS challenges instead.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
ACME uses different domain-control validation methods. tls-alpn-01 works on shared hosting without DNS access; DNS challenges suit wildcard certificates but require external DNS control.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.