Certificate Extensions – Basic Constraints

Certificate extensions are an integral part of the certificate structure as per X.509 standard for public key certificates. This structure is expressed in a formal language called Abstract Syntax Notation One (ASN.1).
There are a number of certificate extensions in the structure of a certificate. In this article, we will discuss the Basic Constraints certificate extensions. The details corresponding to Basic Constraints can be found in the following RFC:
www.tools.ietf.org/html/rfc5280#section-4.2.1.9
The Basic Constraints certificate extension has the following ASN.1 structure as per the RFC standard:
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
The X.500 was the first version where it was not possible to identify the certificate subject/holder in the structure. Later came, X.509 standard structure which was improved to identify the subject. The following fields can be found in the Basic Constraints structure:
Subject type denotes the holder of the certificate and it can be of two types:
The holder of this certificate is a CA
The holder of this certificate is an End Entity like domain/organization etc.
Path Length (although an optional field) denotes how many CA’s there are under a CA. For example, a CA with a Path length constraint of 0 cannot have any subordinate CAs which can issue certificates to other end entities.
CA certificates are used for the following purposes:
Basic Constraints for a CA certificate can be found in the following way
From the above CA screen shot, we can clearly see that the Subject type is given as “CA” and there is no defined path length for the certificate. This means that the certificate holder is the CA and unlimited certificates are allowed in the certificate chain under this CA.
The “certificate chain” for a certificate can be found in the following way:
From the certification chain in the screen shot, it is clear that there are 3 certificates in the chain. The first two certificates are CA certificates and the third certificate is the end entity certificate, as CA certificates are those at the top of the order and the last certificate in the chain belongs to an end entity.
End entity certificates are used to authenticate end entities (user, device, domain etc.) to clients including: TLS, S/MIME, and encryption certificates. The End Entity certificates can be found in the following way:
In the screen shot, we can observe that the “Subject Type” field is “End Entity” and the path length field “None” implies that this certificate cannot be used to issue/sign other certificates. Also, if Basic Constraint is not included in the certificate structure, the certificate is, by default, meant to be an End Entity certificate.
In the certificate chain diagram above, the first certificate specifies a path length constraint 2 which means there could be a maximum of 2 CA certificates under this certificate, other than the end entity certificate.
Next in the hierarchy, the second certificate specifies the path length constraint 1. This condition also holds true because there is only one CA certificate under this certificate.
The third certificate in the list specifies the path length constraint 0. This condition holds true as there is no CA certificate under this certificate.
The path length constraint restriction is not applicable to the final certificate, as it is an end entity certificate.
The Basic Constraint certificate extension is critical in restricting any End Entity certificate to issue/sign any other certificates, as this is a violation of the Basic Constraints certificate extension. Only certificates issued with “Subject Type” as “CA” and with the “Path Length” attribute would be able to issue/sign other certificates.
February 21, 2025
October 9, 2024