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.
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.
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).
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.
