What does a TLS certificate chain connect?
A certificate has months left, yet the browser warns. Another computer opens the site without trouble. Expiration is only one part of validation. Using a typical CA-signed certificate for public HTTPS, separate the server name from the path back to a trusted authority.
Follow the server certificate toward a trust anchor
A server certificate contains names, a public key and other information signed by an issuing CA. An intermediate CA certificate is itself signed by another CA. The client validates these connections and tries to reach an anchor it already trusts.
Three different roles
A root is not trusted merely because it signs itself. Trust is an input from outside this chain. Sending an unfamiliar root alongside the server certificate does not cause a client to trust it. RFC 5280 §6.1.1 treats anchor information as input to validation.
| Role | What to look for |
|---|---|
| Server certificate, or leaf | Service names, public key, validity period and TLS server purpose |
| Intermediate CA certificate | A public key for checking a signature and constraints on its CA role |
| Trust anchor | Information trusted in advance through OS, application or administrative configuration |
Compare SAN with the name you actually use
Current TLS service-identity rules use Subject Alternative Name, or SAN. A matching Common Name alone is not sufficient. RFC 9525 §6 defines DNS and IP matching and replaces RFC 6125.
Suppose SAN contains DNS:*.example.com
A wildcard can occupy only the entire leftmost label. Passing this comparison does not establish that the other validation conditions have passed.
| Requested host | Name-matching result only |
|---|---|
| www.example.com | Matches for a client supporting wildcards |
| example.com | Does not match: there is no leftmost label to replace |
| a.b.example.com | Does not match: a wildcard does not span two labels |
| 192.0.2.10 | Does not match a DNS SAN; an IP address SAN must be checked |
Time, signatures and purpose are separate checks
notBefore and notAfter describe the validity period. An incorrect client clock can make a certificate appear not yet valid or expired. Signatures, CA constraints, key usage and name constraints also matter. Being able to display these fields is different from validating them.
Failures despite an unexpired leaf
RFC 5280 §6.1.3 provides the basic path-processing rules. Successful certificate validation does not certify the safety of the products, content or links on a website.
| Observation | Where to investigate |
|---|---|
| Name mismatch | The URL hostname, SAN and the certificate selected by the server |
| Issuer cannot be reached | Supplied intermediates and the trust anchors available to the client |
| Wrong purpose | Key Usage and Extended Key Usage constraints |
| Revocation or unknown status | The client revocation method and information supplied by the CA |
The displayed chain is not necessarily the validated path
A server normally sends its leaf and needed intermediate certificates, while the client supplies its own trusted starting point. In TLS 1.3, RFC 9846 §4.5.1 places the sender certificate first and permits omission of the certificate representing the trust anchor. Missing intermediates can affect clients differently depending on their stored information and path-building behavior.
Matching Issuer and Subject text is only a clue
An Issuer matching the next Subject suggests a candidate link. Certificates with the same name can still have different keys or constraints. Text equality is not signature verification or trust validation. During a TLS connection, the handshake also checks that the peer can use the corresponding private key; merely reading a certificate file does not establish that possession.
Choose between inspecting a file and testing a connection
The certificate decoder sends the input file to the server to read SAN, dates and other fields. Successful parsing does not validate trust, the hostname or revocation. A public certificate is enough for this inspection; a private key is unnecessary.
Read SSL/TLS checker results in context
The SSL/TLS checker connects from its server to the entered host. If its verified connection fails, it retries without verification to retrieve the certificate, so displayed details do not mean verification succeeded. When OCSP information is available, it may contact that external responder, but it does not verify the OCSP response signature. Results reflect this server clock, trust configuration and network path; compare them with the client you intend to use.
Specifications and preparation guides
RFC 5280 §4.1.2.5: validity; RFC 9525 §6.3–6.4: name matching; RFC 9846 §4.5.2: CertificateVerify and key possession. RFC 9846 is the current TLS 1.3 specification and replaces RFC 8446. Continue with CSRs and private keys, the certificate format guide or reading OCSP results.