Invariant Properties

Introduction to Digital Certificates, Part 3: X509v3

Bear Giles | May 29, 2012

This is part of a series on Digital Certificates.

Now that we know what an “ID” is we can quickly understand the big picture with X509v3 certificates.

A X509v3 certificate must contain:

Serial Number: unique for each issuer
Subject Distinguished Name: subject’s Name (X500)
Issuer Distinguished Name: issuer’s name (X500)
Not Before: the earliest date/time the certificate may be used
Not After: the last date/time the certificate may be used
Public Key: how the certificate is bound to the subject
Signature Algorithm: how the issuer’s signature is made
Signature: how the certificate is bound to the issuer

As you can see the certificate contains the core characteristics of an ID – it identifies the subject, issuer, a way to identify the subject (the key), a way to prove the issuer produced the certificate (the signature), and immutability (again, the signature).

The serial number has an arbitrary length. Many CAs use a UUID so you must be prepared to handle at least that many digits.

The subject and issuer are identified by X500 names. This is the same format used by LDAP directories and in fact they’re part of the same set of standards. You should try to adhere to conventions even if you will only use your certificates internally – it gives you the best shot at reusing existing software libraries and applications.

The most important X500 name attribute for servers is the “Common Name” (CN) – many applications require it to match the server’s hostname or DNS name.

A “self-signed” certificate uses the same value for subject and issuer.

The “not before date” and “not after date” are self-explanatory. The date range of a certificate should not exceed the date range of the signing certificate.

The “signature” is a cryptographic signature of the contents of the certificate. It is made with the issuer’s private key and can be verified with the issuer’s public key. The issuer’s public key may be known to the client through other trusted means or via PKIX (public certificate authorities). The signature should not be blindly trusted.

Digital certificates are encoded in a well-known predecessor to XML: ASN.1 (Abstract Syntax Notation One). Each field is tagged with a tree of numbers, e.g., “1.2.840.113549.1.1.11”, to identify its contents. These numbers are registered at a central authority so they’re always unique – you don’t have to worry about two companies using the same tag for different purposes.

You should always use a library to read and write ASN.1 documents. The format is difficult to work with and there’s no benefit in rolling your own.

Extensions

X509v3 certificates offer several standard extensions and an issuer can always add its own extensions as well – just remember to go through the formal process to get unique ASN.1 tags.

Extensions can be marked ‘critical’ or ‘noncritical’. The user of a certificate is expected to gracefully handle noncritical extensions but must understand and handle any critical extensions. If a critical extension is not understood the certificate should be refused.

Basic Constraint

This critical extension indicates whether a certificate can be used to sign other certificates. There is no technical reason why you can’t use any certificate to sign another certificate but PKIX policy (discussed later) requires this.

The basic constraint has an optional “certificate path length” that indicates how deep the certificate chain can be below this point. It can be used to delegate authority by creating certificates that can be used to sign normal “leaf” certificates but not additional “signing” certificates.

Subject Alternate Names

This noncritical extension contains one or more alternate name for the subject. The most common uses are email address or IP Address (for servers).

N.B., there is a well-known hack that can embed an email address in an X500 name but this technique is more correct. In practice many clients ignore this extension so you should use both approaches.

Issuer Alternate Names

Same thing, but for issuers instead of subjects.

Key Usage

This critical extension indicates the acceptable usages for this certificate. There are a number of flags but the overall gist is that you can use these flags to indicate whether a certificate should be used to sign other certificates, for servers, or for individuals. You usually want separate certificates for each purpose.

Flags:

Digital Signature
Nonrepudiation
Key Encipherment
Data Encipherment
Key Agreement
Key Certificate Signing
CRL Signing
Encipher Only
Decipher Only

Extended Key Usage

This noncritical extension elaborates on acceptable usages.

Subject Key Identifier

This noncritical extension offers a standard shorthand reference for the certificate’s public key. It is a good searchable index since the public key itself can have arbitrary length.

Authority Key Identifier

This noncritical extension offers a standard shorthand reference for the certificate’s issuer’s public key. This can be used to quickly establish certificate chains.

Search Criteria

There are several search criteria identified by RFC4387. They can give you an idea about what creates a good search key. (Note: a truncated search key is fine for your own use – you only need the full search key if you have a public certificate repository.)

Certificate Hash / Fingerprint

This is the SHA-1 hash of the entire certificate (in DER format). You can easily get this using OpenSSL tools.

Name

The subject’s Common Name.

sHash

The Base64-encoded SHA-1 hash of the subject’s DN, in DER format. OpenSSL provides a truncated form of this in hex.

iHash

The same thing but for the issuer.

iAndSHash

The Base64-encoded SHA-1 hash of the certificate’s issuer and serial number. The last values should be unique.

sKIDHash

The base64-encoded SHA-1 hash of the certificate’s subject key identifier. This hash is on the key identifier itself, not the entire SKID extension.

In the real world…

In the real world clients often do not check or honor the extensions. Certificate authorities may use expired certificates or certificates lacking the basic constraint.

The bottom line is that you have to have very low standards if you accept public certificates. In contrast certificates intended for internal use can and should be carefully checked.

Vulnerabilities and Attacks

The serial number, X500 names, and public key have essentially unlimited length. This must be kept in mind if you accept certificates from the public – malicious certificates have been seen that attempt to trigger buffer overruns in order to execute arbitrary code.