Chapter 3 of 8

Inside an X.509 certificate

A guided tour of the fields and extensions a client actually enforces.

About 12 minutes of reading

By the end of this chapter you can

  • Name the core fields of an X.509 v3 certificate
  • Explain what Subject Alternative Name and Extended Key Usage control
  • Read a certificate with openssl and identify the issuer and validity
  • Predict which validation errors a given certificate will cause

01The envelope and the claims

X.509 is the standard format for public key certificates. Think of it as an envelope with three parts: the certificate's own data, the algorithm used to sign it, and the CA's signature over that data. Once signed, nothing inside can change without breaking the signature.

FieldWhat it holdsWhy you care
VersionUsually v3v3 is what adds extensions
Serial numberUnique per issuing CAUsed in revocation lists and audits
IssuerName of the signing CATells you who to ask next in the chain
ValidityNot-before and not-after datesExpired certificates fail validation outright
SubjectWho the certificate is aboutFor TLS the hostname usually lives in SAN instead
Subject Public Key InfoThe public key and its algorithmThe actual credential being vouched for
ExtensionsConstrained additional factsWhere most validation failures originate
SignatureCA's signature over the aboveMakes the document tamper evident

02Extensions do the real work

If you remember one thing from this chapter, remember this: modern clients decide almost everything from extensions. A certificate with the right subject but the wrong Extended Key Usage will be rejected by a browser for a web server.

Subject Alternative Name (SAN)
The hostnames, IP addresses or identities the certificate is valid for. Browsers ignore the subject common name for hostname matching.
Key Usage
A bit mask limiting what the key may do: sign, encrypt, sign certificates, and so on.
Extended Key Usage (EKU)
A purpose list such as serverAuth, clientAuth or codeSigning. It answers 'valid for what?'.
Basic Constraints
Marks whether the certificate is a CA and, if so, how deep a chain may run below it.
Authority Key Identifier
Which issuer key signed this certificate, useful when a CA has several keys.
CRL Distribution Point / AIA
Where to find revocation lists and the issuer's own certificate.

03Reading a certificate yourself

The fastest way to build intuition is to look at real certificates. The openssl command line prints everything, in a format you will see in textbooks and incident reports.

echo | openssl s_client -connect securetron.net:443 -servername securetron.net 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Fetch and inspect the certificate a server presents

Three outputs are worth checking every time: the issuer (who vouched for this), the dates (is it still valid), and the SAN list (does it cover the name you asked for). A fourth check — does the certificate include the intermediate certificates — is covered in the chain chapter.

04From fields to failures

SymptomField or extension to inspect
Hostname mismatchSubject Alternative Name — does it list the exact name?
Certificate has expiredValidity — not-after date
Certificate is not valid for this purposeExtended Key Usage
Certificate is a CA but constrainedBasic Constraints and path length
Unable to get local issuer certificateIssuer plus the chain the server sends

When a certificate error appears, do not guess. Read the certificate, find the field that disagrees with the client's expectation, and fix the issuance process rather than the client.

What to remember

  • X.509 is a signed envelope of fields plus extensions
  • Clients enforce extensions: SAN for names, EKU for purpose, Basic Constraints for CA rights
  • openssl x509 turns a certificate into readable facts in one command
  • Most certificate errors map to one specific field you can inspect