Basic Constraints certificate extension

Hello everyone! Today I’m going to talk about X.509 Basic Constraints certificate extension.

Basic Constraints is an X.509 Version 3 certificate extension and is used to identify the type of the certificate holder/subject. In the past (prior to version 3 X.509 certificates) it was impossible to identify who is the subject: CA certificate or end entity subscriber. With the V3 profile introduction many things were improved, including subject type separation. The extension is defined in RFC 5280 §4.2.1.9 and has the following ASN.1 syntax:

id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }

   BasicConstraints ::= SEQUENCE {
        cA                      BOOLEAN DEFAULT FALSE,
        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

and extension identifies two aspects:

1. Subject type: is the certificate a CA certificate or it is an end entity certificate;
2. [Optionally] How many CAs are allowed in the chain below current CA certificate. This setting has no meaning for end entity certificates.

So, what’s the difference between subject types? How we identify them when viewing certificates?

CA certificate

CA certificate is used only to:

• sign other certificates and CRLs;
• validate the signature of issued certificates;
• [Optionally] set restrictions or constraints on the configuration of issued certificates.

CA certificate is not usually used to authenticate the CA anywhere. For example, when we access web server via HTTPS, server authenticates itself with a certificate, but it is not a CA certificate.

When we open CA certificate in GUI we can find a basic constraints extension:

We see that subject type is set to CA and there is no defined path length constraint. Last setting means that unlimited certificates are allowed in certificate chain below the current CA certificate. For more details about certificate chains read my another blog post: Certificate Chaining Engine — how it works. When examining certificate chains we see one or more certificates:

We see four certificates in the chain. Without any additional information we can clearly say that at least 3 certificates are CA certificates. CA certificates are always on top. Last certificate (selected) can be either, CA certificate or end entity certificate. Only one end entity certificate may appear in certificate chain and if presented, it is only last (leaf) in the certification path. End entity certificates cannot appear anywhere in the middle, it is always last.

If we see a number in path length constraint:

this indicates that this CA certificate is the last CA certificate in the chain. No additional CA certificates under the current one are allowed. Only end entity certificate can appear under this CA certificate in the certification path.

Note that path length constraint indicates the depth of certificate chain. With value of ‘1’ in path length constraint, you can have unlimited CA certificates right below the current CA certificate. But no CA below will be eligible to issue other CA certificates.

End Entity certificate

End entity certificates are used to authenticate end entity (user, device, service, etc.) to servers and clients, this includes (but not limited to) TLS, code signing, S/MIME, encryption certificates. We can easily identify them when viewing the certificate:

We see that subject type is set to End Entity. Path length constraint has no meaning in this case because it cannot be used to sign other certificates. Just due to cA bit.

If Basic Constraints extension is not included in certificate, it is automatically treated as end entity certificate.

Violation

Based on my experience on StackExchange forum boards, there are questions where people are looking for a way to reduce costs on certificate purchases by using their TLS certificate for other certificate signing. Just few quick examples:

• SSL sign certificate with existing certificate
• Can I purchase a certificate for my domain that can sign other certificates for subdomains?
• Email signing using commercial SSL certificate

To make this possible, CA must issue you a CA certificate. However, no CA will give you CA certificate, because you will be able to impersonate any entity, any web site, anyone. And obviously, entire PKI business will be ruined, because certificate issuance will be out of control very quickly.

When you order certificate from public CA, you will get a certificate with End Entity value in a Subject Type field. But what if you manage to sign another certificate with your existing TLS or S/MIME certificate? Let’s give it a try:

I used my personal S/MIME certificate to sign TLS certificate and checked the certification path. Certificate viewer put a yellow triangle on signer certificate and says that “the certificate does not appear to be valid for the selected purpose”. The message is not very self-descriptive, but suggests that there are issues with signer certificate. If we execute certificate chaining engine (certutil -verify) we will get more detailed explanation on what is going on:

ChainContext.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
ChainContext.dwErrorStatus = CERT_TRUST_INVALID_BASIC_CONSTRAINTS (0x400)

Now, exact error is more evident: issuer certificate has no permissions to sign other certificates. The same error will appear when you create another CA certificate under CA with ‘0’ value in path length constraint. And any properly implemented chaining engine will reject such certificate because of Basic Constraints certificate extension violation.