Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
Mirrored from https://github.com/Slazee/caddy.git
Synced Nov 11, 04:45 UTC
httpcaddyfile: new `tls_automate_names` global option (#8015)
* httpcaddyfile: new tls_automate_names global option Provisioning a certificate for a name that is not served requires giving it a site block of its own: *.example.com { } foo.example.com { respond "Real site" } That asks the tls app for the wildcard, but it also adds a route to the http app, so every name pointed at the server that has no site block of its own -- bar.example.com here -- gets an empty but valid response rather than no match at all. Wanting a certificate and wanting to serve a name are separate things, and the Caddyfile had no way to say only the first. Name them in the new global option instead: { tls_automate_names *.example.com } foo.example.com { respond "Real site" } The names are added to the automate certificate loader and to an automation policy built from the global options, so a name listed here is managed exactly as it would be from a site block, with the same issuers; the only difference in the adapted config is that no route is added for it. Repeating the option appends rather than replaces, so a long list can be split over several lines. Names that cannot get a public certificate are given the internal issuer, the same treatment a site block gives them. Names that already appear in the automate list are skipped, but a name that also has a site block is left listed here as well: a site block for http:// only is not managed by auto-HTTPS, so dropping the name because a block exists could silently leave it without a certificate. The option needs no http app at all, so a config consisting only of global options now adapts to a tls app on its own -- enough to keep certificates renewed for a mail or XMPP server, or for names served by a layer 4 app. Closes #7122 * httpcaddyfile: reuse an existing policy for an automated name A name given to tls_automate_names may already have an automation policy from its own site block. Adding a second policy for the same subject is not just redundant: the adapter rejects overlapping subjects, so { email nobody@example.com tls_automate_names foo.example.com } foo.example.com { tls { ca https://acme.example.test/directory } } failed to adapt at all, with "hostname appears in more than one automation policy, making certificate management ambiguous". Keep such a name in the automate loader but leave its policy alone. The site block's policy is the more specific of the two, and the loader entry is still wanted, since a site block served only over HTTP is not managed by auto-HTTPS. * Pin that tls_automate_names overrides auto_https off The names given to the option are managed whether or not auto-HTTPS is disabled: unlike the hostless-key block above it, that code is not gated on auto_https, because naming a subject explicitly is a stronger signal than the general switch. Nothing enforced it, so add the adaptation fixture @steadytao asked for.