Reverse proxies and TLS

Certificates are issued lazily

Most proxies with automatic certificate management do not request anything at startup. The request happens on the first connection that carries a matching SNI. Watching the log after a restart and seeing nothing is therefore not a failure — it means nothing has asked yet.

The practical consequence is that the first request after a config change may time out or return no status at all while issuance happens in the background. The second request is the one that tells you anything.

HTTP-01 needs port 80 reachable from outside

The validating servers connect from the public internet to the name in DNS. If the A record points somewhere else, or the port is filtered, validation fails — regardless of how the service is configured locally.

Note

A CDN in front of the name breaks this too, because the challenge is answered by the CDN rather than the origin.

Testing with a hostname, not an address

When overriding DNS resolution for a single request, the URL must still contain the hostname. Pointing the client at an IP literal skips the override entirely and sends no SNI, so a server with virtual hosts has nothing to match against and closes the connection.

# no SNI is sent — the override is ignored
curl https://127.0.0.1:8443/ --resolve example.com:8443:127.0.0.1

# hostname in the URL, resolution overridden
curl https://example.com:8443/ --resolve example.com:8443:127.0.0.1