↓ Skip to main content
Le Site de François
  1. Index/

X.509

Security Cryptography Certificates Pki Tls Standards

X.509 is the ITU-T standard (first published in 1988, currently at version 3) that defines the structure of a digital certificate: a signed data structure that binds a public key to an identity and a set of constraints, issued by a Certificate Authority whose signature vouches for the binding. It is the near-universal format for certificates in PKI, TLS, code signing, S/MIME encrypted email, SPIFFE X.509-SVIDs, and SSH host certificates. When someone refers to a TLS certificate, a CA certificate, or a code-signing certificate, they are referring to an X.509 certificate. The format is defined using ASN.1 (Abstract Syntax Notation One) and most commonly serialised as DER (Distinguished Encoding Rules, binary) or PEM (base64-wrapped DER with -----BEGIN CERTIFICATE----- headers, the format seen in most configuration files).

An X.509 v3 certificate contains a fixed set of fields and an extensible Extensions section that carries the semantically rich parts of modern certificates. The core fields include: the Subject (a Distinguished Name — CN, O, OU, C fields — identifying the certificate holder), the Issuer (the DN of the signing CA), the Validity period (Not Before and Not After timestamps), the Subject Public Key Info (the algorithm and public key being certified), and the Serial Number (unique per issuer, used in revocation). The Extensions section, mandatory in v3, carries: Subject Alternative Names (SANs), which contain the actual hostnames, IP addresses, email addresses, or URIs (including SPIFFE IDs) that the certificate authenticates — the SAN is what TLS implementations check against the server name, not the CN; Key Usage and Extended Key Usage, which constrain the operations the key may be used for (digital signature, key encipherment, TLS server authentication, TLS client authentication, code signing); Basic Constraints, which marks a certificate as a CA certificate and optionally caps the length of certificate chains beneath it; Authority Key Identifier and Subject Key Identifier, which allow relying parties to locate the issuing CA’s certificate efficiently; and CRL Distribution Points and Authority Information Access, which provide URLs for revocation checking and OCSP. A certificate is verified by checking the cryptographic signature against the issuer’s public key, validating that the current time falls within the validity period, checking that no extension in the chain is violated, and confirming that the certificate has not been revoked.

X.509 certificate handling is operationally pervasive and a frequent source of outages and security incidents. The most common failures are expired certificates (automated renewal via ACME or Vault’s PKI engine is the standard mitigation), hostname mismatches (the requested hostname is not in the certificate’s SAN list — a frequent consequence of using the deprecated CN field for hostname validation), missing intermediate CA certificates (the server sends only the leaf certificate, and the client cannot build a chain to a trusted root), and trust store divergence (a certificate chains to a root trusted by some clients but not others, as is common with corporate CAs on managed devices). In the PQC transition, X.509 certificates are directly affected: the signature algorithm field must change from ecdsa-with-SHA256 or sha256WithRSAEncryption to an ML-DSA OID, and the Subject Public Key Info must carry an ML-DSA or ML-KEM public key; both the IETF and CA/Browser Forum are standardising the necessary OIDs and profile constraints for PQC X.509 certificates. Hybrid certificates — carrying both a classical and a PQC key — are under active development but not yet standardised for production use.

Related

PKI (Public Key Infrastructure)

Security Cryptography Certificates Identity Tls Pki
Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.

PQC (Post-Quantum Cryptography)

Security Cryptography Standards Pki Tls Nist
Post-Quantum Cryptography (PQC) is the set of cryptographic algorithms designed to resist attacks from a Cryptographically Relevant Quantum Computer (CRQC) — a quantum computer large and stable enough to run Shor’s algorithm at scale. Shor’s algorithm can solve the integer factorisation and discrete logarithm problems that underpin RSA, ECDSA, and ECDH in polynomial time, meaning that every asymmetric algorithm in wide use today — TLS key exchange, X.509 certificate signatures, SSH host keys, code signing, and encrypted email — becomes trivially breakable by a CRQC. Symmetric algorithms (AES, SHA-256) are substantially less affected: Grover’s algorithm provides only a quadratic speedup against them, which is mitigated by doubling key lengths (AES-256 remains appropriate). PQC replaces the asymmetric primitives only, on hard mathematical problems for which no efficient quantum algorithm is known: structured lattices (the Learning With Errors and Module-LWE problems), hash functions (the security of SHA-3 family variants), and error-correcting codes.

CRL (Certificate Revocation List)

Security Pki X509 Certificates Revocation Tls
A Certificate Revocation List (CRL) is a signed data structure, published by a Certificate Authority as part of its PKI operations, that lists the serial numbers of X.509 certificates the CA has revoked before their scheduled expiry date. A CA revokes a certificate when its private key is compromised, the subject’s identity information changes, the certificate was mis-issued, or the subject is no longer authorised. Without revocation, a compromised certificate remains trusted by all verifiers until it expires — which for long-lived CA and infrastructure certificates can be years. The CRL is the oldest revocation mechanism, defined in RFC 5280 alongside the X.509 v3 certificate format, and remains widely deployed for CA certificates, code signing certificates, and client certificates in contexts where OCSP is impractical.