X.509 is the ITU-T standard that defines the format of public key certificates used throughout the internet's security infrastructure. First introduced in 1988 as part of the X.500 directory services standard, X.509 certificates have become the universal mechanism for binding a public key to an identity, enabling encrypted communications and authenticated connections across the web. The current version, X.509v3, introduced extensions that greatly increased the flexibility and capability of certificates.

The internal structure of an X.509 certificate follows ASN.1 (Abstract Syntax Notation One) encoding, serialized using DER (Distinguished Encoding Rules) binary format. The certificate contains three main sections: the TBSCertificate (To Be Signed) data, the signature algorithm identifier, and the digital signature itself. The TBSCertificate includes the version number, serial number (unique within the issuing CA), signature algorithm, issuer distinguished name, validity period (notBefore and notAfter timestamps), subject distinguished name, and the subject's public key information. Version 3 extensions add fields like Key Usage, Extended Key Usage, Subject Alternative Names, and Authority Information Access.

Public Key Infrastructure (PKI) establishes the trust framework that gives certificates their meaning. At the apex of the hierarchy are root Certificate Authorities (CAs) whose self-signed certificates are pre-installed in operating systems and browsers as trust anchors. Root CAs issue certificates to intermediate CAs, which in turn issue end-entity certificates to websites and services. This chain of trust means that when a browser encounters a certificate, it verifies the entire chain from the end-entity certificate through intermediates back to a trusted root. Each certificate in the chain is validated by checking that its signature was created using the private key of the issuer above it, that the certificate has not expired, and that it has not been revoked.

Certificate chains can be verified through two revocation checking mechanisms. Certificate Revocation Lists (CRLs) are periodically published lists of revoked certificate serial numbers, but their size and update frequency create scalability issues. The Online Certificate Status Protocol (OCSP) provides real-time revocation status for individual certificates, but introduces latency and privacy concerns because the OCSP responder learns which sites users visit. OCSP Stapling addresses the privacy issue by having the server periodically fetch its own OCSP response and "staple" it to the TLS handshake, proving revocation status without the client contacting the CA. Certificate Transparency (CT), developed by Google, requires CAs to log all issued certificates in publicly auditable append-only logs, enabling domain owners to detect misissued certificates and providing accountability across the entire PKI ecosystem.