What Is an X.509 Certificate?

X.509 is a standard format for public key certificates, digital documents that securely associate cryptographic key pairs with identities such as websites, individuals, or organizations.

First introduced in 1988 alongside the X.500 standards for electronic directory services, X.509 has been adapted for internet use by the IETF’s Public-Key Infrastructure (X.509) (PKIX) working group. RFC 5280 profiles the X.509 v3 certificate, the X.509 v2 certificate revocation list (CRL), and describes an algorithm for X.509 certificate path validation.

Recent updates to X.509 certificate handling include RFC 9618 (August 2024), which updates the certificate policy validation algorithm to address potential denial-of-service vulnerabilities and improve processing efficiency.

Common applications of X.509 certificates include:

• SSL/TLS and HTTPS for authenticated and encrypted web browsing
• Signed and encrypted email via the S/MIME protocol
• Code signing
• Document signing
• Client authentication
• Government-issued electronic ID

Key Pairs and Signatures

No matter its intended application(s), each X.509 certificate includes a public key, digital signature, and information about both the identity associated with the certificate and its issuing certificate authority (CA):

• The public key is part of a key pair that also includes a private key. The private key is kept secure, and the public key is included in the certificate. This public/private key pair:
  • Allows the owner of the private key to digitally sign documents; these signatures can be verified by anyone with the corresponding public key.
  • Allows third parties to send messages encrypted with the public key, which can only be decrypted by the owner of the private key.
• A digital signature is an encoded hash (a fixed-length digest) of a document that has been encrypted using a private key. When an X.509 certificate is signed by a publicly trusted CA, such as SSL.com, the certificate can be used by a third party to verify the identity of the entity presenting it.
  
  Note: Not all applications of X.509 certificates require public trust. For example, a company can issue its own privately trusted certificates for internal use. For more information, please read our article on Private vs. Public PKI.
• Each X.509 certificate includes fields that specify the subject, issuing CA, and other required information, such as the certificate’s version and validity period. In addition, v3 certificates contain a set of extensions that define properties such as acceptable key usages and additional identities to bind a key pair to.

Certificate Fields and Extensions

To review the contents of a typical X.509 certificate in the wild, we will examine www.ssl.com’s SSL/TLS certificate, as shown in Google Chrome. (You can check all of this in your own browser for any HTTPS website by clicking the lock on the left side of the address bar.)

• The first group of details includes information about the Subject, including the name and address of the company and the Common Name (or Fully Qualified Domain Name) of the website that the certificate is intended to protect. (Note: the Serial Number shown in this subject field is a Nevada business identification number, not the serial number of the certificate itself.)
  
• Scrolling down, we encounter information about the Issuer. Not coincidentally, in this case, the Organization is “SSL Corp” for both subject and issuer, but the issuer’s Common Name is the name of the issuing CA certificate rather than a URL.
  
• Below the Issuer, we see the certificate’s Serial Number (a positive integer uniquely identifying the certificate), X.509 Version (3), the Signature Algorithm, and dates specifying the certificate’s Validity Period.
  
• Next, we arrive at the Public Key, Signature, and associated information.
  
• In addition to the fields above, X.509 v3 certificates include a group of Extensions that offer additional flexibility in certificate use. For example, the Subject Alternative Name extension allows the certificate to be bound to multiple identities. (For this reason, multiple-domain certificates are sometimes referred to as SAN certificates). In the example below, we can see that the certificate actually covers eleven different SSL.com subdomains:
  
• The Fingerprints shown below the certificate information in Chrome are not part of the certificate itself, but are independently calculated hashes that can be used to uniquely identify a certificate.
  

Certificate Chains

For both administrative and security-related reasons, X.509 certificates are typically combined into chains for validation. As shown in the screenshot from Google Chrome below, the SSL/TLS certificate for www.ssl.com is signed by one of SSL.com’s intermediate certificates, SSL.com EV SSL Intermediate CA RSA R3. In turn, the intermediate certificate is signed by SSL.com’s EV RSA root:

For publicly trusted websites, the web server will provide its own end-entity certificate, plus any intermediates required for validation. The root CA certificate with its public key will be included in the end user’s operating system and/or browser application, resulting in a complete chain of trust.

Certificate Validity Periods

X.509 certificates include validity periods specified by “Not Valid Before” and “Not Valid After” dates. For security reasons, the validity periods of certificates have been significantly reduced over time.

Currently, publicly trusted TLS certificates have a maximum validity period of 398 days (approximately 13 months). However, the industry is moving toward even shorter validity periods to improve security. In April 2025, the CA/Browser Forum approved a schedule that will reduce the maximum validity period for TLS certificates to 47 days, effective March 15, 2029.

Shorter lifecycle certificates eliminate many security concerns associated with certificate compromise, as these swift validity periods minimize the window of potential misuse. Organizations using short-lived certificates may not need to implement traditional revocation checking, as certificates expire quickly enough to limit exposure from compromised keys.

Revocation

X.509 certificates that must be invalidated before their “Not Valid After” date may be revoked.

Certificate revocation mechanisms enable certificate authorities (CAs) to communicate when certificates should no longer be trusted, typically due to key compromise, CA compromise, or changes in the certificate’s status.

Certificate Revocation Lists (CRLs)

As mentioned above, RFC 5280 profiles certificate revocation lists (CRLs), which are time-stamped lists of revoked certificates published by CAs. CRLs have become the preferred method for certificate revocation in the modern web PKI.

In March 2024, the CA/Browser Forum updated the Baseline Requirements to make CRLs mandatory and the Online Certificate Status Protocol (OCSP) optional for publicly trusted certificate authorities. This change reflects the industry’s recognition that CRLs offer significant advantages over OCSP, particularly in terms of user privacy and operational efficiency.

Modern Revocation Checking

Current browsers and applications use various approaches for revocation checking:

• CRL Distribution Points (CDP): Browsers download and cache CRLs from the URLs specified in certificate extensions
• CRLSets: Some browsers use compressed datasets derived from CRLs for efficient revocation checking
• OCSP Stapling: Where still supported, web servers can include OCSP responses during TLS handshakes
• Short-lived certificates: Organizations increasingly use certificates with very short validity periods (7-47 days) to minimize revocation needs

For more information on the thorny history of revocation checking and how current browsers check the revocation status of certificates, please read our articles, Page Load Optimization: OCSP Stapling, and How Do Browsers Handle Revoked SSL/TLS Certificates?

X.509 Frequently Asked Questions