In one paragraph
A missing intermediate certificate can prevent a client from building a trusted path from your server certificate to a trusted root. Some browsers compensate using cached or fetched intermediates, while other clients fail. Install the appropriate leaf-and-intermediate bundle at the actual TLS endpoint, verify it externally, and fix renewal automation so the incomplete chain does not return.
Why it matters
Certificate trust is a chain-building process. A server certificate is commonly issued by an intermediate authority whose certificate leads towards a root the client trusts. The server should provide the leaf and necessary intermediate certificates; clients normally obtain trust in the root from their own trust store, not from a root sent by the server.
A working browser is not enough to establish that the served chain is complete. Some clients have cached intermediates or can retrieve missing certificates, while others do neither. The result can be an integration that fails despite the site appearing normal on the maintainer's laptop. Browser and operating-system behaviour varies, so do not claim every browser always repairs an incomplete chain.
The same connection can fail for other reasons: an expired leaf, a hostname mismatch, a self-signed certificate, or a client trust store that does not contain the appropriate root. Read the actual verification error instead of assuming that every certificate finding is missing intermediates.
How WebAuditOS evaluates this finding
The supplied site-wide rule opens a TLS connection to the scanned origin and checks certificate verification and hostname matching. A valid verified connection passes. Verification failure or a handshake that fails or reaches the documented ten-second timeout fails. Non-HTTPS sites are not graded.
This is therefore a general certificate-validation check presented under the missing-intermediate topic, not a detector exclusive to that cause. The supplied examples include UNABLE_TO_VERIFY_LEAF_SIGNATURE, DEPTH_ZERO_SELF_SIGNED_CERT, ERR_TLS_CERT_ALTNAME_INVALID, and CERT_HAS_EXPIRED. Error strings can depend on the TLS runtime and failure circumstances; they are diagnostic evidence, not universal one-to-one mappings.
How to fix it
- Identify the public TLS termination point. If visitors connect to a CDN or load balancer, inspect its certificate configuration first. The origin's separate certificate matters to the edge-to-origin connection but may not be what the visitor or this scanner receives.
- Inspect the served chain for the intended hostname. For example:
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error -verify_hostname example.comReplace the hostname and port appropriately. Interpret the output with the client's trust-store configuration in mind. -showcerts displays certificates sent by the server; seeing multiple certificates alone does not prove the chain or hostname is valid.
- Obtain the correct intermediate bundle from the issuing certificate authority or your certificate automation. Do not use an unrelated certificate downloaded merely because its subject name looks similar. Check the issued leaf, its issuer, and the recommended chain for your certificate.
- Install the chain in the format your TLS server expects. In nginx, ssl_certificate should reference a PEM bundle containing the leaf first, followed by the intermediate certificates in chain order:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;Those paths are illustrative for a Certbot-style deployment. ssl_trusted_certificate serves a different trust configuration purpose and is not a substitute for the chain nginx must present through ssl_certificate.
- Validate configuration and reload the terminating service safely. Confirm that the certificate's private key matches the leaf without exposing that private key in logs, tickets, or shared files. On managed platforms, follow the provider's certificate upload or reissuance process rather than changing an unused origin file.
- Verify from outside your infrastructure, using the intended SNI hostname and a client that does not rely on a previously cached intermediate. Test both apex and www if they terminate separately, plus relevant API endpoints. Check multiple edge locations or instances if results are inconsistent.
- Repair renewal or deployment automation. It must install and activate the complete bundle after renewal, not copy only cert.pem or leave the old in-memory certificate loaded. Rescan the public endpoint once the actual served chain is correct.
What the fix can break
A malformed bundle, wrong certificate order, mismatched key, or incorrect file permissions can prevent a TLS service from reloading. Validate first and retain a tested deployment rollback.
A new intermediate or alternative chain can affect older client trust stores. Choose a chain supported by the issuing authority and test the clients your service actually supports rather than assuming all clients share a browser's trust configuration.
Do not include a root merely to make an untrusted chain trusted. Sending it does not add it to the client's trusted roots. For public web deployments, send the required intermediates and rely on an appropriate supported root path.
Questions
Why does my browser work while a webhook client fails?
They may build chains differently or use different trust stores. A cached or retrieved intermediate can hide a server-chain omission in one client. Inspect the chain actually sent by the server.
Does the server need to send the root certificate?
Usually not. The client must independently trust a root. The normal server bundle contains the leaf and required intermediates, not a root intended to create trust by being sent.
Will installing intermediates fix an expired certificate?
No. Expiry requires a renewed valid certificate. A hostname mismatch requires a certificate covering the requested hostname. Use the reported error to select the right remedy.
What should I review next?
Review HSTS only after certificate delivery is reliable, and use the website audit checklist for broader endpoint coverage.