Use local HTTPS

You should develop against HTTPS, not HTTP. Secure cookies, service workers, and mixed-content rules all behave differently over TLS, and you want to discover that on your laptop, not in production.

Caddy makes this painless. For localhost and other internal names it doesn’t contact a public CA. It creates its own local certificate authority and issues certificates from it.

localhost {
  respond "local HTTPS works"
}

Run it:

caddy run --config Caddyfile

On first run, Caddy generates the local CA and issues a certificate for localhost. It also tries to install the CA root into your system trust store, which may prompt for your password.

Test it:

curl https://localhost/

If you get the response body, the trust installation worked. If curl complains about an untrusted certificate, install the root explicitly:

caddy trust

caddy trust asks the running Caddy instance for its root certificate and installs it into your local trust stores. Retry the curl, then look at who signed the certificate you’re trusting:

curl -v https://localhost/ 2>&1 | grep issuer

The issuer names the Caddy Local Authority. You’re not talking to Let’s Encrypt here — you’re trusting a CA that lives in Caddy’s data directory on this machine.

Now the part that trips people up. Trust lives per client, per machine. Your browser works, but a Docker container hitting your host fails, your phone on the same Wi-Fi fails, and a colleague’s laptop fails. Each has its own trust store that has never heard of your Caddy root. The server cannot push trust to clients — that’s the entire point of a trust store. Export the root from Caddy’s data directory, under pki/authorities/local, and install it on each device you administer. Only on devices you administer.

Keep the local CA local. Never use it for a public site, and never install its root on machines you don’t control.