X.509 Certificates: Structure & Trust Explained

An X.509 certificate doesn’t actually prove who you are; it proves that someone (a Certificate Authority) vouches for the identity associated with the public key inside.

Let’s see an X.509 certificate in action. Imagine a web server presenting its certificate to your browser.

openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -text -noout

This command connects to Google’s web server, retrieves its TLS certificate, and then uses openssl x509 -text -noout to display the certificate’s contents in a human-readable format. You’ll see fields like Issuer, Subject, Validity, Public Key Algorithm, and Extensions.

The core problem X.509 certificates solve is establishing trust in a decentralized, untrusted network like the internet. How can your browser trust that the server it’s talking to is actually Google, and not an imposter? X.509 uses a Public Key Infrastructure (PKI) built on a chain of trust.

Here’s how it works internally:

1. Identity Binding: An entity (e.g., a company wanting a website) generates a public/private key pair. They then send their public key and proof of identity to a Certificate Authority (CA).
2. CA Verification: The CA verifies the identity of the applicant. The level of verification varies (e.g., Domain Validation, Organization Validation, Extended Validation).
3. Certificate Issuance: If satisfied, the CA signs the applicant’s public key and identity information with its own private key. This signed package is the X.509 certificate. The signature is the CA’s vouch.
4. Chain of Trust: Most certificates aren’t signed directly by a root CA (like DigiCert or Let’s Encrypt). Instead, they’re signed by an intermediate CA, which is itself signed by a root CA. This creates a chain: your certificate -> intermediate CA certificate -> root CA certificate.
5. Browser Trust: Your operating system and browser come pre-loaded with a list of trusted root CA certificates. When your browser receives a server’s certificate, it checks the signature. It uses the public key of the issuer (found in the issuer’s certificate) to verify the signature on the server’s certificate. It then follows the chain up, verifying each signature, until it reaches a root CA it trusts. If the chain is valid and the root is trusted, the connection is considered secure.

The key fields you’ll see in a certificate are:

• Version: Usually version 3 for modern certificates.
• Serial Number: A unique identifier for this certificate within the issuing CA.
• Signature Algorithm: The algorithm used to create the signature (e.g., sha256WithRSAEncryption).
• Issuer: The Distinguished Name (DN) of the CA that issued this certificate. This is crucial for the chain.
• Validity:
  • Not Before: The date/time the certificate becomes valid.
  • Not After: The date/time the certificate expires.
• Subject: The Distinguished Name (DN) of the entity the certificate belongs to (e.g., the website’s domain name).
• Subject Public Key Info: Contains the public key itself and the algorithm it uses (e.g., RSA, ECC).
• Extensions: This is where much of the important information resides for modern certificates. Key extensions include:
  • Key Usage: Specifies how the public key can be used (e.g., digitalSignature, keyEncipherment).
  • Extended Key Usage (EKU): Further refines the purpose (e.g., serverAuth for TLS, clientAuth for mutual TLS, codeSigning).
  • Subject Alternative Name (SAN): Crucially, this lists all hostnames and IP addresses the certificate is valid for. A certificate is only valid for names listed here, not just the Subject DN.
  • Basic Constraints: Indicates if the certificate is a CA certificate and the maximum path length of the chain.
  • Certificate Policies: Defines the policies under which the certificate was issued.
  • CRL Distribution Points / OCSP Information: Pointers to services used to check if the certificate has been revoked.

When you see openssl s_client -connect www.google.com:443 < /dev/null | openssl x509 -text -noout, you’re seeing the public part of this system. The private key corresponding to the Subject Public Key Info is what the web server uses to decrypt data and prove its identity during the TLS handshake. The CA’s private key, which is never shared, is used to sign certificates.

The way certificate revocation checking works is often misunderstood. While Certificate Revocation Lists (CRLs) are a standard mechanism, they can be large and slow to download. Online Certificate Status Protocol (OCSP) is a more real-time method where a client queries an OCSP responder to get the status of a specific certificate. Browsers often perform OCSP stapling, where the web server proactively fetches an OCSP response for its own certificate and includes it with the certificate during the TLS handshake, speeding up validation for clients and improving privacy.

Understanding the Subject Alternative Name (SAN) field is critical. A certificate issued for example.com is not inherently valid for www.example.com unless www.example.com is explicitly listed in the SAN extension. The Subject field’s Common Name (CN) is becoming less important for TLS validation, with SANs being the primary source of truth for hostnames.

The next step in understanding secure communication is exploring the TLS handshake itself, which utilizes these certificates to establish a secure, encrypted channel.