The problem
A platform with many subdomains, most of them private. The classic ACME challenge (HTTP-01) validates each name by serving a file on the public HTTP port. Something must therefore be exposed for every subdomain, including those that have no business being on the Internet. And every issued certificate records its name in the Certificate Transparency logs, which are public and continuously scanned: issuing one certificate per service amounts to publishing the map of your infrastructure.
The pattern
The DNS-01 challenge proves control of the domain rather than of a web
server. The ACME client sets a temporary TXT record
(_acme-challenge.<domain>) through the registrar’s API (OVH), Let’s
Encrypt verifies it, the certificate is issued. Consequences:
- No port to open. Validation goes through DNS rather than through the server.
- Wildcard possible (
*.domain.fr): a single certificate covers all subdomains, present and future, without enumerating them publicly. - Fully automatic renewal, integrated into the reverse proxy (Traefik’s ACME resolver), with no external cron or manual reload.
The pitfalls
- The API credential becomes the critical secret. Whoever can write to the DNS zone can issue certificates. The token must be limited to the strict minimum (rights on the relevant zone only) and handled as a first-class secret (secrets management).
- DNS propagation is not instantaneous. The ACME client must wait until the TXT record is visible to Let’s Encrypt’s resolvers. Delays and TTLs are configurable, otherwise failures are intermittent.
- Silent renewal must be monitored. Automatic does not mean guaranteed: an approaching expiration must raise an alert. It is one of the use cases for the observability planned on the roadmap.
When not to use it
A single public domain, no private subdomains, no reliable DNS API: HTTP-01 is simpler and sufficient. DNS-01 is worth its cost as soon as there is something private to protect or a wildcard to cover.