Understanding X.509

This week, we will be exploring the general architecture of X.509 to get a better idea of how it provides security for its users.

This post is intended for people who are unfamiliar with the general architecture of X.509.  I will be addressing the wide use of OpenSSL on SmartOS in a subsequent blog-post.

Overview

If you haven't done this already, the first thing when dealing with modern cryptography is wrapping your head around the major players in the X.509 standard.  Namely:

• Encryption Keys (key)
• Certificate Signing Requests (CSR)
• Public Key Certificates (CRT)
• Certificate Authorities (CA)
• Trusted Certificate Store
• Certificate Revocation Lists (CRL)
• Certification Path Validation

Encryption Keys

In Asymmetric Cryptography, encryption keys are generated and used in pairs, a widely disseminated public key which can encrypt data that may only be decrypted by the associated and closely guarded private key.  It may be better to visualize the public key as an open padlock which can be clamped onto any strongbox, and which can only be opened by the private key.  It is easy to close the padlock without the key, and difficult to open the padlock without the key.

Additionally, for authentication purposes, the private key can sign (encrypt) data which can be verified (decrypted) by anyone holding the public key.  This functionality, combined with cryptographic hash functions, means that documents can be certified as valid by a private key, and verified by any holder of the public key of a key-pair.

The concept of the key in X.509 is actually both the public and private key.  When stored as a file, it is optionally symmetrically encrypted with a password and key derivation function (KDF), due to the sensitive nature of the contained information.

Certificate Signing Requests

A Certificate Signing Request (CSR) is a well-structured, documented request to be trusted, issued by a Private Key.  It contains the following:

• The Subject: Information about the requesting key formatted in LDIF style fields.
• The Subject's Public Key: Modulus (n) and Exponent (e) in the case of RSA.
• Optional Meta-Data such as:
  • The maximum length of Certification Paths under this key
  • The possible roles of this key

The entire document is signed with the private key of the referenced key-pair to authenticate its accuracy.

Public Key Certificates

A Public Key Certificate (CRT) is the documented expression of trust by one key (issuer) of another key (subject).  In cases where the keys are the same, this is known as a self-signed certificate.  CRTs are created from the data of a CSR, combined with some additional information provided by the issuing key, all of which is signed by the issuing key.

In addition to the information in the CSR, Certificates include a Validity time frame: A field that specifies a date and time before which a Certificate is invalid, and another field that specifies a date and time after which a Certificate is invalid.

Certificate Authorities

Certificate Authorities are organizations that have created private keys, self-signed CRTs (CSRs that have been CRTed by the same key).  These self-signed CRTs are often referred to as Root Keys and are distributed in operating system installation and update pathways to end-users' trusted certificate store, with the assumption that they are trustworthy.

Trusted Certificate Store

Also commonly referred to as a Certificate Trust Store, a trusted certificate store is a secure collection of certificates held by a peer that is intrinsically trusted by that peer.  They usually contain certificates provided by CAs, but can also include additional certificates provided by intermediaries and end-users.  Any Certificates should be scrutinized carefully before inclusion into a Trusted Certificate Store.

Certificate Revocation Lists

Certificate Revocation Lists are a list of certificates (specifically a list of serial numbers for certificates) that have been revoked and should no longer be considered trusted.  These lists are signed and distributed by the certificate authority.

Certification Path Validation

One last thing to examine on X.509 is how certification path validation works.

When you combine the concept of a Certificate Authority, Trusted Certificate Store, and How Certificates are generated, you get the magic of X.509.  An otherwise un-trusted Private Key can generate a Certificate Signing Request that is fulfilled by a CA's private key which has had its public certificate globally distributed into the Trusted Certificate Stores of all peers.  This means that the everyone can reasonably assume that an otherwise un-trusted certificate is actually legitimate.

The steps to validate a certificate are as follows.  Any false answer invalidates the certificate:

• Does the certificate have a valid signature?
• Is the Issuing Certificate trusted?  ie: Is it in our Trusted Certificate Store or validated by another trusted certificate?
• Is the certificate not referenced by the signer's CRL?
• Does the service match the certificate subject? ie: A certificate that says it's for googlecom.com is invalid if you're trying to access google.com.
• Does the current date and time fall within the Certificate Validity dates?

Certificate Chains

Often times, the certificate used by an end service to provide authentication will not be directly signed by a Certificate in the other peer's trust store.  In this case, there will be at least one additional certificate between the certificate used at an application level and the trusted certificate.

This intermediate certificate should be exported with the end certificate for distribution to the client as it's a vital link in establishing the validity of the end certificate.  This collection of linked certificates is known as a Certificate Chain.

Root, Branch & Leaf Certificates

As I've alluded to in the previous section, there are Certificates which serve different roles in X.509 PKI.  Each of these Certificates has associated Keys.

Root Certificates are distributed to the Trusted Certificate Stores of a set of peers.  They are always self-signed and are intended to serve as anchors of trust for other certificates.  Because of this role, Root Keys should never be used for common encryption or authentication tasks.  It would be better yet that they are stored on physically isolated systems with access granted only to serve their function of signing other valid certificates.

Branch Certificates are used as intermediaries between Root Certificates and Leaf Certificates.  Due to the commonality of physical isolation for Root Keys, issuing Leaf Certificates becomes difficult without this intermediary.  Branch Certificates are distributed with their issued Leaf Certificates while their associated Branch Keys often reside on logically isolated yet still online systems.

Leaf Certificates are used for the authentication of services by peers with Trusted Certificate Stores.  They are either signed directly by a Root Certificate, or by one or more Branch Certificates.

Cross-Signed Certificates

On occasion, it is helpful for a single CSR to be fulfilled by multiple Issuers.  This allows multiple independent CA's to express their trust in a single Key.  It results in multiple Certificates or Certificate Chains, one for each Issuer.  Technically, repeat keys could be omitted, but this is an unlikely circumstance in how X.509 PKI normally operates.

One situation where this can occur is where no single CA has Certificates in the Trusted Certificate Stores of the majority of a given user base.  Having cross-signed leaf certificates would mean either Root Certificate could be used for validation.

Another place where this is common is when a new CA is starting operations and their Root Certificates haven't yet been fully distributed to the Trusted Certificate Stores of their user base, while another CA's Root Certificates have.  The trusted CA can sign the Branch Certificates of the new CA for a temporary workaround that lasts until the new CA's Root Certificates are fully distributed.