TLS certificate inspection with OpenSSL cheat sheet
Inspect the presented TLS certificate, hostname validation and certificate expiration using OpenSSL.
OpenSSL 3.x CLI and an approved TLS endpoint. Examples assume a POSIX shell and a PEM certificate file.
Updated · OpenSSL · 6 min read
| Command | What it does |
|---|---|
openssl version | Identify the OpenSSL version |
openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts </dev/null | Inspect the server-presented certificate chain |
openssl s_client -connect app.example.com:443 -servername app.example.com -verify_hostname app.example.com -verify_return_error </dev/null | Check hostname and certificate validation |
openssl x509 -in server.pem -noout -subject -issuer -dates | Inspect a saved certificate’s identity and dates |
openssl x509 -in server.pem -noout -ext subjectAltName | Inspect subject alternative names |
openssl x509 -in server.pem -checkend 604800 -noout | Check whether a certificate expires within seven days |
Walkthrough
Replace app.example.com and server.pem with the authorized hostname and certificate file. The s_client commands contact the remote service. Never share private keys or paste secrets into commands.
Step 1: Identify the OpenSSL version
openssl version
Record the OpenSSL release and compare supported options with the installed manual. Trust-store configuration and TLS behavior can vary across builds and platforms.
Step 2: Inspect the server-presented certificate chain
openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts </dev/null
Specify the hostname for SNI and inspect the returned certificates and handshake messages. A displayed chain is the server-provided chain, not necessarily a verified trust chain; output can include internal names.
Step 3: Check hostname and certificate validation
openssl s_client -connect app.example.com:443 -servername app.example.com -verify_hostname app.example.com -verify_return_error </dev/null
Use the expected DNS name for SNI and hostname verification. Trust depends on the OpenSSL trust store and any explicitly configured CA files; compare it with the client environment experiencing the issue.
Step 4: Inspect a saved certificate’s identity and dates
openssl x509 -in server.pem -noout -subject -issuer -dates
Read the subject, issuer and validity period from the public PEM certificate file. This command does not contact the server and cannot establish which certificate a load balancer is currently serving.
Step 5: Inspect subject alternative names
openssl x509 -in server.pem -noout -ext subjectAltName
Compare the DNS name clients use with the certificate subject alternative names. Hostname matching rules and wildcard scope matter; use explicit hostname verification as well as reading the extension.
Step 6: Check whether a certificate expires within seven days
openssl x509 -in server.pem -checkend 604800 -noout
The interval is in seconds. Use the command exit status with the output and confirm the file represents the certificate in question; this is not a complete chain or hostname validation.
WORKED INCIDENT
Practical case: A browser reports a certificate name mismatch
Fictional teaching scenario; observations are examples, not captured production output.
Situation
Users reach an HTTPS endpoint but the browser rejects the presented certificate.
Investigation sequence
1. Identify the OpenSSL version
openssl versionRecord the OpenSSL version and the hostname users actually enter.
2. Inspect the server-presented certificate chain
openssl s_client -connect app.example.com:443 -servername app.example.com -showcerts </dev/nullInspect the certificate presented with the expected SNI hostname.
3. Check hostname and certificate validation
openssl s_client -connect app.example.com:443 -servername app.example.com -verify_hostname app.example.com -verify_return_error </dev/nullRun explicit hostname verification using the same hostname.
4. Inspect subject alternative names
openssl x509 -in server.pem -noout -ext subjectAltNameCompare the public certificate subject alternative names with the requested host.
Example findings
Illustrative findings: the server presents a certificate for old.example.com and explicit verification for app.example.com fails.
Interpret the findings
The observed hostname mismatch explains the verification failure for this connection. It does not establish whether DNS, load-balancer selection or certificate deployment caused the wrong certificate to be presented.
Verify the outcome
After the certificate or endpoint owner corrects the approved configuration, repeat the hostname validation and test the normal browser path with trust checks enabled.
Escalation handoff
Provide the hostname, endpoint address, certificate issuer, validity dates and validation error to the certificate or load-balancer owner; never include private keys.