Caddy gets and renews certificates for the hostnames in its config and redirects HTTP to HTTPS, with no extra directives. It needs ports 80 and 443 reachable, DNS pointing at the server, and a writable, persistent data directory. Several common settings quietly switch the feature off.
What it does
According to the Caddy documentation, automatic HTTPS serves sites over HTTPS by default, obtains and renews certificates, and redirects HTTP on port 80 to HTTPS on port 443. Local names and IP addresses get certificates from Caddy's own local CA. Public domain names get certificates from a public ACME CA.
It activates when Caddy knows a hostname or IP address, for example from a Caddyfile site address.
What it needs for public names
- Ports 80 and 443 reachable from outside, or forwarded to Caddy's HTTP and HTTPS ports.
- The domain's A and AAAA records pointing to the server.
- A writable and persistent data directory.
- The domain present in the config.
The data directory is the one people lose. In a container with no volume, every restart looks like a new server and Caddy may request new certificates repeatedly, which can hit CA rate limits.
Issuers and challenges
Let's Encrypt and ZeroSSL are enabled by default, and if Let's Encrypt fails Caddy falls back to ZeroSSL. The HTTP challenge on port 80 and the TLS-ALPN challenge on port 443 are on by default. The DNS challenge needs provider configuration and no open ports, and enabling it disables the other challenges by default. Let's Encrypt requires DNS validation for wildcard certificates.
On failure, Caddy retries, switches challenge types, tries the next issuer, then backs off exponentially, with a maximum of one day between attempts and up to 30 days of retries.
For test setups, point the ACME endpoint at a staging URL to avoid production rate limits.
What switches it off
The docs list these: disabling it explicitly, giving no hostnames or IPs, listening only on the HTTP port, prefixing a site address with http://, or loading certificates manually. That http:// prefix is the usual accident. A site written as http://example.com is plain HTTP, and nobody will warn you.
Security notes
- Local certificates come from a root and intermediate CA Caddy generates, and the root is installed into the system trust store on first use. Treat that machine's CA files like any signing key.
- Check expiry from outside, not just from Caddy logs. The certificate expiry checklist and ACME renewal checklist apply here too.
- Automatic issuance only covers the certificate. Protocol and cipher choices, HSTS and backend encryption are still yours to review.
You can verify what a client sees with openssl s_client.
Where Safeguard fits
Safeguard does not issue certificates. It scans the dependencies and containers behind your web server and automates compliance evidence. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Why might Caddy serve plain HTTP for a site you thought was HTTPS?
A site address prefixed with http://, a config with no hostnames, or manually loaded certificates can disable automatic HTTPS.
Which challenge is needed for a wildcard certificate from Let's Encrypt?
The DNS challenge.
Sources
Last reviewed: 19 October 2026.
