Webinar: PKI Insights - The Most Common Misconfigurations in Today's PKI
Schedule a Demo
Blog August 12, 2019 Certificates, PKI

Basic Constraints certificate extension

by Vadims Podāns

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

Person sitting at a laptop while viewing the PKI Spotlight Dashboard.

Expand Your PKI Visibility

Discover why seeing is securing with revolutionary PKI monitoring and alerting.

Learn More About PKI Spotlight®

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.

Related Resources

  • Blog Graphic with a gold background with the Globee Awards Gold Winner logo for Public Key Infrastructure PKI Cybersecurity.
    May 10, 2024

    Globee Awards Gold Winner in PKI Cybersecurity!

    PKI, PKI Spotlight
  • Blog a shield with a lock on it representing pki and certificates with several other locks and cybersecurity components in the background
    May 1, 2024

    Strengthening Security with Centralized MFA Integration

    MFA, PKI, PKI Spotlight
  • Blog
    April 29, 2024

    PKI Insights Recap – PKI Posture Management for Digital Certificates

    Digital Certificates, PKI, PKI Insights

Vadims Podāns

PKI Software Architect

View All Posts by Vadims Podāns


  • 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

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

  • 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


    Thanks again

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

  • Hello Vadims,

    There is a requirement where i am asked to create a csr and We would like to use these basic constraints:
    Basic Constraints
    Subject Type=CA
    Path Length Constraint=None
    Key Usage Certificate Signing, Off-line CRL Signing, CRL Signing (06)

    How can pass/insert these in a inf file such that I can use certreq to create a csr and keys.

    I appreciate any help here.

  • Unfortunately, inside file capolicy.inf in my company SUB CA not include option as below:

    PathLenght = 0
    Critical = true

    The SubCA Basic Constraints certificate options are as below:

    Subject Type = CA
    Path Length Constraint = None

    is it possible to somehow force the change of these settings so that this SubCA was the last in the chain and the option appeared

    Subject Type = CA
    Path Length Constraint = 0

    • You can change the capolicy.inf and then perform a renewal of the subordinate CA and it will pick up the desired path length constraint.

  • According RFC 5280:
    BasicConstraints ::= SEQUENCE {
    pathLenConstraint INTEGER (0..MAX) OPTIONAL }

    Therefore Subject Type=End Entity does not seem to have any meaning in the context of RFC 5280.
    So why some CAs do use Subject Type=End Entity?

    • > Therefore Subject Type=End Entity does not seem to have any meaning in the context of RFC 5280.

      this statement is not very accurate. SubjectType=End Entity has the same meaning as field absence.

      > So why some CAs do use Subject Type=End Entity?

      They tend to be more explicit rather than relying on default values. I don’t see any issues with CA practices that explicitly set “cA” field to False.

Leave a Reply

Your email address will not be published. Required fields are marked *