I’ve been meaning to write a primer on certificates for about a decade now. Certificates are a ubiquitous piece of modern engineering infrastructure that we collectively spend very little time discussing. Hopefully I can demystify some of the inner-workings so the next time you get a goofy certificate error you’ll at least have something to refer back to.
This might become “Part 1” of a larger set if you find it helpful :-). So feel free to offer suggestions + feedback.
The Certificate File
Certificates essentially come in two flavors: DER and PEM. Telling them apart is very easy. DER is a binary encoding format
DER encoded certificate
PEM encoding starts with the much prettier, well-known header:
PEM encoded certificate
If you wanted to inspect the contents of a PEM certificate you would use:
openssl x509 -in root.pem -text
and if you wanted to read a DER certificate you would add the -inform der
flag.
openssl x509 -in root.der -inform der -text
The Body Elements
Just about everything you need to know about certificates can be understood locally by looking at certificate files. There’s really nothing special happening in them.
We’re going to go section by section explaining the pieces. I’ll present them in the same order that openssl’s x509 text presents them.
Data
Certificate Data & Serial Number
Every certificate you are likely to ever see is version 3. I have never seen a non-v3 in the wild.
Serial numbers though are interesting. These are unique and tracked by certificate authorities to track issued certificates. If you were to go looking through a Certificate Revocation List (CRL) you would be searching by serial number.
Signature, Issuer, and Subject
Algorithm, Issuer, and Subject
The signature algorithm explains how this particular certificate is to be validated. In this case we’re saying that if you want to validate this certificate you’ll need to calculate a SHA-512 of the certificate body and use the public key of the issuer certificate to make sure the signature matches. In this case, because the issuer matches the subject, this is a self-signed certificate (and later when we talk about extensions it will be identified as a CA). All root certificates are self-signed like this.
Both the issuer and the subject field are made of a “Distinguished Name.” A distinguished name is technically an X.500 Name so if you thought this looked… ldap-y that’s why. The distinguished name may include:
CN=commonName
OU=organizationUnit
O=organizationName
L=localityName
S=stateName
C=country
For the purposes of the internet, the common name is what’s used for matching a hostname. So my certificate above would name match for https://squanderingti.me because it’s the common name (cn) of the subject.
Subject Key Info
Public Key Information
The juicy crypto bits. If you don’t care about the innards of RSA you can safely ignore these fields. This is an RSA key that’s 2048 bits in length. Then it’s the bytes of the modulus and exponent. The value 65,537 is the commonly selected exponent for a variety of reasons.
X.509v3 Extensions
X.509 V3 Extensions
The V3 extensions are the real meat & potatoes of the certificate body. These define some niceties and how the certificate may be used.
Subject Key Identifier
The subject key identifier is a hash of the public key body. It’s used for making additional cert lookups fast.
Key Usage
The Key Usage says what this certificate’s key is authorized (by the certificate authority) to perform. From the standard, RFC 3280, this field may contain:
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
OpenSSL displays keyCertSign as “Certificate Sign.” That means this public
key is usable for signing other certs. That makes sense since it’s a root.
However, if you tried using this certificate on a local http server for
playing around you would notice some clients would reject it outright because
it lacks the key usage of dataEncipherment, and keyEncipherment. It’s sort
of an additional protection to make sure a CA certificate isn’t used for non-
approved uses… but relies on the checker to verify usage bits. In my
experience few libraries check usage flags.
Criticality
Also of note is that ‘critical’ flag. Any extension marked as critical means “Dear SSL/TLS library: If you do not know how to interpret this extension then you must reject me immediately.”
Extended Key Usage
Extended key usage came later and is sometimes used for clarifying intent. I included it in my root in this example but it’s usually used on end certificates. The values outlined in the spec are:
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
but if you were feeling industrious you could put any OID in this field.
Basic Constraints
Basic Constraints only contains two possible values: “is this a CA?” and “maximum path length.” If you sign a certificate (let’s say ‘A’) by another certificate (‘B’) and the issuing certificate(‘B’) doesn’t have this flag set your new certificate (‘A’) will be rejected. Path length says the maximum number of signing certificates that can exist between this certificate and the end certificate being verified (this prevents an intermediate certificate being lost).
Authority Key Identifier
The Authority Key Identifier is a hash of the issuing entity’s public key. This makes it fast to search the local trust store/certificate list. In this case you can see the Subject Key Identifier and the Authority Key Identifier match.
Subject Alternative Name
Google’s SAN on 5/15/19
This has become a very common extension. This is used when the subject of the certificate may have multiple names. If you request a wildcard cert that should work on multiple domains like ‘*.squanderingti.me’ then the wildcard will be placed inside the Subject Alternative Name field. As you can see in the example, it’s possible to cram quite a few DNS names into this field.
Certificate Policies
The policies are essentially where certificate issuance and contract law meet. An issuer may include policy identifiers saying under what terms the certificate was issued and what would be required for revocation or some such. If you wish to read Google’s PKI policies you can search that first OID
CRL Distribution Points
The CRL distribution point is where you would go to find the entire list of certificates that this certificate’s issuer has revoked. CRLs are special signed lists containing all the serial numbers of certificates that should be considered bad.
Certificate Authority Information Access
For long-lived issuing authorities, they might have revoked a lot of certificates over the years. For instance, if a customer requests a re- issuance of a cert, which happens through the normal course of business, then the old one has to be revoked. So instead of having to download a potentially massive CRL you can use the Online Certificate Status Protocol (OCSP) to quickly check a serial number.
The CA issuers is a link to locate the certificate body of the issuer.
