Practical guide
How to inspect a TLS certificate
Use this page to check what certificate an endpoint actually serves, whether it is trusted, and whether it is close to expiration.
What this tool checks
The TLS inspector opens a TLS connection to the host and reads the certificate the server actually presents. The important fields are the subject and SAN names, the issuer, the validity window (not-before and not-after), the certificate chain, the fingerprint, and the trust status. Because it reflects the live endpoint, it catches cases where the served certificate differs from what your certificate provider says was issued.
When to use it
Use it before renewing a certificate, after changing a CDN or load balancer, when users report browser warnings, or when a domain serves the wrong certificate. It is also useful after any deployment, because backend and edge systems can serve different certificates if one layer was missed during a rollout.
How to read the result
First confirm the requested hostname appears in the subject alternative name list — browsers match on SANs, not the legacy Common Name. Then check the not-before and not-after dates, the issuer, and whether the chain is trusted. A certificate can be valid and still wrong if it does not cover the exact hostname your users visit, so the name match matters as much as the dates.
Common TLS findings and how to fix them
| Finding | What it means | Common fix |
|---|---|---|
| Certificate expired | The not-after date is in the past | Renew and deploy the new certificate to every endpoint |
| Hostname mismatch | The visited name is not in the SAN list | Reissue the certificate with the correct names |
| Missing intermediate | Clients cannot build a trust chain | Install the full chain (leaf + intermediates) |
| Self-signed certificate | Not trusted by public browsers | Use a public CA, or add a private trust root internally |
| Not yet valid | The not-before date is in the future, or the clock is wrong | Check the server clock or deploy the correct certificate |
| Covers apex but not www (or vice versa) | The SAN list is incomplete | Add both names when issuing the certificate |
| Wrong certificate behind a CDN | The edge is serving a stale or default certificate | Update the CDN custom-domain / TLS settings |
Common errors and what they mean
CERT_HAS_EXPIRED means the not-after date has passed. ERR_TLS_CERT_ALTNAME_INVALID means the hostname is not in the SAN list. UNABLE_TO_VERIFY_LEAF_SIGNATURE and SELF_SIGNED_CERT_IN_CHAIN almost always point to a missing intermediate or an untrusted root — the certificate itself may be fine but the chain is incomplete. A reset during the handshake (ECONNRESET) or an SNI mismatch usually means the server is not configured for the hostname you asked for, or it only supports obsolete protocol versions.
Example TLS inspection
- Example input
example.com:443- Example result
subject: example.com issuer: DigiCert Global G3 TLS ECC SHA384 2020 CA1 valid to: 2026-01-15 trusted: true
The hostname must be covered by the certificate names, and the full chain must be trusted by normal clients.
Related tools
Related guides
Why Your New SSL Certificate Shows A Name-Mismatch Error
Apex vs www, wildcard depth, wrong cert, half-deployed renewals — and how to read the SAN list to spot which.
Read guideTLS Certificate Expiration And Troubleshooting
Read certificate dates, SANs, chains, and the common ways renewals fail.
Read guideWhat Is A CAA Record?
Restrict which CAs may issue certificates for your domain.
Read guideFAQ
How do I check when a TLS certificate expires?
What is a subject alternative name (SAN)?
Why does my browser say the certificate is invalid when it looks fine here?
Does a wildcard certificate cover the root domain?
Why is the certificate different behind Cloudflare or a CDN?
What is a certificate chain?
How often should TLS certificates be renewed?
Last reviewed: 2026-06-22.