Caddy As A TLS Front Door

caddy-https

Caddy as a TLS front door: HTTPS by default (its own CA for private names, Let's Encrypt for public ones), HTTP redirected, HSTS and the usual security headers on every response, no Server header, no admin API. Serves a directory or proxies an upstream. Original role for EL 10, live-tested with podman on Rocky Linux 10.

Caddy is in EPEL. AppStream on EL 10 does not carry it; the role enables EPEL first (caddy_https_enable_epel: false if you mirror it).

The package serves plain HTTP. Its Caddyfile is http:// on port 80 from /usr/share/caddy, and every response says Server: Caddy. Caddy's whole point is automatic HTTPS; the package configuration switches it off. This role writes a site block for a real address, and the live test proves HTTP answers with a permanent redirect to HTTPS.

Private names get real certificates too. tls internal makes Caddy run its own CA, so localhost, an internal hostname or an IP gets a certificate a client can verify against one root file (/var/lib/caddy/.local/share/caddy/pki/authorities/local/root.crt). The live test verifies the chain against exactly that file, with certificate checking on, and negotiates TLS 1.3. The role does not push that root into the host's trust store (skip_install_trust); distributing a CA root is a decision, not a side effect.

The admin API is off. Caddy listens on localhost:2019 by default and any local process can replace the running configuration through it. This role turns it off and restarts Caddy on changes instead of reloading through it; the live test reads the listening sockets and expects no :2019.

Public hostnames: set caddy_https_site_address to the name, caddy_https_tls: auto and caddy_https_acme_email; the role refuses auto without an email. Ports 80 and 443 must reach the host for the ACME challenge.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.