The Blocker Is the Challenge Type, Not the Tool

The ACME protocol requires you to prove you control a domain before it issues a certificate. That proof is the challenge, and there are three main types, each asking you to place specified content somewhere different: a path on your website, a DNS TXT record, or the TLS handshake itself.

Most tutorials hand you a single Certbot command, which defaults to HTTP-01. On a single machine facing the internet directly, that works. But add any architectural complexity — a CDN in front, several backends, or a need for wildcards — and HTTP-01 starts failing, usually without an error that says "you should be using a different challenge type".

Challenge How it works Constraints
HTTP-01 Serve a file at a specific path for the CA to fetch Needs port 80 open; fails behind CDNs and multi-node setups; no wildcards
DNS-01 Publish a specified TXT record under the domain Only option for wildcards; needs DNS API access and propagation waits
TLS-ALPN-01 Serve a special certificate during the TLS handshake Needs direct control of port 443; unusable behind a CDN; no wildcards
DNS-PERSIST-01 One standing authorisation record, no repeated updates IETF draft; check Let's Encrypt for current production availability
How the three ACME challenge types work and their hard constraints. The fourth row is a newer type not yet in production.

The table below sets out how each works and what constrains it. The third column is what should drive the decision.

Three Situations Where HTTP-01 Fails

HTTP-01 requires the CA to read a specific file from your server over the public internet. These three architectures break that assumption:

  1. The service sits behind a CDN The CA's request hits a CDN node first, while the validation file lives on the origin. Unless the CDN is configured to pass `/.well-known/acme-challenge/` through to the origin, the CA gets a cached response or a 404. This is the most common case for teams in Taiwan and Hong Kong, since cross-border services almost always front with a CDN.
  2. There are multiple backend servers The load balancer routes the CA's request to one machine at random, but the validation file only exists on whichever machine initiated the request. That's a 1-in-N hit rate, and each retry may land somewhere different. This failure is particularly irritating because it's intermittent — sometimes it passes, sometimes it doesn't.
  3. Port 80 isn't publicly open Where security policy closes port 80, or the service is only offered internally, HTTP-01 simply cannot work. That includes API domains you only want reachable from specific sources.

What DNS-01 Costs You

DNS-01 solves all of the above — it never needs the CA to reach your server, only to resolve a DNS record. So it doesn't matter whether you're behind a CDN, how many machines you run, or whether port 80 is open. That's why multi-node architectures almost always end up on DNS-01.

It carries its own cost, though. Every issuance requires adding a TXT record, meaning your automation must hold **DNS provider API credentials**. Those credentials have to reach every machine or CI environment that performs renewals — and DNS access is high-risk, since holding it means being able to repoint your domain.

Worth noting: in February 2026 Let's Encrypt proposed **DNS-PERSIST-01**, which replaces the repeated updates with a single standing authorisation record bound to a specific ACME account — aimed squarely at both pain points above. It remains an IETF draft; the announced production target was Q2 2026, so check Let's Encrypt's own announcements for current availability. Note too that once authorisation is persistent, protecting the ACME account key matters correspondingly more.

The Hard Constraint on Wildcards

If you need a wildcard like `*.example.com`, the decision is already made: **only DNS-01 can issue one**. Neither HTTP-01 nor TLS-ALPN-01 can produce wildcard certificates. This isn't a configuration issue; it's a protocol-level constraint.

It's worth knowing early, because it works backwards into your choice of DNS provider. If your registrar or DNS service offers no API, you can't automate DNS-01, which means no automatically-renewed wildcard — you'd be adding TXT records by hand every time. With lifetimes already at 200 days and heading to 47, manual handling isn't a viable long-term plan.

Three Implementation Decisions

In practice the choice reduces to three questions:

1. Is there a CDN or load balancer in front?

If so, rule out HTTP-01 and TLS-ALPN-01 and use DNS-01. You can force HTTP-01 to work by configuring the CDN to pass the validation path through to origin, but that's an extra special-case rule to maintain, and it's easily broken by unrelated CDN changes.

2. Do you need wildcard certificates?

If yes, DNS-01 is the only option. If your subdomains are few and stable, a SAN certificate listing them all avoids wildcards — but every new subdomain then requires reissuing, so weigh that against how often they change.

3. Does your DNS provider expose an API?

This is the prerequisite for DNS-01. When choosing a registrar or DNS service, treat API support as a requirement rather than a bonus. Plan credential storage too — putting DNS API keys directly in config files on every server turns your certificate automation into a security weakness.

Three Things to Establish First

Before configuring anything, settle these:

  1. List every domain and subdomain needing a certificate This determines whether you need wildcards, which determines the challenge type. Discovering the wildcard requirement afterwards means rebuilding the whole flow.
  2. Check your DNS provider's API and permission granularity Beyond whether an API exists, check whether it can issue scoped tokens limited to TXT records on specific domains. Full-access keys distributed across machines carry too much risk.
  3. Recognise that validation and deployment are separate Obtaining the certificate is step one. It still has to reach every TLS-terminating endpoint and take effect, which ACME tooling generally doesn't handle. Decide who owns that half before you start.

In Summary

The hard part of certificate automation was never installing Certbot; it's picking the right challenge for your actual architecture. The logic is short: **a CDN in front or a wildcard requirement means DNS-01** — and committing to DNS-01 means first confirming your DNS provider has an API, then managing that key carefully.

If you'd rather not handle DNS API key distribution and multi-node deployment yourself, our SSL automation platform combines validation and delivery in one flow: the platform performs DNS validation and pushes issued certificates straight to CDN nodes.

Sources