Troubleshooting¶
Fixes for the problems you are most likely to hit with Caddy HTTPS Gateway. Each entry gives the symptom, the usual cause, and what to do.
curl reports a certificate error on port 8443¶
Cause: the HTTPS listener uses a certificate from the instance's own local CA, which your system does not trust by default.
Fix: pass the public CA certificate to the client:
On your own computer, use a copy of that file. If you rebuilt the instance
or lost /var/lib/caddy/data, the CA changed: copy the new
local-root.crt to your clients.
The private path returns 401¶
Cause: /private/api/status.json needs HTTP basic auth, user pilot,
and the request had no password or the wrong one.
Fix: send the password from /etc/caddy/pilot.password, as shown in
Getting started. If you
changed the hash in the Caddyfile, use the password that matches it.
Nothing answers on 8080 or 8443¶
Cause: first boot has not finished, or Caddy failed to start.
Fix: check both services and their logs:
systemctl status sushi-caddy-firstboot caddy --no-pager
sudo journalctl -b -u sushi-caddy-firstboot -u caddy --no-pager
If you edited the Caddyfile, validate it (see Configuration) and fix any error before you restart Caddy.
I cannot reach the gateway from another machine¶
Cause: by design, every listener is on 127.0.0.1.
Fix: for your own access, use Session Manager port forwarding, as in Getting started. To serve other clients, change the Caddyfile and the security group yourself, as described in Serve a public name.
Caddy fails to start after I add a site on port 80 or 443¶
Cause: the service does not have permission to bind ports below 1024.
Fix: add AmbientCapabilities=CAP_NET_BIND_SERVICE with a drop-in and
restart, as described in Serve a public name.