TLS & Certificates: Is the HTTPS Certificate Valid?
Using openssl to inspect a certificate's chain, expiry date, and hostname match by hand.
Tools required: openssl
Overview
Browser padlock warnings almost always trace back to one of a handful of causes: an expired certificate, a broken chain, a hostname mismatch, or a self-signed certificate the browser doesn't trust. openssl lets you see exactly which one, instead of guessing from the browser's generic warning.
Step-by-Step Manual Check
Connect and inspect the raw TLS handshake
openssl s_client performs the exact same handshake a browser does, but shows you the full certificate chain and negotiated protocol instead of hiding it behind a padlock icon.
openssl s_client -connect example.com:443 -servername example.com-servername is required for sites using SNI (almost all modern sites) - without it you may see the wrong certificate.
Healthy result
Verify return code: 0 (ok) --- Certificate chain 0 s:CN=example.com i:C=US, O=DigiCert Inc, CN=DigiCert Global CA (chain shown with no errors, ends in 'Verify return code: 0')
Problem result
Verify return code: 10 (certificate has expired) -- OR -- Verify return code: 18 (self-signed certificate) -- OR -- Verify return code: 21 (unable to verify the first certificate)
What it means
Code 10 = expired, needs renewal. Code 18 = self-signed, the browser will never trust this without a manual exception - needs a real CA-issued cert. Code 21 = the server isn't sending its intermediate certificate(s), even though the leaf cert itself might be fine - this is one of the most common 'works in some browsers, not others' causes.
If unresolved, escalate to: Level 2 — Intermediate
Check the exact expiry date and remaining days
Pull just the validity dates directly rather than reading through the whole handshake output.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -datesOn Windows, run this inside Git Bash or WSL - the echo-pipe trick doesn't work directly in PowerShell/cmd.
Healthy result
notBefore=Jun 20 00:00:00 2026 GMT notAfter=Oct 18 23:59:59 2026 GMT (notAfter is comfortably in the future - more than 30 days away)
Problem result
notAfter=Jul 10 23:59:59 2026 GMT (a date that has already passed, or is only a few days away)
What it means
Anything under 30 days should be treated as needing urgent renewal - most CAs and monitoring tools flag 30 days as the warning threshold, 7 days as critical.
If unresolved, escalate to: Level 2 — Intermediate
Confirm the certificate actually covers this hostname
A perfectly valid, unexpired certificate can still trigger browser warnings if it was issued for a different domain or missing the specific subdomain being used.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"Healthy result
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com
(the exact hostname you're checking is listed)Problem result
X509v3 Subject Alternative Name:
DNS:otherdomain.com
(your hostname is not listed anywhere in the SAN list)What it means
Browsers only trust the hostname if it appears explicitly in the Subject Alternative Name list (the old practice of matching only the Subject CN is deprecated and no longer trusted by modern browsers). A missing SAN entry means you need a new certificate that explicitly includes this hostname.
If unresolved, escalate to: Level 3 — Expert / Critical
Cross-check in the browser's own certificate viewer
Confirms what a real visitor sees, and is a faster way to communicate the issue to a non-technical stakeholder than pasting openssl output.
Click the padlock icon in the address bar > Connection is secure > Certificate is valid (Chrome/Edge)Healthy result
Issued by a recognized CA, valid dates shown, no warning icons.
Problem result
"Not Secure" in the address bar, or a full-page warning like "Your connection is not private" (NET::ERR_CERT_DATE_INVALID / NET::ERR_CERT_COMMON_NAME_INVALID).
What it means
The specific error code in the browser warning (visible if you click 'Advanced') maps directly to the openssl findings above - DATE_INVALID = expiry (Step 2), COMMON_NAME_INVALID = hostname/SAN mismatch (Step 3), AUTHORITY_INVALID = chain/self-signed problem (Step 1).
If unresolved, escalate to: Level 1 — Basic
Interpreting the Results
Certificate problems almost always fall into exactly one of four buckets: expired, self-signed/untrusted CA, broken chain (missing intermediate), or hostname/SAN mismatch. Identify which bucket first (Step 1's verify return code tells you immediately), then act on that specific cause rather than just re-issuing blindly.
Common Causes
| Symptom | Likely Cause | Fix |
|---|---|---|
| Works in curl/Chrome but fails in older browsers or some corporate networks | Missing intermediate certificate in the chain (verify code 21) | Configure the server to send the full chain, not just the leaf certificate. |
| Certificate valid but browser still blocks it | Hostname/SAN mismatch - visiting via a different subdomain than the cert covers | Reissue the certificate with all required hostnames in the SAN list. |
| Warning appeared suddenly with no site changes | Certificate simply expired on its scheduled date | Renew and reinstall - see the Certificate/PFX Management guide. |
Automated by
Diagnostic Suite - Site Latency Diagnostic (Option 2)
Automatically runs the equivalent TLS handshake and certificate analysis (version, cipher, expiry, SAN, chain) and produces a PDF report - this exact check, done for you.