Automatic HTTPS

Prepare public certificate issuance

Verify DNS, ports, permissions, and persistent storage before asking Caddy to obtain a public certificate.

10 minute lesson

~~~

Automatic HTTPS is one line of configuration and four external dependencies. When issuance fails, the Caddyfile is almost never the problem — the environment is. This lesson is the preflight checklist I run before pointing a real domain at a server.

First, DNS. The name must resolve to this machine, in both address families:

dig +short A app.example.com
dig +short AAAA app.example.com

Compare both answers against the server’s actual addresses. The sneaky one is a stale AAAA record: IPv4 points at the new server while IPv6 still points at the old one. The CA may validate over IPv6, fail, and leave you staring at a config that looks perfect.

Second, ports. ACME challenges arrive on port 80 for the HTTP challenge and port 443 for the TLS-ALPN challenge. Check that nothing else holds them:

sudo ss -lntp | grep -E ":80 |:443 "

If nginx or Apache is squatting on those ports, Caddy either fails to bind or never sees the challenge traffic. Your firewall and any cloud security group must allow both ports too.

Third, storage. Caddy keeps certificates, private keys, and its ACME account in a data directory. For the packaged Linux service that resolves to /var/lib/caddy/.local/share/caddy; you can confirm the environment Caddy sees with:

caddy environ

Two requirements: the caddy user can write there, and the directory survives deployments. In containers, that means a volume.

Why persistence matters: wipe the data directory on every deploy and Caddy requests fresh certificates on every deploy. That works until you hit the CA’s duplicate-certificate rate limit, and then issuance stops for days. The data directory is state, not cache. Never delete it casually.

Once all three checks pass, load the configuration and watch it happen:

journalctl -u caddy -f

You’ll see Caddy obtain the certificate, with log lines naming the challenge and the issuer. When something fails, the error names the failing step — DNS lookup, connection, or authorization — which tells you exactly which check to redo.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →