Caddy's on-demand TLS asks an endpoint before it issues a certificate for
a hostname it has not seen. The reference PDS answers that at /tls-check,
and its installer and deploy recipes configure Caddy with
on_demand_tls { ask http://localhost:3000/tls-check }. Without the
route, a deployment with Caddy as its only TLS layer and no DNS plugin
has no safe way to get certificates for handles under its service handle
domains.
The answers mirror the reference's service/index.ts: 400 for a missing domain or one outside PDS_SERVICE_HANDLE_DOMAINS, 200 for the server's own hostname and for a held handle, 404 for an unheld one. The own hostname is PDS_HOSTNAME, else the did:web host, via crawl::public_hostname, so HttpState now carries PDS_HOSTNAME.
A handle counts as held on the same terms as /.well-known/atproto-did: lowercased, and only when the account allows public reads. So a deactivated handle passes, where the reference's getAccount excludes it.
Additive only: a deployment on a wildcard certificate never asks, and the route reveals nothing atproto-did does not.
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com
