- X.509 certificates combine a public/private key pair with a CA-issued digital signature to verify a claimed identity.
- Under CA/Browser Forum Ballot SC-081v3 (April 2025), TLS certificate validity will be limited in phases to a maximum validity of 47 days by March 2029.
- Security teams should give each AI agent a short-lived X.509 certificate tied to a unique workload identity.
What Is an X.509 Certificate?
An X.509 certificate is a digital file that cryptographically binds a public key to a verified identity, such as a person, device, server or workload, using a signature issued by a trusted certificate authority (CA).
First published in 1988 as part of the ITU-T X.500 directory services suite, the X.509 standard defines a widely used format for public key certificates.
An X.509 certificate is “a digital certificate containing a public key for an entity and a unique name for that entity together with some other information that is rendered un-forgeable by the digital signature of the certification authority that issued the certificate.”
There are three versions of X.509. Version 1 (1988) introduced the basic structure. Version 2 (1993) added fields for directory access control.
Version 3 (1996) introduced extensions, the mechanism that gives X.509 digital certificates their flexibility in expressing key usage, subject alternative names, and policy constraints.
Most PKI deployments today require v3 certificates.
How X.509 Certificates Work
At the core of an X.509 certificate is a public/private key pair mathematically linked by asymmetric cryptography. The certificate holds the public key; the private key stays with the subject.
A root CA is the trust anchor of the X.509 system.
Root CAs are typically kept offline in highly secure facilities to avoid compromise. They use their own private key to sign certificates for intermediate CAs.
An intermediate CA vouches for the binding of an identity to an X.509 certificate by signing the certificate with its own private key.
Verifying a certificate means walking the chain of trust: the end-entity certificate is signed by an intermediate CA, which is signed by a root CA.
Clients validate each certificate in the chain and confirm none of the certificates have been revoked.
Uses of X.509 Certificates
X.509 certificates can be used for encryption, authentication and identity verification. Here are the most common ways X.509 certificates are used:
- TLS/SSL: Helps ensure users connect to legitimate servers and that their traffic is encrypted.
- Client authentication: Can be used for certificate-based client authentication including mutual TLS (mTLS), cloud applications, VPNs and wired or wireless network access
- Code signing: Developers can use certificates to apply digital signatures to their applications, providing evidence of the signer’s identity and showing the app hasn’t been tampered with.
- Email (S/MIME): A PKI can be used to verify the identity of the sender and encrypt email messages being sent.
- Document signing: X.509 certificates can be used to digitally sign documents by encrypting the digital signature with the certificate’s private key.
Version 3 X.509 certificates contain optional key usage extensions which define the purpose of the public key used in the certificate.
Key Fields in an X.509 v3 Certificate
An X.509 certificate format packs identity and cryptographic data into the structured fields shown below:
| Field | Description |
|---|---|
| Version | Identifies the certificate as v1, v2, or v3 |
| Serial number | A unique integer assigned by the issuing CA |
| Subject | The identity the certificate represents (e.g., a common name, organization, or URI for a workload) |
| Issuer | The CA that signed the certificate |
| Validity period | Not-before and not-after timestamps defining the certificate’s active window |
| Public key info | The algorithm and public key value |
| Extensions (v3 only) | Subject Alternative Name (SAN), Key Usage, Extended Key Usage, and Basic Constraints, among others. RFC 5280 requires conforming applications to recognize a defined set of extensions. |
Certificate Revocation
Certificates can be invalidated before their expiry date via two main mechanisms:
- Certificate Revocation Lists (CRLs): Periodic lists of revoked serial numbers published by the issuing CA. The CA/Browser Forum’s Ballot SC-063v4 made CRLs mandatory (and OCSP optional) for publicly trusted CAs, effective March 15, 2024.
- Online Certificate Status Protocol (OCSP): Allows real-time status queries per certificate. OCSP became optional under the same 2024 update, partly due to the privacy concern that CAs can observe which clients connect using which certificates.
Shortening certificate lifetimes reduces the window of exposure if revocation fails.
The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases TLS certificate validity down to a maximum of 47 days by March 2029.
X.509 in AI and Non-Human Identity
As AI agents, microservices, and automated pipelines replace human operators in more workflows, X.509 authentication is increasingly applied to non-human identities (NHIs) alongside traditional user and server contexts.
The SPIFFE framework formalizes this by issuing every workload an X.509 SPIFFE Verifiable Identity Document (SVID): a short-lived X.509 certificate encoding a SPIFFE ID as a URI in the Subject Alternative Name extension.
SVIDs are typically valid for one hour and auto rotate, which means even if an agent’s certificate is captured, the attacker’s window is narrow.
An SVID is like a cryptographic identity, similar to a passport, that’s going to be put on your AI agents so you can tell other systems like an MCP server, ‘This agent is trustworthy and should get this much access.’
- Micah Spady, Director of Product Marketing at SecureW2
This short-lived, cryptographically verifiable identity model is a clean fit for agent authentication in agentic systems.
Related Terms
Frequently Asked Questions
What is an X.509 certificate used for?
X.509 certificates authenticate the identity of websites, users, devices, and software workloads, and they enable encrypted communication by binding a verified identity to a public key.
What is the difference between X.509 and SSL/TLS?
X.509 is the certificate format standard; SSL/TLS are the protocols that use X.509 certificates to authenticate servers and establish encrypted connections.
What fields are inside an X.509 certificate?
Every X.509 v3 certificate contains at minimum a version number, serial number, issuer name, subject name, validity period, and public key, plus optional extensions such as Subject Alternative Names and Key Usage constraints.
How is an X.509 certificate revoked?
A certificate authority revokes an X.509 certificate by adding its serial number to a Certificate Revocation List (CRL) or by marking it invalid via the Online Certificate Status Protocol (OCSP).
How are X.509 certificates used to authenticate AI agents?
Frameworks like SPIFFE issue each AI agent or workload a short-lived X.509 certificate encoding a unique workload identity, so agents can authenticate to each other and to services without sharing long-lived secrets.
Securing AI agents and workloads?
SecureW2 issues short-lived, certificate-based identities to non-human and agent identities so every connection is authenticated. See how it maps to your stack.