What Is an X.509 Certificate? The Complete Guide to Digital Trust

As organizations manage more machines, devices, and services than ever before, the volume of X.509 certificates in production has grown exponentially. At the same time, the upcoming shift to 47-day certificate lifespans is compressing renewal windows, making manual certificate management unsustainable. Understanding how X.509 certificates work, how to manage them, and how to prepare for emerging cryptographic standards is no longer optional for IT and security teams.

This guide covers everything you need to know about X.509 certificates: what they are, how they secure communications, their internal structure, lifecycle management best practices, and what the transition to post-quantum cryptography means for your certificate strategy.

What is an X.509 certificate?

An X.509 certificate is a digital credential that follows the ITU Recommendation X.509 standard, and has been also adopted as an internet standard in the RFC 5280. It is used primarily to establish identity and secure communications across networks. It binds a verified identity (such as a domain name, organization, or device) to a cryptographic key pair, allowing systems to authenticate each other and encrypt data in transit.

X.509 certificates serve as credentials for both machines and human users, though machine-to-machine communication is by far the most common use case. They form the backbone of several critical security protocols and applications:

• TLS (web security): Every HTTPS connection relies on an X.509 certificate to authenticate the server and establish an encrypted channel.
• S/MIME (email security): X.509 certificates encrypt and digitally sign email messages, ensuring confidentiality and sender verification.
• Code signing: Software publishers use X.509 certificates to sign executables and updates, proving the code has not been tampered with.
• Device authentication: IoT devices, industrial controllers, and network equipment use X.509 certificates to prove their identity on a network.

Notably, SSH is absent in the list above, since the protocol uses a different type of certificate for native support of the needs of the protocol.

X.509 certificates operate within a Public Key Infrastructure (PKI), where Certificate Authorities (CAs) issue, validate, and revoke certificates according to established trust policies. While PKI defines the overall trust framework and CAs serve as the trusted third parties within it, the X.509 standard specifies the exact format and fields that make a certificate interoperable across systems and applications.

Other types of certificates, such as PGP certificates, use a decentralized “web of trust” model where any user can vouch for another’s identity. On the other hand, X.509 certificates rely on a hierarchical trust model with established CAs at the top. This hierarchical approach scales better for enterprise and internet use cases, where centralized trust decisions and automated validation are essential.

How X.509 certificates secure communications

The most visible application of X.509 certificates is securing web traffic through the TLS (Transport Layer Security) protocol, formerly known as SSL. Understanding the TLS handshake reveals exactly how certificates enable trusted, encrypted communication.

The TLS handshake process

When a client (such as a web browser) connects to a server, the TLS handshake follows a structured sequence. The precise steps vary depending on the version, however, at a high level it can be described as follows:

1. Client hello: The client initiates the connection by sending its supported cipher suites and TLS version to the server, alongside a nonce.
2. Server certificate presentation: The server responds with its signed X.509 certificate, presenting its verified identity to the client, with a signature of the nonce.
3. Certificate validation: The client verifies the nonce signature with the public key in the certificate, and the certificate’s signature by tracing it back through the certificate chain to a trusted root CA in its trust store. This confirms the server is who it claims to be.
4. Key exchange: Once authentication succeeds, the client and server negotiate a shared symmetric key. This key will encrypt all subsequent data in the session.
5. Secure channel established: With the symmetric key in place, the client and server communicate over an encrypted channel, protecting data from interception or tampering.

Server and client authentication

In most TLS connections, only the server presents a certificate and is validated by the client. This is the standard flow for HTTPS browsing: the server proves its identity, and the client (browser) verifies it before proceeding. However, some environments require both parties to authenticate each other using mutual TLS (mTLS), where the server also verifies the client’s X.509 certificate. Mutual TLS is increasingly common in API security, zero-trust architectures, and industrial environments where both endpoints must prove their identity before exchanging data.

The role of digital signatures

The X.509 certificate’s digital signature is what makes the entire trust model work. First, the client can be sure that it is communicating with the owner of the certificate by checking that the nonce was correctly signed, the certificate alone is not enough since anyone can have access to it. The client can also be sure that the server owns the certificate. When a CA issues a certificate, it signs the certificate data with its own private key. The client can verify this signature using the CA’s public key (available through the certificate chain), confirming that the certificate has not been altered and was genuinely issued by the claimed authority.

X.509 certificate format and fields

The X.509 standard defines a precise set of fields that every certificate must contain. These fields provide the information that clients and servers use to validate identities and establish trust.

Core certificate fields

Field	Description
Version	The X.509 version number (V1, V2, or V3). If omitted, Version 1 is assumed.
Serial Number	A unique identifier assigned by the issuing CA. No two certificates from the same CA share a serial number.
Signature Algorithm	The algorithm used to generate the certificate’s digital signature.
Issuer	The distinguished name (DN) of the CA that issued the certificate.
Validity	Two timestamps defining the certificate’s active window: Not Before (the date the validity starts) and Not After (expiry date).
Subject	The distinguished name of the entity the certificate identifies (e.g., a domain name or organization).
Subject Public Key Info	The public key algorithm (RSA, DSA, or Diffie-Hellman) and the actual public key value.

Version 3 extensions

Version 3 certificates introduced extensions that significantly expand what a certificate can communicate. These extensions use three subfields:

• extnId: Identifies the specific extension.
• critical: A boolean flag indicating whether the extension is mandatory for the recipient to process. If a critical extension is not recognized, the certificate must be rejected.
• extnValue: Contains the extension data, encoded as an octet string.

Common V3 extensions include key usage constraints (limiting what operations a key can perform), subject alternative names (allowing a single certificate to cover multiple domains), certificate policies, and basic constraints (distinguishing CA certificates from end-entity certificates).

These extensions are essential for modern PKI operations, enabling fine-grained control over how certificates are used within and across trust domains.

X.509 certificate encoding: DER vs. PEM

The X.509 standard defines the content and structure of a certificate but does not prescribe how that data should be encoded for storage and transmission. Two encoding formats dominate in practice.

DER (Distinguished Encoding Rules)

DER is a binary encoding format that produces compact certificate files. DER-encoded certificates cannot be opened in a text editor but are processed efficiently by web browsers, operating systems, and Java-based applications. Common file extensions for DER-encoded certificates include .der and .cer.

PEM (Privacy Enhanced Mail)

PEM takes DER-encoded binary data and converts it to Base64-encoded text, making the certificate readable in any text editor. PEM files are recognizable by their distinctive header and footer lines:

-----BEGIN CERTIFICATE----- [Base64-encoded data]  —–END CERTIFICATE—–`

PEM is the most common format on Linux and Unix systems, web servers (Apache, Nginx), and in command-line tools like OpenSSL. Common file extensions include .pem and .crt.

Choosing between formats

Both formats contain identical certificate data; the difference is purely in representation. DER is preferred in environments where binary efficiency matters (embedded systems, certain Windows applications). PEM is preferred when certificates need to be transmitted via text-based protocols (email, configuration files, copy-paste workflows).

Converting between formats is straightforward using standard tools like OpenSSL or certutil, making it simple to adapt certificates for different system requirements.

X.509 version history

The X.509 standard has evolved through three major versions, each expanding the certificate’s capabilities to meet the demands of increasingly complex network environments.

Version 1 (1988)

The original X.509 specification introduced the core certificate structure with the basic fields described above. Distinguished names followed the rules established by the X.500 directory standard, which drew inspiration from the hierarchical systems used to assign telephone numbers globally.

Version 2 (1993)

Version 2 added two fields: Issuer Unique Identifier and Subject Unique Identifier. These fields were intended to handle cases where issuers or subjects might reuse distinguished names over time. However, the IETF now considers these fields deprecated, and they should not be used in new certificates. The rapid growth of the internet during this period drove demand for a more flexible certificate structure.

Version 3 (1996 and beyond)

Version 3 introduced the extensions framework, enabling certificates to carry additional information about key usage, certificate policies, subject alternative names, name constraints, and more. This extensibility transformed X.509 from a basic identity credential into a versatile tool capable of supporting complex trust relationships within and across PKI domains. The standardization was completed by the IETF in 1996, yet is was not formally approved by ITU-T until 1997.

Today, virtually all certificates in production are Version 3. The extensions framework has proven essential for supporting modern use cases such as multi-domain certificates, code signing constraints, and how certificate validity periods have changed over time.

Trust chains and certificate authorities

X.509 certificates rely on hierarchical trust chains that let a client verify any certificate by tracing it back to a trusted root. A typical chain has three levels:

• a self-signed root CA certificate (pre-installed in browser and OS trust stores),
• an intermediate CA certificate that does the everyday work of signing end-entity certificates while keeping the root’s private key safely offline, and
• the end-entity certificate presented by a website, server, or device.

When a client receives an end-entity certificate, it walks the chain upward, validating each signature until it reaches a trusted root, accepting the certificate only if every signature checks out. Trust stores vary by client: Firefox maintains its own with roughly 150 roots, while Chrome defers to the OS trust store, with exceptions like its separate “EV-Qualified” root list and its Certificate Transparency requirement for Extended Validation (EV) certificates since 2015.

Trust can also span organizational boundaries through cross-certification, where two root CAs sign each other’s certificates so that clients trusting one root will accept certificates issued under the other, much like international calling agreements extending reach across country codes. Beyond chain structure, CAs issue certificates at different validation levels reflecting how deeply identity is verified:

• Domain Validation (DV): Confirms the applicant controls the domain. Fast to issue, minimal verification.
• Organization Validation (OV): Confirms the domain and verifies the organization’s legal identity.
• Extended Validation (EV): The most rigorous validation, requiring detailed verification of the organization’s identity, legal status, and physical address. EV certificates trigger enhanced trust indicators in some browsers.

How to generate an X.509 certificate

Generating an X.509 certificate follows a well-defined process, whether you are creating a CA-issued certificate for production or a self-signed certificate for development.

The certificate generation workflow

1. Generate a key pair: Create a public/private key pair using a supported algorithm (RSA, ECDSA, or Ed25519). The private key must be stored securely and never shared.
2. Create a Certificate Signing Request (CSR): The CSR contains the public key and the identifying information (subject name, organization, etc.) that will appear in the certificate. The CSR is signed with the applicant’s private key to prove possession.
3. Submit the CSR to a CA: For production certificates, submit the CSR to a trusted certificate authority. The CA validates the applicant’s identity according to the chosen validation level (DV, OV, or EV).
4. Receive the signed certificate: The CA signs the certificate with its own private key and returns the completed X.509 certificate, ready for deployment.

Tools for certificate generation

• OpenSSL: The most widely used command-line tool for generating keys, creating CSRs, and managing certificates. OpenSSL is available on virtually every Linux and macOS system.
• EJBCA: Keyfactor’s open-source PKI platform, designed for enterprise-scale certificate issuance and management. EJBCA supports automated enrollment through standard protocols.
• Enrollment protocols: Standards such as SCEP (Simple Certificate Enrollment Protocol), CMP (Certificate Management Protocol), EST (Enrollment over Secure Transport), and ACME (Automated Certificate Management Environment) enable automated certificate issuance, reducing manual intervention and human error.

Self-signed vs. CA-issued certificates

Self-signed certificates can be generated entirely by the end user without involving a CA. They are useful for development, testing, and internal lab environments. However, self-signed certificates should never be used in production. This is the following sections.

How to check X.509 certificate expiration dates

Expired certificates cause service outages, broken user experiences, and security vulnerabilities. Monitoring certificate expiration is a critical operational practice, especially as environments grow in complexity.

Why expiration monitoring matters

Certificates have built-in validity periods defined by the notBefore and notAfter fields. When a certificate expires, any connection that relies on it will fail. In web environments, expired certificates trigger browser warnings that block users from accessing the site. In industrial environments, expired certificates on PLCs, HMIs, or edge gateways can halt production lines entirely.

Organizations that rely on manual tracking (spreadsheets, calendar reminders) consistently experience preventable outages. The challenge scales with the number of certificates: a single overlooked expiration in a fleet of thousands can cascade into a significant incident.

Methods for checking expiration

Browser inspection: Click the padlock icon in your browser’s address bar to view certificate details, including the expiration date. This works for any HTTPS site but is impractical for monitoring large certificate inventories.

Command-line tools: OpenSSL provides direct access to certificate expiration data:

openssl x509 -enddate -noout -in certificate.pem

This returns the Not After date in a human-readable format. For remote servers, you can check expiration without downloading the certificate:

openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Automated monitoring solutions: For production environments, automated certificate discovery and monitoring tools continuously scan networks, inventory all certificates, and alert administrators before expiration dates arrive. This approach eliminates the risk of human oversight and is essential for organizations managing hundreds or thousands of certificates.

Self-signed vs. CA-issued X.509 certificates

The choice between self-signed and CA-issued certificates has significant implications for security, manageability, and trust.

What makes self-signed certificates risky

A self-signed certificate is one where the issuer and the subject are the same entity. The certificate holder generates the key pair, creates the certificate, and signs it with their own private key. No third-party verification occurs.

In colloquial terms, using a self-signed certificate is like writing your own passport. You can present it, and it may look legitimate, but no trusted authority has verified your identity. Any system that accepts a self-signed certificate is trusting the presenter’s claim without independent validation.

The risks of self-signed certificates in production include:

• No trust verification: Without a CA in the chain, there is no independent confirmation that the certificate holder is who they claim to be. Man-in-the-middle attacks become easier to execute.
• Unmanaged expiration: When someone generates a self-signed certificate using a command-line tool, the expiration date is whatever value they entered at creation time. Without centralized tracking, these certificates expire without warning.
• Operational outages: Organizations consistently report outages caused by expired self-signed certificates. In industrial environments, expired certificates on OPC UA servers, HMIs, and PLCs have caused machines to stop working, directly impacting production and revenue.

When self-signed certificates are appropriate

Self-signed certificates are acceptable in controlled, non-production scenarios:

• Local development and testing environments
• Internal lab setups isolated from production networks
• Proof-of-concept demonstrations

Root CA certificates are also self-signed, but that’s a structural property of trust anchors, not the same case. The are appropriate (indeed required) in production at any assurance level, with trust conferred by distribution into trust stores rather than by the signature itself.

Why CA-issued certificates are essential for production

CA-issued certificates provide the chain of trust that browsers, operating systems, and applications rely on to validate identity automatically. The CA has verified the certificate holder’s identity, the certificate chains back to a trusted root, and expiration is tracked within a managed lifecycle. For any system that serves external users, handles sensitive data, or connects to production infrastructure, CA-issued certificates are a requirement.

X.509 certificate lifecycle management

Managing X.509 certificates is not a one-time task. Each certificate passes through a lifecycle that, if not actively managed, introduces security risks and operational failures.

The certificate lifecycle stages

1. Discovery: Identify all certificates across the environment, including those issued by multiple CAs, embedded in devices, or deployed by individual teams without central oversight.
2. Inventory: Catalog each certificate with its metadata: issuer, subject, expiration date, key algorithm, and deployment location.
3. Issuance: Request and obtain certificates from appropriate CAs using standardized enrollment protocols.
4. Deployment: Install certificates on the target systems (web servers, load balancers, devices, applications).
5. Monitoring: Continuously track certificate status, approaching expirations, and policy compliance.
6. Renewal: Replace certificates before they expire, ideally through automated workflows.
7. Revocation: Invalidate certificates that are compromised, no longer needed, or associated with decommissioned systems.

Why manual management fails at scale

Organizations that attempt to manage certificates through spreadsheets, email reminders, or ad-hoc processes consistently encounter the same problems: missed expirations, duplicated effort, inconsistent policy enforcement, and delayed incident response. These challenges intensify as certificate volumes grow and validity periods shorten.

The shift toward 47-day certificate lifespans and the urgency of automation makes manual management untenable. When certificates renew every 47 days instead of every 398 days, the operational volume of renewals increases roughly eightfold.

The role of automation

Automated certificate lifecycle management addresses these challenges by:

• Continuously discovering certificates across networks, cloud environments, and device fleets
• Enrolling and renewing certificates through standard protocols (SCEP, CMP, EST, ACME)
• Enforcing consistent policies across all certificate types and CAs
• Alerting on approaching expirations and policy violations before they cause incidents
• Supporting standard certificate formats (PKCS#7, PKCS#10, PKCS#12, PEM) for interoperability across platforms

In industrial environments, certificate lifecycle management must also align with the lifecycle of the machines and devices the certificates protect. A certificate deployed on a PLC with a 15-year operational life requires a fundamentally different management approach than a certificate on a web server that is redeployed monthly.

Common use cases for X.509 certificates

X.509 certificates secure communications across a wide range of environments, from consumer-facing websites to factory floors.

IT use cases

• Web security (HTTPS): The most visible use case. Every website serving content over HTTPS uses an X.509 certificate for server authentication and encryption.
• Email encryption (S/MIME): X.509 certificates encrypt email messages and verify sender identity, protecting sensitive communications from interception and spoofing.
• Code signing: Software publishers sign executables, updates, and scripts with X.509 certificates, allowing users and systems to verify that the code has not been modified since it was signed.
• VPN authentication: X.509 certificates authenticate VPN endpoints, replacing or supplementing password-based authentication with certificate-based identity verification.
• Mutual TLS for API security: Microservices architectures and API gateways increasingly use mutual TLS with X.509 certificates to authenticate both client and server, supporting zero-trust security models.

OT and IoT use cases

Industrial environments introduce unique challenges for certificate management, including longer device lifecycles, limited compute resources, and operational technology (OT) protocols that differ significantly from IT standards.

• PLCs (Programmable Logic Controllers): Industrial controllers use X.509 certificates to authenticate communications with supervisory systems, preventing unauthorized commands from reaching production equipment.
• HMIs (Human-Machine Interfaces): Operator panels and visualization systems use certificates to secure their connections to underlying control systems.
• Edge and remote gateways: Devices that bridge OT networks with cloud platforms or IT systems rely on certificates for authenticated, encrypted data transmission.
• OPC UA (Open Platform Communications Unified Architecture): The leading industrial communication standard uses X.509 certificates as its primary mechanism for authentication and encryption between industrial components.
• Industrial firewalls and security appliances: Network security devices in OT environments use certificates to establish trusted communication channels and enforce access policies.

The IEC 62443 standard for industrial cybersecurity mandates PKI and certificate-based security at Security Level 2 and above, establishing X.509 certificates as a compliance requirement for many industrial organizations.

X.509 certificates and post-quantum cryptography

The emergence of quantum computing poses a long-term threat to the cryptographic algorithms that current X.509 certificates rely on. Organizations that depend on X.509 certificates for security need to understand the timeline and begin preparing now.

Unsigned trust anchors

One of the most immediate changes to the X.509 standard is the introduction of unsigned trust anchors. An upcoming update to the RFC 5280 removes the requirement for self-signed root certificates to carry a signature.

The reasoning is straightforward: since root CA certificates are self-signed, their signatures serve no practical purpose. No one actually validates the self-signature on a trust anchor. Tools like OpenSSL and Bouncy Castle have never validated root certificate signatures in practice.

With post-quantum algorithms, signatures become significantly larger. Algorithms like ML-DSA-87 and SLH-DSA produce signatures that consume considerably more space than their classical counterparts. Removing unnecessary signatures from trust anchors saves meaningful space, particularly in constrained environments.

Bouncy Castle already supports unsigned trust anchors, and the RFC is expected to formalize this approach as the standard moves toward post-quantum readiness.

Cryptographic agility and preparation

The transition to post-quantum cryptography requires organizations to:

• Inventory all cryptographic assets: Know where every X.509 certificate is deployed, what algorithms it uses, and when it expires.
• Achieve cryptographic agility: Build the ability to swap cryptographic algorithms without re-architecting systems. This means avoiding hardcoded algorithm choices and adopting PKI platforms that support algorithm flexibility.
• Monitor standards development: NIST has finalized its first set of post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA), and organizations should begin testing PQC-compatible certificate issuance in non-production environments.
• Plan for hybrid certificates: During the transition period, organizations may need to support both classical and post-quantum algorithms simultaneously.

The intersection of shorter certificate lifespans and the PQC transition means that preparing for post-quantum cryptography by 2030 is not a distant planning exercise. It is an active workstream for any organization that takes digital trust seriously.

How Keyfactor can help

The challenges covered throughout this guide (certificate sprawl, manual management limitations, self-signed certificate risks, lifecycle complexity, and post-quantum readiness) point to a common need: a unified platform for managing digital trust at scale.

Keyfactor addresses these challenges across four key areas:

• Modern PKI Infrastructure (EJBCA): Keyfactor’s EJBCA is an open-source, enterprise-grade PKI platform used by organizations worldwide to issue and manage X.509 certificates at scale. EJBCA supports standard enrollment protocols (SCEP, CMP, EST, ACME), flexible deployment models (on-premises, cloud, or hybrid), and the crypto-agility needed for the PQC transition.
• Certificate Lifecycle Automation (Command): Keyfactor Command provides end-to-end visibility and automation for certificate lifecycle management, from discovery and inventory through issuance, renewal, and revocation. It integrates with CAs across the organization, enforces consistent policies, and eliminates manual tracking.
• Cryptographic Discovery and Inventory: Keyfactor’s AgileSec automatically discovers every cryptographic asset across the environment, providing the visibility needed to assess quantum readiness and enforce security policies.
• PKI as a Service: For organizations that need managed PKI infrastructure without the operational overhead, Keyfactor combines hosted PKI with certificate lifecycle automation in a single service.

In industrial environments, Keyfactor’s Trust Point project extends PKI capabilities to operational technology, providing certificate management solutions designed for the unique constraints of industrial devices, long machine lifecycles, and OT protocols.