X.509: the certificate fields, version scoping, and revocation

What a certificate is, in one sentence

A public-key certificate binds a public key to the identity of its owner, with the whole block signed by a trusted third party. Anybody can verify it, provided they can already verify the certifying authority's public key — which is the entire recursion that a PKI exists to terminate. X.509 is the format with the broadest acceptance by a wide margin: it is what IPsec, TLS and S/MIME all consume, and the Internet profile of it is RFC 5280.

Be careful with a distinction the exam likes. X.509 is the certificate format standard. PKIX is the IETF working group and the profile it wrote — a set of choices about how X.509 is used on the Internet. Format versus profile: if a question asks which standard is "universally accepted for formatting public-key certificates", the answer is X.509, and PKIX is the distractor that catches people who know just enough.

The fields, in order

Read a certificate top to bottom and this is the order:

1. Version
2. Certificate serial number — unique within the issuing CA, and therefore sufficient by itself to identify the certificate
3. Signature algorithm identifier
4. Issuer name — the CA
5. Period of validity — not-before and not-after
6. Subject name — the key owner
7. Subject's public key information — the algorithm, its parameters, and the key
8. Issuer unique identifier
9. Subject unique identifier
10. Extensions

…followed by the Signature, which is present in every version and is always last.

The version scoping is a favourite detail. Version 1 carries fields 1–7. Version 2 adds the two unique identifiers, giving 1–9. Version 3 adds Extensions, giving 1–10. Current certificates are v3, and the extension mechanism is why: it is the general-purpose slot that lets the format absorb new requirements without a new version.

Issuer is the CA; subject is the key owner. That pair is reversed more often than any other on this topic.

Worked example — inspecting one certificate, finding four problems

Here is a certificate presented by a server, with everything determinable from its own contents.

Version:              3
Serial number:        0x1f 8c 44 a2
Signature algorithm:  md5WithRSAEncryption
Issuer:               CN=Northgate Commercial CA, O=Northgate, C=CA
Validity:             notBefore 2000-01-14, notAfter 2003-01-14
Subject:              CN=orders.northgate.example, O=Northgate, C=CA
Subject public key:   RSA, 512 bit
Extensions:
  Basic Constraints:  CA:FALSE
  Key Usage:          digitalSignature, keyEncipherment

Four independent findings, each of which alone is disqualifying.

(1) It is an end-user certificate, not a CA certificate. Basic Constraints: CA:FALSE decides that, and nothing else does — not its position in a chain, not who issued it. So this certificate may not be used to sign other certificates. If you find it as an intermediate in a chain, the chain is invalid.

(2) It is expired. notAfter is in the past, so it is not valid, full stop. Validity is a hard window, not a preference.

(3) The signature algorithm is broken for this purpose. MD5 collisions are constructible, and constructing a collision lets an attacker prepare two certificates with the same hash — one innocuous and submitted for signing, one hostile — so that a signature legitimately issued over the first also verifies over the second. That is the forgery model that killed MD5 in certificates, and it needs collision resistance, not merely second-preimage resistance.

(4) The key is far too small. RSA-512 was factored in August 1999. This certificate was issued in January 2000 — the key was already known to be breakable before the CA signed it. A verifier who checks only the signature and the dates passes a certificate whose private key an attacker could simply compute.

Revocation — a published list, or a live question

Certificates outlive their trustworthiness. A key is compromised, or a rekey is forced by a software upgrade, and the certificate must be withdrawn before its notAfter date. There are two mechanisms.

A certificate revocation list (CRL) is a signed object issued by the CA carrying the signature algorithm, the issuer name, this-update and next-update dates, a list of revoked certificates — each entry just a serial number and a revocation date, because the serial number alone identifies the certificate — and the issuer's signature. The standard says an application receiving a certificate should check the current CRL. The standard also admits, with unusual candour, that because of the overhead of retrieving and storing these lists, very few applications actually do. When Heartbleed forced the mass revocation and reissue of server certificates, that gap stopped being theoretical.

OCSP (RFC 6960) replaces the list with a live query: ask the CA about this one certificate, get a signed answer. It is fresh and cheap for the client, at the cost of a round trip on the critical path, an availability dependency on the responder, and a privacy leak — the CA now learns which sites you visit. The address of the responder travels in the Authority Information Access extension.