Basic Constraints certificate extension

PKI Solutions Logo

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 § 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.


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:

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.

About Vadims Podāns

Senior PKI Developer


  1. Ernest on May 12, 2021 at 1:25 am

    Hi Vadims

    Trust you are very well,

    Quick question, if a two Teir AD CS was installed whereby the Root CA cert has a Basic Constraint of 1
    It then turns out another level of CA is required but at the same time minimum disruption is required to the existing system (issued certs, CRLs)

    Is the best option to Renew the Root CA cert using the ‘same keys’ (assuming there is still pelenty of life left in the key pair). Then use a CAPolicy.inf when renewing the CA Root Cert to extent the depth e.g. (from one of your blog posts)

    Signature= “$Windows NT$”




    Thanks Vadims

    • Vadims Podāns on May 12, 2021 at 1:33 am

      In this case, you need to renew CA with new key pair. And it a good practice to not put any constraints in root CA certificate. Its role is to provide a trust anchor functions, nothing else. All constraints must be set at lower levels. Intermediate CA certificate renewal/replacement is much easier (from administrative efforts and expenses perspective) than replacing/renewing root CA.

  2. Ernest on May 17, 2021 at 9:10 am

    Hi Vadims

    Thanks very much, the issue was come across an existing CA (two-tier) where the root CA had a basic constraint of 1 and now they want to add a third tier of CA but minimize disruption for existing systems. Therefore thought to renew CA Root cert with the same key pair (not best practice normally) and at the same time remove the issue of 1 level of CA (but as you say do not enter any basic constraint for the new root CA cert). Just thought this option easier overall in this situation.

    However, I will refresh my memory by going over your post here,CA%20cert%20without%20any%20changes.

    Thanks again

    • Vadims Podāns on May 17, 2021 at 9:32 am

      Even renewal may cause random issues with wrong chain until new root CA certificate is completely propagated to all clients. This kills all the benefits you get from key reuse. Even in your case, I would recommend to go with new key pair and new root chain.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.