X.509 is an ITU-T and IETF standard that defines the format for public key certificates, certificate revocation lists, and certification path validation, and an X.509 certificate is the digital certificate issued under that format to verify ownership of a public key.
X.509 is the standard format behind almost every digital certificate in use today, defining fields like version, serial number, issuer, validity period, subject, and public key. A Certificate Authority issues X.509 certificates to bind a public key to an identity, and browsers and applications validate them for TLS, code signing, and email security.
Key Takeaways
- X.509 is jointly maintained by the ITU and IETF, and it defines certificates, certificate revocation lists, attribute certificates, and path validation algorithms.
- An X.509 certificate can belong to a user, website, device, or organization, and supports both asymmetric and symmetric use cases.
- The Validity Period field carries two dates, notBefore and notAfter, which together define the certificate’s usable window.
- Extensions such as Subject Alternative Name (SAN) and Key Usage let a single certificate cover multiple domains or restrict how its key can be used.
- Under the CA/Browser Forum’s SC-081v3 schedule, the notAfter window on public TLS certificates is shrinking to 100 days by March 2027 and 47 days by March 2029.
What Fields Make Up an X.509 Certificate?
| Field | Purpose |
| Version | Indicates the X.509 iteration used, affecting available extensions and algorithm support |
| Serial Number | Uniquely identifies the certificate within the issuing CA’s domain |
| Signature Algorithm | Specifies the cryptographic algorithm the CA used to sign the certificate, such as RSA or ECDSA |
| Issuer Name | Identifies the CA that issued and signed the certificate |
| Validity Period | Defines the notBefore and notAfter dates during which the certificate is trusted |
| Subject Name | Identifies the certificate holder, typically via Common Name and organizational attributes |
| Public Key | The key used for encryption, signatures, or key exchange, paired with a private key the holder keeps secret |
| Extensions | Optional metadata such as Subject Alternative Name or Key Usage that customizes the certificate’s scope |
Why Does the Signature Algorithm Field Matter?
The signature algorithm field records exactly which algorithm and parameters the CA used to sign the certificate, commonly RSA, DSA, or ECDSA. Relying-party software checks this field during path validation to confirm the signature is both cryptographically valid and still considered acceptable under current security policy.
What do Certificate Extensions Add to the Base X.509 Fields?
Extensions let a certificate carry more than the base fields, without changing the base X.509 structure itself.
- Subject Alternative Name (SAN): lists multiple domain names or identities a single certificate can cover.
- Key Usage: restricts what operations the public key may be used for, such as digital signatures or key encipherment.
- Certificate Policies: carries a policy OID and optional CPS Pointer that defines the issuance and revocation practices a CA followed.
How Encryption Consulting Helps
CertSecure Manager parses and inventories every X.509 field and extension across your certificate estate, flagging weak signature algorithms and validity periods that no longer meet the CA/Browser Forum’s shortened schedule. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.
Frequently Asked Questions
What is the difference between X.509 and TLS?
X.509 defines the format of the digital certificate itself, including its fields and extensions. TLS is the protocol that uses an X.509 certificate during the handshake to authenticate a server, and in some cases a client, before establishing an encrypted session.
Can one X.509 certificate cover multiple domains?
Yes, using the Subject Alternative Name (SAN) extension. A single certificate can list several domain names, which is how many organizations secure a primary domain and several subdomains without issuing a separate certificate for each.
What is the notBefore and notAfter field?
notBefore and notAfter together make up the Validity Period field. notBefore is the earliest date the certificate is considered valid, and notAfter is its expiration date; a relying party rejects the certificate outside that window.
Who maintains the X.509 standard?
X.509 is jointly maintained by the International Telecommunication Union (ITU) and the Internet Engineering Task Force (IETF), which together define the certificate format, revocation list structure, and path validation rules that PKI implementations follow.
Manage Every X.509 Certificate You Issue
CertSecure Manager discovers, inventories, and automates renewal for every X.509 certificate across your infrastructure, keeping signature algorithms and validity periods aligned with current CA/Browser Forum requirements. See CertSecure Manager in action.