Users' browsers reject a web server's TLS certificate even though it is within its validity period and its subject alternative name matches the hostname. Packet capture shows the server sends only its own leaf certificate, which was issued by an intermediate CA. What is the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
Trust works like a reference chain: your browser trusts the root, the root vouches for the intermediate, and the intermediate vouches for the server. Skip the middle link and the chain falls apart. Don't overthink it — hostname and dates were fine, so check what the server is actually sending.
Full Explanation
Certificate validation requires the client to build a path from the server's leaf certificate to a root CA in its trust store. Public CAs issue server certificates from intermediate CAs, and the root signs the intermediate. The server is expected to send its leaf plus the intermediate certificates; the client already holds the root. When the server sends only the leaf, a client that cannot locate the intermediate elsewhere cannot verify the issuer's signature and rejects the certificate as untrusted, even though hostname and validity are correct. Some browsers mask this by caching intermediates or fetching them, which explains why such failures appear inconsistently across clients. A 2048-bit RSA key remains the common baseline for public server certificates and is accepted by current browsers. Browsers cannot see how a server stores its private key; the handshake proves possession of the key, not its protection on disk. Serial numbers are unique per issuing CA, and browsers do not consult DNS to compare serials across sites. Exam caveat: an untrusted private root produces the same symptom, which is fixed by distributing the root, not the intermediate. Operational check: run openssl s_client with the showcerts option against the server, confirm the chain includes the intermediate, and install the full chain bundle on the server.