How it works
Browsers and mail servers don’t trust individual certificates directly. They trust a limited set of root certificates in their trust store. Root CAs rarely sign server certificates themselves; they sign one or two intermediate CAs, which in turn issue the server certificate. The chain therefore runs from the server (leaf) certificate through the intermediates up to a root the client trusts.
In the handshake the server has to send its own certificate plus every intermediate, but not the root. With Let’s Encrypt that is the fullchain.pem file; configuring cert.pem instead serves the leaf alone.
A self-signed certificate is its own issuer: subject and issuer are identical and no public CA vouches for it. That’s fine for internal testing, but on the public internet it is the same as a broken chain. Common culprits are the default certificates of reverse proxies such as Traefik or of hosting panels, served whenever no proper certificate is set up for a hostname.
Why it matters
A missing intermediate is sneaky because desktop browsers often hide it: many fetch it from the URL inside the certificate or already have it cached. curl, PHP, Java, older Android devices, payment services and webhooks don’t, and they drop the connection. The result is seemingly random failures that “work on my machine.”
A self-signed or foreign default certificate triggers a full-page browser warning. On mail servers, senders using MTA-STS or DANE stop delivering; senders without them keep encrypting but no longer verify who they are talking to.
How to prevent it
- Always install the full chain: fullchain.pem for Let’s Encrypt, or the CA bundle in the right order (leaf first, then the intermediates) for purchased certificates.
- Test from the outside after every installation, for example with openssl s_client -connect example.com:443 -servername example.com -showcerts, and look for “Verify return code: 0 (ok)”.
- Let the ACME client or hosting platform supply the chain instead of hard-coding an old bundle file – CAs rotate their intermediates regularly.
- Give every publicly reachable hostname a real certificate or delete its DNS record, so no proxy default certificate is ever served.
- Keep self-signed certificates internal and give mail servers a public certificate whose name matches the MX hostname.
How DomainWarn detects it
The Certificate check verifies the chain the server sends against the common root store without fetching missing intermediates – just like curl or a mail server would. An incomplete or untrusted chain produces the finding “The certificate chain does not verify” with the exact reason (for example “unable to verify the first certificate”), and a self-signed certificate the finding “The certificate is self-signed”. Both are critical and open the “Certificate invalid” incident after two runs; the intermediates are listed with issuer and expiry date in the result.
For mail servers the SMTP check validates the chain via STARTTLS (incident “Mail server certificate invalid”), and the Subdomain inventory finds hostnames serving a proxy’s self-signed default certificate (incident “Invalid certificate on a subdomain”).
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.