TLS Certificate Validation: Mermaid Sequence Diagram

TLS Certificate Validation sequence diagram

About Source

TLS certificate validation is the process by which a client verifies that a server's digital certificate is authentic, unexpired, and issued by a trusted authority before establishing an encrypted connection.

When a browser or API client connects to an HTTPS endpoint, the server presents its TLS certificate during the handshake. The client must perform several checks before trusting this certificate. First, it parses the certificate to extract the subject (the domain name the certificate was issued for), the issuer (the Certificate Authority that signed it), the validity period (not-before and not-after timestamps), and the digital signature.

The client checks that the certificate's Common Name or Subject Alternative Names match the hostname it is connecting to. A mismatch results in an immediate rejection regardless of other validity checks — this prevents a valid certificate for one domain from being used to impersonate another.

Next, the client validates the certificate chain. The server certificate is signed by an intermediate CA, which is itself signed by a root CA. The client walks this chain, verifying each signature using the public key of the issuing CA, until it reaches a root CA that is present in its local trust store. If any link in the chain cannot be verified, the connection is rejected.

The client also checks the certificate's validity period. Certificates include explicit not-before and not-after fields; if the current time falls outside this window, validation fails. Additionally, the client may check revocation status using either OCSP (Online Certificate Status Protocol) or a CRL (Certificate Revocation List) to ensure the certificate has not been revoked by its issuer before expiry.

Only after all these checks pass does the client proceed with the TLS handshake, generating session keys using the server's public key from the validated certificate. This entire validation process is what makes HTTPS resistant to man-in-the-middle attacks.

For the broader context of how this fits into connection setup, see TLS Handshake and HTTPS Handshake. The chain of CAs involved is explored in Certificate Authority Chain, and the underlying asymmetric cryptography is explained in Public Key Encryption.

Frequently asked questions

TLS certificate validation is the process a client performs during the TLS handshake to verify the server's certificate is authentic, issued by a trusted authority, covering the correct hostname, and not expired or revoked. All checks must pass before the client proceeds to establish an encrypted session.

The client starts with the server's end-entity certificate and verifies its signature using the issuing intermediate CA's public key. It then verifies the intermediate CA's certificate using the root CA's public key. The root CA must be present in the client's local trust store. If any signature fails or the root is not trusted, the chain validation fails.

OCSP (Online Certificate Status Protocol) lets the client query the CA's OCSP responder in real time to check whether a certificate has been revoked before its expiry date. OCSP Stapling is an optimization where the server attaches a pre-fetched, CA-signed OCSP response to the TLS handshake, eliminating the client's need to make a separate OCSP request.

The client aborts the connection and displays an error — typically "Your connection is not private" in browsers. API clients throw certificate validation errors. The connection is never established, preventing any data exchange with the server. This protects against man-in-the-middle attacks where an attacker presents a fraudulent certificate.

Certificate validation is one step within the TLS handshake. The handshake covers the full session setup: protocol version negotiation, cipher suite selection, certificate exchange, key derivation, and session establishment. Certificate validation is specifically the set of checks on the certificate itself — chain trust, hostname, expiry, and revocation.

mermaid

sequenceDiagram
    participant Client
    participant Server
    participant IntermCA as Intermediate CA
    participant RootCA as Root CA (Trust Store)
    participant OCSP as OCSP Responder

    Client->&gt;Server: ClientHello (TLS handshake start)
    Server-->&gt;Client: ServerHello + Certificate chain
    note">Note over Client: Parse certificate fields\n(subject, issuer, validity, SANs)
    Client->&gt;Client: Check hostname matches CN or SAN
    Client->&gt;Client: Check notBefore <= now <= notAfter
    Client->&gt;IntermCA: Verify server cert signature\nusing intermediate CA public key
    IntermCA-->&gt;Client: Signature valid
    Client->&gt;RootCA: Verify intermediate CA cert\nusing root CA public key
    RootCA-->&gt;Client: Root CA found in trust store
    Client->&gt;OCSP: Check revocation status\n(certificate serial number)
    OCSP-->&gt;Client: Certificate status: good
    note">Note over Client: All checks passed\nProceed with key exchange
    Client->&gt;Server: Continue TLS handshake