An X.509 certificate is a digital certificate that uses the X.509 public key infrastructure (PKI) standard to verify the identity of a certificate holder and enable encrypted communications between parties. X.509 certificates work by binding a public key to an identity through a certificate authority (CA).
Introduction to X.509 Certificates
X.509 certificates allow secure communication over networks and the internet by providing cryptographic keys that can encrypt and decrypt messages. Here are some key points about X.509 certificates:
- X.509 certificates bind a public key to an identity through a certificate authority. This allows others to verify their identity.
- They enable secure encrypted communication through SSL/TLS protocols. The certificate contains a public key that can encrypt messages that only the holder’s private key can decrypt.
- Certificates form a chain of trust from the end entity up to a root CA that is trusted. Intermediate CAs may also be part of the chain.
- Certificates have standard fields with information about the holder’s identity, the issuer, validity period, public key, and more.
- End entities typically get certificates from CAs, but organizations can run their own CAs to issue certificates to employees. Self-signed certificates skip the CA.
- Certificates have different levels of validation depending on the verification steps CAs takes. Extended validation (EV) is the highest level.
X.509 establishes the format and contents of the certificate. But other standards like SSL/TLS use X.509 certificates for secure communications.
How X.509 Certificates Work
X.509 certificates utilize public key cryptography to secure communications between two parties and verify identity. Here is an overview of how X.509 certificates work:
Certificate Authority Issues Certificate
A certificate authority reviews an application and background information to verify the applicant’s identity. If approved, the CA issues an X.509 certificate containing the applicant’s public key and information such as their identity and the CA’s signature.
User Presents Certificate to Relying Party
When the certificate holder needs to prove their identity, they share the certificate with the relying party. This could be for a TLS connection, signing a document, encryption, or other purposes.
Relying Party Validates Certificate Chain
The relying party traces the certificate chain up to a trusted root CA to verify the end entity certificate has not been altered or fraudulently issued.
Parties Exchange Encrypted Messages
With the holder’s identity validated, the relying party can use the public key in the certificate to encrypt a message that only the holder can decrypt with their private key. This allows secure communication.
Certificate Revoked if Private Key Compromised
If the certificate holder’s private key is compromised, the CA can revoke the certificate. Relying parties check revocation lists to ensure the certificate they are trusting has not been revoked.
This process allows trusted third-party CAs to securely vouch for identities and issue certificates used for encrypted communications.
X.509 Certificate Contents
X.509 certificates follow a standard format with required and optional fields. This enables widespread interoperability between different systems and technologies using X.509 certificates.
Certificate Fields
These are some of the key fields in an X.509 certificate:
- Version: Version of X.509 standard, typically 2 or 3.
- Serial number: Unique ID for certificate issued by a CA.
- Signature algorithm: Algorithm used by CA to sign the certificate, like SHA-256.
- Issuer: Identity of the CA that issued the certificate.
- Validity: Start and end dates for validity of the certificate.
- Subject: Identity of the certificate holder.
- Subject public key: Public key bound to the subject used for encryption.
- Extensions: Optional fields like key usage, policies, alternate names.
- Signature: The CA digitally signs the entire certificate to validate it.
Formats
X.509 certificates utilize the Abstract Syntax Notation One (ASN.1) standard to structure the data in the certificate. This data can be encoded using formats like:
- DER: Binary encoding of ASN.1 certificate. Smaller but not human readable.
- PEM: Base64 encoded version of DER format, with header and footer text. Used for data transfer between systems.
- CER / CRT: DER formatted certificate in separate .cer or .crt files.
Most applications can handle various X.509 certificate formats. The binary DER format is used to digitally sign and encrypt. PEM base64 encoding makes certificates portable.
Types of X.509 Certificates
There are different classes and types of X.509 certificates used for specific use cases:
Classes
- Class 1: Validates basic identity information. Low assurance.
- Class 2: Requires in-person vetting of identity. Medium assurance.
- Class 3: Extensive validation from authoritative sources. High assurance.
Types
- Publicly Trusted: Issued by public CAs like Comodo, Digicert, for public internet use.
- Private: For internal use in organizations, issued by private CAs.
- Self-Signed: Unsigned by any CA, used for testing mostly.
- Root: Self-signed, represents trusted root of hierarchy. Issues other intermediate and entity certificates.
- Intermediate: Issued and signed by a root or higher-level intermediate CA. Issues end entity certs.
- End Entity: Issued to users, servers, or devices. End of validation chain.
Different classes and types have different levels of trust and intended use cases. Publicly trusted certificates require extensive validation for internet use.
X.509 Certificate Validation
Validating an X.509 certificate involves these steps:
Verify Integrity
Digital signature from the issuing CA is used to verify the certificate contents have not been tampered with.
Confirm Validity Dates
Check that the current date falls within the validity start and end dates of the certificate. Expired certificates are rejected.
Validate Issuer Signature
Use the issuer’s public key to decrypt the signature and verify it matches the rest of the certificate contents.
Check Revocation Status
Check CRLs or OCSP responses to ensure the certificate has not been revoked by the issuing CA.
Validate Certificate Path
Move up the certificate chain to verify each issuer until reaching a trusted root CA.
Following these validation steps prevents fraudulent certificates and verifies the end entity certificate.
Certificate Authorities (CAs)
Certificate authorities are trusted third parties that issue X.509 certificates by verifying identity and signing certificates with their private key.
Types of CAs
- Public CAs: Issue browser-trusted certificates to websites and the public. Examples: Comodo, DigiCert, GoDaddy.
- Private CAs: Operated by organizations to issue internal certificates. Eg. to employees or servers.
- Root CAs: Top-level authority that issues intermediate certificates. Trusted by browsers and OSs.
- Intermediate CAs: Issues end-entity certificates, signed by the root CA or another intermediate.
Web of Trust
Hundreds of public CAs form a complex web of trust relationships:
- Browsers and OSs trust root CAs who then validate lower level intermediates.
- Intermediates may issue certificates or cross-sign each other for broader trust.
- End entities complete the chain to a trusted root.
CA Responsibilities
Key responsibilities for CAs include:
- Validating applicant identity through required procedures.
- Securely issuing certificates and storing private signing keys.
- Publishing issued certificates and certificate revocation lists (CRLs).
- Revoking compromised certificates quickly.
- Following industry best practices for certificate issuance and lifecycle management.
Becoming a CA
Major web browsers and OSs only trust pre-approved CAs who meet strict standards. CAs must undergo audits and inspections to be included as trusted. Becoming a public CA requires significant time, compliance, and technology investments.
Organizations can become their own private CA more easily and issue internal certificates. The operating system needs to trust the root CA for the certificates to be automatically accepted.
X.509 in SSL/TLS
SSL and TLS protocols utilize X.509 certificates to secure communications and transactions on the internet. Here is how certificates enable HTTPS web traffic:
Certificate Creation
A domain owner generates a certificate signing request (CSR) containing their public key and domain name and submits it to a CA. The CA validates the domain ownership and issuer an SSL certificate.
Client Retrieves Certificate
When visiting the website, the client requests the SSL certificate as part of the initial TLS handshake. This allows the client to verify the server’s identity.
Server Presents Certificate
The web server provides its SSL certificate to the client containing public key, issuer, signature, and domain name information.
Client Validates Certificate
The client verifies the certificate signature chains up to a trusted root CA and that the domain name matches the website. This confirms the server’s identity and allows encrypted communication.
Secure HTTPS Connection
With the server’s identity validated, the client and server can establish a secure TLS encrypted connection using the public key in the server certificate.
Private Key Encrypts/Decrypts
The website’s private key can decrypt requests encrypted with the public key. Responses encrypted with the public key can only be read by the client’s private key.
This handshake allows the client and server to communicate securely over HTTPS using the X.509 certificates and SSL/TLS cryptographic protocols. The certificates enable authenticated encryption.
X.509 Certificate Management
Proper management of X.509 certificates is crucial for security and reliability. Here are some best practices:
Key Generation
Private keys should be generated securely on the server to prevent compromise. Key size should be at least 2048 bits for RSA.
New Certificate before Expiry
Apply for a new certificate with sufficient time before the current certificate expires to avoid disruptions.
Safe Private Key Storage
Private keys should be stored securely to prevent unauthorized access. Encryption and hardware security modules can provide protection.
Renew and Replace Compromised Keys
If a private key is compromised, the corresponding certificate must be immediately revoked and replaced with a new key pair.
Use Trusted Public CAs
For public SSL certificates, only purchase from reputable CAs trusted by major browsers to avoid untrusted certificate warnings.
Validate Own Certificates
Use certificate managers to track certificates and validate upcoming expirations, revocations, and renewals.
CRL and OCSP Updating
Ensure certificate revocation lists and OCSP responder services are kept updated so clients can efficiently check revocation status.
Following best practices for the X.509 certificate lifecycle is essential for reducing disruptions and maintaining security.
X.509 Certificate Examples
Below are examples of common X.509 certificates:
Domain Validation Certificate
Issued for: example.com
Issuer: DigiCert SHA2 Secure Server CA
Subject: example.com
Valid: Jan 1 2020 – Jan 1 2022
Basic validation of domain ownership only. Low cost option for encrypting non-critical sites. Provides domain validated (DV) SSL cert.
Organization Validation Certificate
Issued for: shop.example.com
Issuer: GeoTrust RSA CA 2018
Subject: Example Company Inc.
Valid: Mar 1 2021 – Mar 1 2023
Moderate assurance certificate that validates legal identity of company. Issuer confirmed organizational documents. Provides organization validated (OV) SSL cert.
Extended Validation Certificate
Issued for: bank.example.com
Issuer: DigiCert SHA2 Extended Validation Server CA
Subject: Example Bank Inc.
Valid: Sep 1 2022 – Sep 1 2024
High assurance certificate with extensive company identity checks. Displays green bar with organization name in browsers. Meets extended validation (EV) guidelines.
These show the range of validation levels and identity assurance provided by different classes of X.509 certificates.
X.509 Certificate FAQs
What is an X.509 certificate used for?
X.509 certificates bind a public key to an identity and enable encrypted communication, authentication, and digital signatures. They are widely used for HTTPS websites, VPN connections, email signatures, document signing, and more.
What’s the difference between public and private CAs?
Public CAs like Comodo and GoDaddy issue certificates trusted for use on the public internet. Private CAs operate within organizations to issue certificates for internal use.
What is a self-signed certificate?
Self-signed certificates are signed by their own creator rather than a trusted CA. They are commonly used for testing but not considered secure for production websites facing the internet.
What information is in an X.509 certificate?
X.509 certificates include fields like serial number, issuer, subject, public key, validity period, signature algorithm, extensions, and the digital signature.
How does certificate validation work?
Relying parties validate certificates by checking the signature, verifying the certificate chain to a trusted root CA, confirming validity dates, and checking revocation status.
What’s the difference between DER, PEM, and CRT formats?
DER is binary encoding, PEM is base64 encoded, and CRT/CER are DER-encoded certificates in individual files. Applications can handle all formats.
How do CAs verify identity before issuing certificates?
CAs follow validation guidelines based on the certificate class, confirming identity documents, legal existence, address, domain ownership, etc through checking official records.
What is an intermediate certificate authority?
Intermediate CAs are certified by root CAs or other intermediates to issue certificates on their behalf. This creates a chain of trust for validating certificates.
How do browsers and OSs trust root CAs?
Major software vendors and consortiums carefully select reputable CAs as trusted roots after extensive auditing and compliance checks. Root stores are updated periodically.
What is the best way to store certificate private keys securely?
Private keys should be stored unencrypted only on secure servers. Encrypted private keys or hardware security modules offer additional protection against unauthorized access.
