Automatic HTTPS
Choose advanced certificate automation
Understand when DNS challenges, wildcard certificates, and on-demand TLS are justified and what new risks they add.
10 minute lesson
The default challenges cover most sites. Before reaching for the advanced options, make sure you actually need them, because each one adds authority that can be abused.
The DNS challenge proves domain control by creating a DNS TXT record instead of answering a request on your server. Caddy needs a DNS provider module compiled in — this is the main reason custom xcaddy builds exist — plus an API credential for your DNS host:
*.example.com {
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
respond "wildcard site"
}
Two situations justify it. Wildcard certificates, which ACME only issues through the DNS challenge. And origins that cannot accept traffic on ports 80 and 443, like a server behind a strict firewall.
The cost is that API token. Anyone holding it can change your DNS, which is close to owning your domain. Scope the token to the one zone it needs, keep it out of the Caddyfile itself — the {env.…} placeholder reads it from the environment — and rotate it if you ever suspect a leak.
On-demand TLS goes further: Caddy obtains a certificate during the TLS handshake, the first time it ever sees a hostname. It exists for SaaS platforms serving customer domains that are unknown at deploy time.
{
on_demand_tls {
ask http://127.0.0.1:5555/check
}
}
https:// {
tls {
on_demand
}
respond "customer site"
}
The ask endpoint is the safety control. Before issuing, Caddy calls it with the hostname and only proceeds on a 200 response — your app answers the question “is this a real customer?”. Without that permission check, anyone who points a DNS name at your server can make you request certificates, burning CA rate limits and disk on garbage names. Never enable on-demand issuance without it.
My advice: write the decision down before touching configuration. Something like this:
need wildcard: no
ports 80/443 reachable: yes
hostnames known at deploy time: yes
choice: default automatic HTTPS
If your answers match those, the default setup is right and you’re done. If not, add the smallest advanced feature that changes the blocking answer, and test it against the staging CA first, exactly like the previous lesson.
Lesson completed