Certificate Validation in TLS

Without certificate validation, a TLS connection could be established to an attacker posing as the server (man-in-the-middle). Certificate validation ensures you are talking to the legitimate server that controls the private key.

Key fields: Subject (who owns the cert), SubjectAltName (DNS names/IPs), Issuer (signing CA), Validity (notBefore/notAfter), Public Key, Signature. The browser checks all of these.

Server cert → Intermediate CA cert → Root CA cert. The root CA is self-signed and pre-installed in the OS/browser trust store. The server sends its cert + intermediates in the TLS handshake Certificate message.

Each certificate is signed by the issuer above it. The client verifies: signature(cert_n) using public_key(cert_{n+1}). If any signature is invalid, the chain is rejected. The root is trusted by pre-installation, not signature.

The client checks that the server's hostname matches the certificate Subject or SubjectAltName (DNS entries). Wildcards (*.example.com) match one label. Since 2000, SAN takes precedence over CN for hostname matching.

The client checks notBefore ≤ now ≤ notAfter for every cert in the chain. Expired certificates are rejected even if signatures are valid. Certificate lifetimes have shrunk: browsers now cap at ~398 days.

The CA publishes a Certificate Revocation List (CRL) — a signed list of serial numbers of revoked certs. The client downloads the CRL URL (from the cert's CRL Distribution Points extension) and checks for the serial number.

Online Certificate Status Protocol (OCSP) lets clients query the CA's OCSP responder for a single cert's status. Faster than CRL but adds latency. OCSP Stapling has the server include a signed OCSP response in the TLS handshake.

CT (RFC 6962) requires CAs to log all issued certs to public, append-only logs. Browsers check for Signed Certificate Timestamps (SCTs) in the cert or TLS extension. This prevents mis-issuance going undetected.

HTTP Public Key Pinning (HPKP, deprecated) and certificate pinning in mobile apps pin a specific public key or cert hash. If the server presents a different cert, the connection is rejected even if valid — prevents CA compromise attacks.

ERR_CERT_AUTHORITY_INVALID: root not trusted. ERR_CERT_DATE_INVALID: expired. ERR_CERT_COMMON_NAME_INVALID: hostname mismatch. NET::ERR_CERT_REVOKED: OCSP/CRL says revoked. Each maps to a specific validation step failure.

What does OCSP Stapling accomplish?

Certificate validation in TLS involves chain verification, signature checking, name matching, validity periods, and revocation. Next: historical TLS attacks and how TLS 1.3 mitigates them.