The TLS handshake is the process by which a client and server establish an encrypted connection, and understanding it is essential for diagnosing SSL/TLS issues. In TLS 1.2, the handshake involves multiple round trips: the client sends supported cipher suites and a random number, the server responds with its chosen cipher suite, certificate, and its own random number, the client verifies the certificate chain and sends an encrypted pre-master secret, and both parties derive session keys. TLS 1.3 streamlined this to a single round trip by combining several steps and removing legacy cipher suites, reducing connection latency while improving security.

Certificate validation during the TLS handshake involves several checks that must all pass for the connection to be considered secure. The browser verifies that the certificate has not expired by checking the notBefore and notAfter dates. It confirms that the certificate's Subject Alternative Names (or Common Name as a fallback) match the requested domain. It builds and validates the certificate chain from the server's certificate through any intermediate certificates up to a trusted root CA. It checks that no certificate in the chain has been revoked, using either Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP). Finally, it verifies that the certificate's signature algorithm and key size meet minimum security requirements.

OCSP (Online Certificate Status Protocol) provides real-time certificate revocation checking as an alternative to downloading large CRLs. When a browser needs to verify a certificate's revocation status, it sends the certificate's serial number to the CA's OCSP responder, which returns a signed response indicating whether the certificate is good, revoked, or unknown. OCSP stapling improves this process by having the server periodically fetch its own OCSP response and deliver it during the TLS handshake, eliminating the client's need to contact the CA directly. This improves both performance (no additional round trip to the CA) and privacy (the CA does not learn which sites the client visits).

Certificate Transparency (CT) is a framework of publicly auditable, append-only logs that record all certificates issued by participating CAs. Introduced by Google in 2013 and required for all publicly trusted certificates since 2018, CT enables domain owners to monitor for misissued certificates and provides accountability across the certificate ecosystem. Signed Certificate Timestamps (SCTs) embedded in certificates prove that the certificate has been logged, and monitors continuously scan the logs for suspicious issuances. Common SSL/TLS configuration issues include incomplete certificate chains (missing intermediate certificates), expired certificates, hostname mismatches, weak cipher suites, and mixed content warnings where HTTPS pages load HTTP subresources.