X.509 Decoder

What is X.509?

X.509 is an international standard (ITU-T X.509, also published as RFC 5280) that defines the format of public key certificates. An X.509 certificate is a digitally signed document that binds a public key to an identity — such as a domain name, an organization, or an individual. Certificates are the trust anchors of the internet: every HTTPS connection, every code-signed application, and every S/MIME email relies on X.509 certificates.

When you visit a website over HTTPS, your browser receives the server’s X.509 certificate, verifies that it was issued by a trusted Certificate Authority (CA), checks that it has not expired or been revoked, and confirms that the domain name matches. Only after all these checks pass does the browser establish an encrypted connection.

The X.509 standard was first published in 1988 as part of the X.500 directory services specification. The current version (v3) introduced extensions, which allow certificates to carry additional metadata such as Subject Alternative Names, key usage constraints, and revocation information. Version 3 certificates are used universally today.

Certificate Structure

Every X.509 v3 certificate contains the following fields, encoded in ASN.1 DER format and typically distributed in PEM (Base64-armored) form:

Field	Description	Example
Version	Certificate version (almost always v3)	v3
Serial Number	Unique identifier assigned by the CA	03:A1:F2:...
Signature Algorithm	Algorithm used by the CA to sign	SHA256withRSA
Issuer	Distinguished Name of the signing CA	CN=Let's Encrypt Authority X3, O=Let's Encrypt
Validity (Not Before)	Start of the certificate’s validity period	2024-01-15T00:00:00Z
Validity (Not After)	End of the certificate’s validity period	2024-04-14T23:59:59Z
Subject	Distinguished Name of the certificate holder	CN=example.com
Public Key	The subject’s public key and algorithm	RSA 2048-bit
Extensions	Optional v3 extensions (see table below)	SAN, Key Usage, etc.

Common Extensions

Extensions give X.509 v3 certificates their flexibility. Some are marked as critical (the certificate must be rejected if the extension is not understood) and others are non-critical.

Extension	OID	Purpose
Subject Alternative Name (SAN)	2.5.29.17	Lists additional identities (DNS names, IPs, emails) the certificate is valid for
Key Usage	2.5.29.15	Restricts the cryptographic operations the key may perform (e.g., digitalSignature, keyEncipherment)
Extended Key Usage (EKU)	2.5.29.37	Specifies purposes like TLS server auth, TLS client auth, or code signing
Authority Key Identifier (AKI)	2.5.29.35	Identifies the CA’s public key that signed this certificate
CRL Distribution Points	2.5.29.31	URLs where the Certificate Revocation List can be downloaded
Authority Information Access (OCSP)	1.3.6.1.5.5.7.1.1	URL for Online Certificate Status Protocol checks and CA issuer certificate retrieval

Chain of Trust

X.509 certificates do not exist in isolation. They form a chain of trust (also called a certificate chain or certification path) from the end-entity certificate back to a trusted Root Certificate Authority.

The chain works as follows:

1. Root CA: A self-signed certificate pre-installed in your operating system or browser’s trust store. Root CAs are the ultimate trust anchors — they are trusted because they have been vetted and explicitly included by OS and browser vendors (Apple, Microsoft, Mozilla, Google)

2. Intermediate CA: A certificate signed by the Root CA (or another intermediate). Root CAs rarely sign end-entity certificates directly. Instead, they delegate to intermediates, which limits exposure — if an intermediate is compromised, only that intermediate needs to be revoked, not the root

3. Leaf (End-Entity) Certificate: The certificate presented by the server (your website). It is signed by an intermediate CA and contains the server’s public key and domain name(s)

During a TLS handshake, the server sends the leaf certificate and any intermediates. The client builds the chain up to a trusted root and verifies every signature in the path. If any link is broken — expired, revoked, or signed by an untrusted CA — the connection fails.

Certificate Transparency

Certificate Transparency (CT) is a system of public, append-only logs that record every certificate issued by participating CAs. CT allows domain owners and the public to detect misissued or fraudulent certificates. Since 2018, Google Chrome requires all publicly trusted certificates to be logged in at least two CT logs.

Common Use Cases

• HTTPS / TLS: Every secure website uses an X.509 certificate to prove its identity and enable encrypted communication. The browser verifies the certificate chain before establishing the TLS connection
• Code signing: Software developers sign executables, drivers, and packages with X.509 certificates so that operating systems and users can verify the code has not been tampered with and comes from a known publisher
• Email signing and encryption (S/MIME): X.509 certificates enable end-to-end email encryption and digital signatures, proving the sender’s identity and ensuring message integrity
• Mutual TLS (mTLS): In zero-trust architectures, both the client and server present certificates to authenticate each other. This is common in service-to-service communication within microservice architectures
• VPN authentication: Enterprise VPNs use X.509 certificates for client authentication, replacing or complementing username/password login
• Document signing: PDF digital signatures use X.509 certificates to provide non-repudiation — proof that the signer signed the document and it has not been altered
• IoT device identity: Connected devices use X.509 certificates to authenticate to cloud platforms (AWS IoT, Azure IoT Hub), ensuring only authorized devices can connect