X.509 is the international standard that defines the format of digital certificates. Every TLS certificate, every code signing certificate, and every client authentication certificate you encounter follows this specification. Understanding X.509 means understanding the language of digital trust.
X.509 is a standard originally defined by the ITU-T (International Telecommunication Union, Telecommunication Standardization Sector) as part of the X.500 directory services framework. First published in 1988, it was initially designed to associate public keys with directory entries in global telecommunications systems. Over the following decades, X.509 evolved far beyond its original scope to become the universal format for digital certificates in public key infrastructure.
Today, the X.509 standard (formalized by the IETF in RFC 5280) governs the structure of every certificate used in TLS/SSL, S/MIME, code signing, and client authentication. When your browser validates a website's identity, it is parsing an X.509 certificate. When a server authenticates a client through mutual TLS, it is reading X.509 fields. The standard defines not just what information a certificate contains, but also how that information is encoded, signed, and validated.
Understanding X.509 is essential for anyone working with PKI. It explains why certificates look the way they do, what each field means, and how extensions add flexibility to an otherwise rigid structure. This chapter breaks down the standard into its core components so you can read, interpret, and troubleshoot certificates with confidence.
An X.509 certificate is a structured data object encoded using ASN.1 (Abstract Syntax Notation One). Every certificate, regardless of its purpose, contains a set of mandatory fields that identify the certificate, its subject, its issuer, and the cryptographic parameters used. Here are the core fields defined by the standard:
Indicates which version of X.509 the certificate uses. Nearly all certificates today are version 3 (v3), which introduced the extensions mechanism that makes modern PKI possible.
A unique integer assigned by the issuing Certificate Authority. The combination of the issuer name and serial number must be globally unique. It is also used to identify certificates in revocation lists.
Specifies the cryptographic algorithm the CA used to sign the certificate (for example, SHA-256 with RSA or ECDSA with SHA-384). This field appears twice: once in the TBS (to-be-signed) portion and once alongside the actual signature.
A Distinguished Name (DN) identifying the CA that issued and signed the certificate. This field is critical for building the certificate chain back to a trusted root.
Two timestamps, notBefore and notAfter, that define when the certificate becomes valid and when it expires. Relying parties must reject certificates outside this window.
A Distinguished Name identifying the entity the certificate was issued to. For a TLS certificate, this typically includes the domain name. For an organization, it includes the company name, country, and organizational unit.
Contains the subject's public key and identifies the algorithm it uses (RSA, ECDSA, Ed25519, etc.). This is the key that will be used for encryption or signature verification in the protocols that rely on the certificate.
Optional fields introduced in version 3 that add constraints and metadata. Extensions can be marked critical (must be understood by the relying party) or non-critical (can be safely ignored if not recognized).
Extensions are what make X.509 v3 certificates so versatile. They allow CAs to express constraints, declare purposes, and provide additional information without changing the base certificate format. Here are the most important extensions you will encounter in practice:
Defines the cryptographic operations the certificate's key is permitted to perform. Common values include digitalSignature, keyEncipherment, keyCertSign, and cRLSign. For example, a CA certificate needs keyCertSign to issue other certificates, while a TLS server certificate typically has digitalSignature and keyEncipherment. This extension is almost always marked critical.
Provides a more granular definition of the certificate's purpose. While Key Usage defines low-level operations, EKU maps to real-world use cases: serverAuth for TLS servers, clientAuth for mutual TLS, codeSigning for software publishers, and emailProtection for S/MIME. A certificate with serverAuth cannot be used for code signing, even if the key type would technically allow it.
Lists the identities the certificate is valid for, beyond what the Subject field specifies. For TLS certificates, the SAN typically contains DNS names (like www.example.com and example.com), but it can also include IP addresses, email addresses, and URIs. Modern browsers rely on the SAN rather than the Subject CN field for hostname validation, making this extension essential for any TLS certificate.
Indicates whether the certificate belongs to a CA or an end entity. When cA: TRUE, the certificate is allowed to issue other certificates. The optional pathLenConstraint field limits how many intermediate CAs can exist below this one in the certificate chain. This extension is critical: without it correctly set, a compromised end-entity certificate could theoretically be used to forge new certificates.
Specifies URLs where the relying party can download the Certificate Revocation List (CRL) published by the issuing CA. When a client needs to check whether a certificate has been revoked, it fetches the CRL from the location indicated in this extension and looks for the certificate's serial number.
Provides two important URLs: the OCSP responder address (for real-time revocation checking) and the CA issuers URL (where the intermediate CA certificate can be downloaded). AIA is what allows a client to dynamically build the full chain of trust even when the server only presents its own certificate.
The same X.509 certificate data can be stored and transmitted in several different encoding formats. These formats determine how the binary certificate data is represented on disk or in transit. Understanding the differences is essential when configuring servers, importing certificates into keystores, or debugging TLS issues.
The most common format on Linux and Unix systems. PEM is simply DER data encoded in Base64 and wrapped between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- headers. Because it uses plain text, PEM files can be opened in any text editor and safely transmitted via email or pasted into configuration files. File extensions are typically .pem, .crt, or .cer.
The raw binary encoding of the ASN.1 certificate structure. DER files are compact and unambiguous, making them the native format for many Java applications, Windows certificate stores, and embedded systems. Because they are binary, they cannot be viewed in a text editor. File extensions are typically .der or .cer.
A container format defined in RFC 2315 that can hold one or more certificates (and optionally CRLs) but never private keys. PKCS#7 is commonly used to deliver a full certificate chain from a CA. It can be encoded in PEM or DER form. File extensions are typically .p7b or .p7c. Windows and Java environments frequently use this format for chain distribution.
A password-protected archive format that bundles the certificate, the full chain, and the private key into a single file. PKCS#12 is the standard way to export a complete credential from one system and import it into another. It is widely used for Windows IIS configurations, Java keystores (via conversion), and certificate migration. File extensions are typically .p12 or .pfx.
The X.509 standard has gone through three major versions. Each version added capabilities that addressed limitations discovered in practice.
The original specification, published as part of the X.500 directory standard. Version 1 defined the basic certificate fields: serial number, signature algorithm, issuer, validity, subject, and public key. It had no mechanism for extensions, which meant there was no standard way to express constraints like key usage or alternative names. Version 1 certificates are essentially obsolete today.
Added two optional fields: the Issuer Unique Identifier and the Subject Unique Identifier. These were intended to handle cases where the same Distinguished Name might be reused over time (for example, after a CA reorganization). In practice, these fields were rarely used, and version 2 is seldom encountered in the wild.
The current and dominant version. Version 3 introduced the extensions framework, allowing CAs to attach additional structured data to certificates. This single change made modern PKI possible: it enabled Key Usage restrictions, Subject Alternative Names, Basic Constraints for CA/end-entity distinction, CRL Distribution Points, Authority Information Access, and dozens of other standard and custom extensions. Virtually all certificates issued today are X.509 v3.
Full X.509 visibility: Evertrust CLM parses every field and extension of your certificates, giving you a clear, searchable view of subjects, SANs, key usages, validity periods, and chain relationships across your entire infrastructure.
Policy enforcement on certificate content: Define rules for allowed key algorithms, minimum key sizes, required extensions, and naming conventions. Evertrust flags non-compliant certificates before they reach production, ensuring every X.509 certificate in your environment meets your organizational standards.
Format-agnostic management: Whether your teams work with PEM, DER, PKCS#7, or PKCS#12, Evertrust CLM handles the import, conversion, and distribution of certificates in any standard encoding format.
Issue standards-compliant certificates: Evertrust PKI issues X.509 v3 certificates with precisely configured extensions, ensuring your CA hierarchy, key usages, and constraints follow industry best practices and your specific compliance requirements.
