SSL Certificate Fields Decoded: X.509 Deep Dive

An SSL certificate isn’t just a lock icon; it’s a complex data structure that cryptographically binds a public key to an identity, and the real magic happens in its extensions.

Let’s look at a certificate in action. We’ll use openssl to inspect one. Imagine you’ve downloaded a certificate file, mycert.pem.

openssl x509 -in mycert.pem -text -noout

This command spits out a wealth of information. You’ll see the basic fields first:

• Issuer: Who vouches for this certificate’s authenticity. This is usually a Certificate Authority (CA) like Let’s Encrypt, DigiCert, or your internal PKI.
• Subject: Who this certificate is for. For a server certificate, this is typically the domain name (e.g., CN = example.com).
• Validity: The Not Before and Not After dates. If the current time is outside this range, the certificate is considered expired or not yet valid.
• Public Key Algorithm: The cryptographic algorithm used for the public key (e.g., rsaEncryption).
• Public Key: The actual public key itself, usually shown in hexadecimal.

But the real power, and often the source of confusion, lies in the X509v3 Extensions section. These are optional, but crucial, pieces of data that define what the certificate can do and where it’s valid.

• X509v3 Key Usage: This dictates the intended use of the public key. Common values include:

  • Digital Signature: For signing data.
  • Key Encipherment: For encrypting other keys (like session keys in TLS).
  • Content Commitment: For data integrity.
  • Key Agreement: For Diffie-Hellman key exchange. For a web server certificate, you’ll almost always see Digital Signature and Key Encipherment.

• X509v3 Extended Key Usage: This is more specific than Key Usage. It defines the purpose of the public key in a particular context. For TLS/SSL, the most important one is:

  • TLS Web Server Authentication: This explicitly states the certificate can be used to authenticate a server in a TLS handshake. Without this, a browser might reject it even if other fields look okay.
  • TLS Web Client Authentication: For client certificates, allowing a client to authenticate itself to a server.

• X509v3 Subject Alternative Name (SAN): This is arguably the most important extension for modern web security. It lists all the hostnames and IP addresses that this certificate is valid for. Browsers strictly check that the hostname they are connecting to exactly matches one of the entries in the SAN list. Historically, only the Subject’s Common Name (CN) was used, but SANs allow for multiple names, making them far more flexible. You’ll see entries like DNS:example.com, DNS:www.example.com, IP Address:192.168.1.100. A certificate must have either a CN or a SAN entry that matches the requested hostname.

• X509v3 Basic Constraints: This extension is critical for distinguishing between end-entity certificates (like your web server’s) and CA certificates.

  • CA:FALSE: Indicates this is an end-entity certificate, not a CA.
  • CA:TRUE: Indicates this is a CA certificate, which can be used to sign other certificates. It also has a pathlen parameter, which limits how many intermediate CA certificates can follow this one in a chain.

• X509v3 CRL Distribution Points: This tells clients where to find a Certificate Revocation List (CRL) for this certificate issuer. CRLs are lists of certificates that have been revoked before their expiry date.

• X509v3 Authority Information Access (AIA): This extension provides URIs for obtaining the issuer’s certificate and for certificate status checking (OCSP).

When a client (like your browser) connects to a server, it receives the server’s certificate. It then performs a series of checks:

1. Trust Anchor: Does the certificate’s issuer chain up to a root CA that the client trusts? This involves examining the Issuer field and then looking for the issuer’s certificate (often provided by the server as an "intermediate certificate"). This forms the "certificate chain."
2. Validity Period: Is the current date within the Not Before and Not After dates?
3. Revocation Status: Has the certificate been revoked? This is checked via CRLs or OCSP, often using information from the CRL Distribution Points or Authority Information Access extensions.
4. Hostname Match: Does the hostname the client is trying to reach match any of the Subject Alternative Names or the Subject’s Common Name?
5. Key Usage: Are the Key Usage and Extended Key Usage extensions appropriate for the connection type (e.g., TLS Web Server Authentication for HTTPS)?

The certificate chain itself is a fundamental concept. A server usually sends its certificate and any intermediate certificates needed to link it back to a trusted root. For example, a chain might look like: Leaf Certificate (your server) -> Intermediate CA Certificate -> Root CA Certificate (trusted by browser). The openssl x509 -text -noout command shows the certificate’s own fields and extensions, but to see the full chain, you’d typically use openssl s_client -connect example.com:443 -showcerts.

The Subject Alternative Name extension is often the most misunderstood part of certificate validation. Many people still think the Subject’s Common Name (CN) is king, but for modern TLS, SANs are the primary mechanism for matching hostnames. A certificate can have a CN and multiple SAN entries, and the browser will check all of them. If a certificate is issued for example.com but the CN is www.example.com and there are no SAN entries, a connection to example.com will fail validation.

Understanding how these extensions, particularly SAN and Extended Key Usage, interact with the trust anchor and validity period is key to troubleshooting certificate issues and correctly configuring your web servers.

The next hurdle you’ll face is understanding OCSP stapling and how it dramatically improves performance and privacy during the TLS handshake.