OpenSSL s_client can show the certificate list sent by a TLS server. Inspect the server actually reached, its leaf certificate, validity dates and subject alternative names before drawing a conclusion about a certificate problem.
Diagnostic steps
- Use the application’s actual hostname for both the connection target and SNI when testing that site. example.com is a placeholder in these examples.
- Inspect the server-sent certificate list. The -showcerts output is not, by itself, a verified certificate chain.
- Save the leaf certificate PEM block to leaf.pem, then inspect its subject, issuer, notBefore, notAfter and subjectAltName fields.
- For a verification test, use the intended hostname and an appropriate trusted CA store. Read the verification result instead of treating an established TLS connection as proof that all checks passed.
- If a reverse proxy or TLS-inspecting network device is involved, compare the certificate presented at the relevant endpoint and document any difference.
Commands
openssl s_client -connect example.com:443 -servername example.com -showcertsopenssl x509 -in leaf.pem -noout -subject -issuer -dates -ext subjectAltNameopenssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_errorKey takeaways
- The certificate file configured on a server may differ from the certificate actually presented through a proxy or load balancer.
- A server usually sends its leaf and required intermediate certificates, rather than relying on a client to trust a supplied root.
- Use a matching hostname and the intended trust store. Ignoring validation errors does not repair a certificate problem.