X.509 certificates are essentially just structured data, but the real magic isn’t in what they are, but how the absence of certain fields or the misinterpretation of others can silently break everything.
Let’s see one in the wild. Imagine a web server with a certificate that looks something like this (simplified):
{
"version": 3,
"serialNumber": "0123456789abcdef",
"signatureAlgorithm": "sha256WithRSAEncryption",
"issuer": {
"countryName": "US",
"organizationName": "Example CA",
"commonName": "Example Intermediate CA"
},
"validity": {
"notBefore": "2023-01-01T00:00:00Z",
"notAfter": "2024-01-01T00:00:00Z"
},
"subject": {
"countryName": "US",
"stateOrProvinceName": "California",
"localityName": "San Francisco",
"organizationName": "Example Corp",
"commonName": "www.example.com"
},
"subjectPublicKeyInfo": {
"algorithm": {
"algorithm": "rsaEncryption",
"parameters": {
"rsaModulusLength": 2048,
"rsaPublicExponent": "65537"
}
},
"publicKey": "..." // Actual public key data
},
"extensions": [
{
"extnId": "2.5.29.15", // keyUsage
"critical": true,
"value": "digitalSignature, keyEncipherment"
},
{
"extnId": "2.5.29.17", // subjectAltName
"critical": false,
"value": [
{"dNSName": "www.example.com"},
{"dNSName": "mail.example.com"}
]
},
{
"extnId": "2.5.29.19", // basicConstraints
"critical": true,
"value": {
"cA": false,
"pathLenConstraint": null
}
}
]
}
This JSON represents a typical TLS certificate. At its core, it’s a public key, information about who owns it (the subject), and who vouches for it (the issuer). The validity tells you when it’s good until. But the extensions are where most of the interesting, and often problematic, functionality lives.
The keyUsage extension (OID 2.5.29.15) dictates what cryptographic operations the public key in this certificate is allowed to perform. For a server certificate used in TLS, you’d expect digitalSignature and keyEncipherment. If keyEncipherment was missing, a client might reject the certificate because it can’t use the key to establish a secure session. The critical flag means that if a system doesn’t understand this extension, it must reject the certificate.
The subjectAltName (SAN) extension (OID 2.5.29.17) is arguably the most crucial for modern web security. It lists all the hostnames and IP addresses that this certificate is valid for. The commonName (CN) in the subject field used to be the primary way to match hostnames, but it’s deprecated in favor of SAN. If a client connects to www.example.com and the SAN only contains mail.example.com (and no CN match or a CN mismatch), the connection will fail. SANs can include dNSName (for hostnames) and iPAddress.
The basicConstraints extension (OID 2.5.29.19) is critical for distinguishing between Certificate Authorities (CAs) and end-entity certificates. If cA is true, it’s a CA certificate and can sign other certificates. If cA is false (as in our example), it’s an end-entity certificate and cannot sign others. The pathLenConstraint limits how many intermediate CA certificates can follow this one in a chain.
Validation is a multi-step process. First, the client checks if the certificate’s subject name (via SAN or CN) matches the hostname it’s trying to connect to. Then, it checks the validity period. Next, it verifies the certificate’s signature using the public key of the issuer. This involves a chain of trust: the server’s certificate is signed by an intermediate CA, which is signed by a root CA. The client must be able to trace this chain all the way back to a root CA certificate that it trusts (usually pre-installed in the operating system or browser). Each signature in the chain must be valid. Finally, it checks the critical extensions.
The one thing most people don’t realize is that the basicConstraints extension, when marked as critical and cA: true, fundamentally changes how the certificate is treated. It’s not just "a certificate"; it’s a root of trust or an intermediate authority capable of issuing new identities. If this extension is missing on a certificate that is acting as an intermediate CA, clients that strictly adhere to RFC 5280 might reject the chain because a critical extension is not present, even if the signature is otherwise valid. This is a subtle but common point of failure in complex PKI setups.
The next hurdle you’ll typically encounter after mastering certificate fields and extensions is understanding Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) – the mechanisms for determining if a certificate, even if validly signed and within its date range, has been intentionally invalidated before its expiration.