Name Constraints in x509 Certificates

One of the major problems with understanding x509 certificates is the sheer complexity that they can possess.

At a core level, a certificate is quite simple. It’s just a pair of asymmetric keys, a subject name and an issuer name saying who’s certificate it is. However things quickly get complicated, especially around the extensions defined in RFC5280 and how they can be applied.

So for my own benefit, I’m going to try to break some of the concepts down into easily understandable terms or explainations. I want to be able to Google myself for this information later, as I will surely forget it. If somebody else benefits from this, then even better.

So, The Name Contraints Extension

Defined here, Name Constraints are only used in CA Certificates.

The extension defines the name spaces that all subject names in issued certificates by the CA certificate must be located.

In particular, these name constraints will just apply to the Subject Name and Subject Alternative Names. So, a subject certificate with a name that does not meet the constraints in the CA certificate will not be considered valid when a client tries to determine if it’s trusted or not.

A common name constraint is one using a URI (Uniform Resource Indicator). If you’ve seen constraints before like this, you might’ve seen two entries for a domain, like this:

• timothy-quinn.com
• .timothy-quinn.com

First off, the dot (.) prefix for .timothy-quinn.com indicates that any sub-domains will be accepted under timothy-quinn.com, e.g. mail.timothy-quinn.com and northamerica.cdn.timothy-quinn.com. However that dot prefix doesn’t cover timothy-quinn.com by itself, which is why we need the two entries.

This applies as well to the other name types, like Email Address and DNS names, and you can also apply restrictions for IP ranges by defining class-based licence restrictions.

And, if you really want to get fancy, you can exclude names as well. So you might have .timothy-quinn.com allowed but test.timothy-quinn.com not allowed.

So why would you use this extension? Some reasons:

• You can restrict a CA to only issuing certificates within a specific domain, say a CA purposely designed to only issue device certificates. A CA might be exposed to some risks to allow it to operate, so these constraints help mitigate attack vectors.
• You wish to have signed emails only trusted from a particular domain.
• You wish to Cross Certify with another CA to establish trust with another group, but you don’t want to trust all of their certificates, you just care about a specific subset.

Now Cross Certification is probably the biggest use-case of this extension. When it comes to certificates, they can be generated and signed in a variety of different methods. An organisation may have some keys stored inside Hardware Security Modules, some stored in the Windows Certificate Store and some sitting as PKCS#12 files on a flash drive. Some may be individually created using some process (like with Smart Cards), and others may be automatically created with software (like SCEP and Auto Enrolment). Because of this, you may trust that some of the certificates are being managed correctly, but others may not.

It’s really not difficult for an administrator to export a key from the machine store if they have admin rights to the machine.

So for Cross Certification, it’s a good measure to apply some Name Constraints to the CA certificate, to prevent any old certificate (under that CA) being trusted.