An X.509 certificate is a digital document that binds a public cryptographic key to a verified identity using the X.509 Public Key Infrastructure (PKI) standard. It tells your browser, email client, or server: “this public key belongs to this verified entity – you can trust it.” Every HTTPS website, every signed email, and every code-signed application relies on an X.509 certificate to prove authenticity and enable encrypted communication. The certificate is issued by a trusted Certificate Authority (CA), which verifies the identity before signing the certificate with its own private key.
What Is an X.509 Certificate Used For?
X.509 certificates serve as the foundation of trust on the internet – they are not limited to websites. A single certificate can prove identity, encrypt data in transit, and verify that a document or piece of software has not been altered since it was signed.
The most common use cases include:
- HTTPS websites: TLS certificates securing browser-to-server connections
- Email (S/MIME): signing and encrypting email messages
- Code signing: verifying that software comes from a trusted publisher
- VPN authentication: validating device or user identity before granting access
- Document signing: legally binding digital signatures on PDF and contracts
The X.509 standard itself defines only the certificate format. Protocols like TLS, S/MIME, and IPsec each decide how they consume and validate X.509 certificates for their specific purpose.
How Does an X.509 Certificate Work?
An X.509 certificate works through public key cryptography combined with a chain of verified trust. The process follows a consistent pattern regardless of the use case.
- A Certificate Authority verifies the applicant’s identity domain ownership for DV, legal organization documents for OV, and extensive vetting for EV certificates.
- The CA issues a certificate containing the applicant’s public key, identity information, validity dates, and the CA’s own digital signature.
- The certificate holder presents it to anyone who needs to verify their identity or send them encrypted data.
- The relying party validates the certificate by checking the CA’s signature, confirming the certificate has not expired, and tracing the chain back to a trusted root CA.
- Encrypted communication begins the sender uses the public key in the certificate to encrypt data that only the certificate holder’s private key can decrypt.
- If the private key is compromised, the CA can revoke the certificate. Relying parties check the Certificate Revocation List (CRL) or use the Online Certificate Status Protocol (OCSP) to catch revoked certificates before trusting them.
The key insight is that you never need to exchange a secret in advance. The public key in the certificate can be shared openly – only the matching private key, held securely by the certificate owner, can decrypt what was encrypted with it.
What Fields Does an X.509 Certificate Contain?
Every X.509 certificate follows a standardized structure defined by the ITU-T X.509 standard, most recently updated in its version 3 form. These are the core fields:
|
Field |
Description |
|
Version |
X.509 version (v1, v2, or v3 – v3 is current standard) |
|
Serial Number |
Unique identifier assigned by the issuing CA |
|
Signature Algorithm |
Algorithm used to sign the certificate (e.g., SHA-256 with RSA) |
|
Issuer |
Distinguished Name (DN) of the CA that issued the certificate |
|
Validity Period |
Not Before and Not After dates defining the active window |
|
Subject |
Distinguished Name of the certificate holder (domain, org, etc.) |
|
Public Key |
The public key bound to the subject, with algorithm identified |
|
Extensions |
Optional v3 fields: Key Usage, Subject Alternative Names, policies |
|
Digital Signature |
CA’s cryptographic signature covering the entire certificate |
What Are the X.509 Certificate File Formats?
X.509 certificate data is encoded and distributed in several file formats. The choice of format depends on the system receiving the certificate.
|
Format |
Encoding |
Description |
Common Use |
|
DER |
Binary |
Compact, not human-readable |
Java applications, Windows systems |
|
PEM |
Base64 (ASCII) |
Text-wrapped version of DER with header/footer |
Apache, Nginx, Linux servers |
|
CRT / CER |
Binary (DER) |
DER-encoded certificate in its own file |
Windows, IIS servers |
|
PFX / P12 |
Binary |
Bundles certificate + private key together |
Windows import, key migration |
Most certificate management tools can convert between formats. PEM is the most portable format for Unix-based server deployments.
What Types of X.509 Certificates Exist?
X.509 certificates are categorized by their position in the trust hierarchy and by how much identity verification was performed before issuance.
By validation level:
- Domain Validation (DV) confirms only that the applicant controls the domain; issued in minutes; lowest cost
- Organization Validation (OV) confirms the legal existence of the organization behind the domain
- Extended Validation (EV) requires the most thorough identity checks; historically displayed a green bar in browsers
By role in the trust hierarchy:
- Root CA certificate self-signed; the anchor of trust; pre-installed in browsers and operating systems
- Intermediate CA certificate signed by the root; issues end-entity certificates; insulates root keys from daily use
- End-entity certificate issued to a website, device, or user; the certificate you actually deploy
By deployment scope:
- Publicly trusted issued by public CAs and accepted by all major browsers without configuration
- Privately trusted issued by an organization’s own CA for internal systems; requires manual trust installation
- Self-signed no CA involved; appropriate only for internal testing; will trigger browser warnings in production
How Is an X.509 Certificate Validated?
Certificate validation happens automatically every time you visit an HTTPS site, but the steps follow a precise sequence. Skipping any step leaves the door open to fraudulent or compromised certificates.
- Verify integrity: Decrypt the CA’s digital signature using the CA’s public key and confirm it matches the certificate contents. Any tampering breaks the signature.
- Check validity dates: Confirm the current date falls within the certificate’s notBefore and notAfter fields. Expired certificates are immediately rejected.
- Validate the certificate chain: Trace each issuer up the chain until reaching a root CA that exists in the local trust store.
- Check revocation status: Query the CA’s CRL or OCSP responder to confirm the certificate has not been revoked.
- Verify subject identity: Confirm the certificate’s Subject or Subject Alternative Name matches the domain or entity being contacted.
According to Google’s HTTPS Transparency Report (February 2025), over 95% of pages loaded in Chrome are served over HTTPS – meaning this validation chain executes billions of times daily across the web.
What Is a Certificate Authority and Why Does It Matter?
A Certificate Authority is a trusted organization that verifies identities and issues X.509 certificates signed with its own private key. The CA’s signature is what makes a certificate meaningful – without it, there is no third-party verification.
Types of CAs:
- Public CAs (DigiCert, Sectigo, GlobalSign) – trusted by browsers and operating systems out of the box; governed by the CA/Browser Forum’s Baseline Requirements
- Private CAs – operated internally by organizations; certificates only work on devices where the root is manually trusted
- Root CAs – hold the highest level of trust; sign intermediate CA certificates rather than end-entity certificates to protect root keys
- Intermediate CAs – sit between the root and end-entity certificates; most day-to-day certificate issuance happens here
The CA/Browser Forum’s Baseline Requirements govern how public CAs must operate – covering validation procedures, certificate lifetimes, and revocation. As of 2024, the maximum publicly trusted TLS certificate validity is 397 days, down from two years in prior years, with further reductions proposed.
How Should You Manage X.509 Certificates?
Poor certificate management is one of the most common causes of unexpected outages. A certificate that expires without a replacement in place takes a service offline immediately.
Follow these practices:
- Track all certificates and expiry dates using a certificate manager or inventory spreadsheet – never rely on memory or ad-hoc renewals
- Generate private keys securely on the server – never transmit a private key over email or store it in version control; aim for RSA 2048-bit minimum or ECDSA P-256
- Renew at least 30 days before expiry – many CAs and automation tools (like ACME/Let’s Encrypt) send renewal reminders; automate where possible
- Revoke and replace compromised keys immediately – do not wait; a compromised private key means the associated certificate must be treated as untrusted
- Use only public CAs trusted by major browsers for externally facing services – private CA certificates will cause browser warnings for any user who has not manually installed your root
X.509 Certificate Examples
These three examples show how the same X.509 standard produces certificates with very different trust levels and use cases.
Domain Validation Certificate
- Issued for: example.com
- Issuer: Sectigo RSA Domain Validation Secure Server CA
- Subject: example.com
- Validity: Jan 1, 2025 – Jan 2, 2026 (397 days, current maximum)
- Use case: Encrypts traffic to a blog or informational site; confirms domain control only
Organization Validation Certificate
- Issued for: shop.example.com
- Issuer: DigiCert SHA2 Secure Server CA
- Subject: Example Company Inc., US
- Validity: Mar 1, 2025 – Apr 1, 2026
- Use case: E-commerce or SaaS product where customers benefit from seeing a verified company name in the certificate details
Extended Validation Certificate
- Issued for: bank.example.com
- Issuer: DigiCert SHA2 Extended Validation Server CA
- Subject: Example Bank Inc., New York, US
- Validity: Sep 1, 2025 – Oct 1, 2026
- Use case: High-assurance environments like banking; requires thorough legal and operational vetting before issuance
Frequently Asked Questions About X.509 Certificates
What is the difference between an X.509 certificate and an SSL certificate?
An SSL certificate is a specific type of X.509 certificate used to secure web traffic over TLS (the protocol that replaced SSL). X.509 is the broader standard that defines the certificate format – SSL/TLS, S/MIME, and code signing certificates are all X.509 certificates serving different purposes.
How long is an X.509 certificate valid?
For publicly trusted TLS certificates, the current maximum validity is 397 days as required by the CA/Browser Forum. Certificates issued for internal or private CA use can technically have longer lifetimes, though shorter is better for security. A 2024 CA/B Forum ballot proposed reducing public certificate validity to 90 days in the coming years.
What happens when an X.509 certificate expires?
Browsers and clients immediately reject expired certificates – visitors see a hard security warning and cannot reach the site without clicking through an override. There is no grace period. The only fix is to obtain and install a new certificate.
What is a self-signed X.509 certificate?
A self-signed certificate is one where the subject and the issuer are the same entity – no CA vouches for its authenticity. Browsers will warn users that the certificate is untrusted. Self-signed certificates are appropriate for local development and internal testing but should never be used on production services accessible to the public.
What is a certificate chain of trust?
The chain of trust is the sequence of certificates linking an end-entity certificate back to a trusted root CA. Your server certificate was signed by an intermediate CA, which was signed by the root CA. Browsers verify each link in this chain – a break anywhere in the chain causes a certificate error.
How do CAs verify identity before issuing an X.509 certificate?
For Domain Validation (DV), the CA confirms domain control by requiring the applicant to place a specific file on the server, set a DNS record, or receive a validation email. For Organization Validation (OV), the CA also checks legal incorporation records, physical address, and phone listings. Extended Validation (EV) adds a manual legal and operational review process governed by strict CA/Browser Forum guidelines.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
