Caddy's on-demand TLS obtains a certificate during the TLS handshake for a hostname it has never been configured with. What does that make possible, what is the abuse risk, and what control contains it?

## Two different modes of the same feature Caddy's ordinary automatic HTTPS is **config-driven**: the set of names is known when the config loads, and Caddy obtains certificates for exactly those names in the background. On-demand TLS is **traffic-driven**: the set of names is unknown, and a certificate is obtained during the TLS handshake for whatever hostname the client asked for. In the Caddyfile it is enabled per site with the `tls` directive: ``` https:// { tls { on_demand } reverse_proxy localhost:8080 } ``` and the permission check is configured once in the global options block with `on_demand_tls { ask <url> }`. ## The problem it solves The motivating case is a SaaS with **customer custom domains**. Thousands of tenants each want their storefront on their own hostname. Without on-demand TLS you have to enumerate every tenant hostname in config, obtain certificates for all of them ahead of time, and reload every time a tenant is added or removed — a control-plane job with its own queue, its own failures and its own latency between "customer added a domain" and "HTTPS works". On-demand collapses that to: the customer points DNS at you, and the first handshake produces a certificate. The same shape shows up in white-label products, vanity domains, and platforms that host user-supplied sites. ## Why it is dangerous unrestricted Everything that makes it convenient makes it attackable, because the trigger is **an inbound handshake from an unauthenticated stranger**: - **Issuance amplification.** Anyone can point any DNS name they control at your IP and cause an issuance attempt. Those attempts count against the CA's limits for whatever domains are involved and against your account's order limits — so a stranger can get you rate-limited, which then blocks issuance for your *legitimate* tenants. - **Handshake-time cost.** Each unknown name means a synchronous decision and potentially a full ACME order inside a connection setup. That is CPU and latency an attacker chooses the volume of. - **Storage growth.** Every certificate obtained is written to storage and then maintained and renewed forever unless something prunes it. - **Failed-attempt churn.** Names that will never validate still cost you the attempt, repeatedly, as clients retry. Note what is *not* on this list: an attacker cannot obtain a certificate for a domain they do not control. Validation is still validation. The damage is to your issuance budget and your capacity, not to anyone else's identity. ## The control: the ask endpoint The `ask` setting names an HTTP URL that Caddy consults **before** it attempts issuance for an unrecognised name. Caddy makes a request carrying the candidate hostname as the `domain` query parameter; a success response permits issuance, anything else denies it. In the JSON configuration this is expressed as an on-demand permission module rather than a bare setting, and modern Caddy requires a permission check to be configured before it will enable on-demand at all — the older approach of bounding the damage with issuance interval and burst limits was not a real defence, because a rate limit still lets the attacker consume the whole budget, just more slowly. The endpoint is where your actual policy lives, and it should be cheap and strict: - look the hostname up in the tenant database and approve only domains a paying, verified tenant has registered; - verify the tenant has completed whatever domain-ownership step you require, so the DNS pointing at you is intentional; - answer fast and cache, because this call sits inside a handshake; - fail closed on your own errors — a database outage should deny new issuance, not approve everything. ## Scoping On-demand belongs on the site block that serves tenant traffic, and only there. Your own hostnames should stay config-driven so that their certificates are obtained proactively at startup rather than lazily on first request — you do not want your primary domain's certificate to depend on a handshake arriving, or on the ask endpoint being up. ## What to say about operating it Monitor the ratio of approvals to denials and the absolute rate of issuance; a spike in denials is someone probing you, and a spike in approvals is either growth or a bug in your tenant lookup. Alert on approaching CA limits rather than discovering them during an outage. And have a plan for pruning certificates for tenants who left, because on-demand adds names to storage and nothing removes them for you.