Basics: Path Length Constraint

Author Uwe GradeneggerPosted on Categories Basics, SecurityTags , ,

The attack on the MD5 signature algorithm demonstrated in late 2008 could only be used to create a usable forged certification authority certificate because the attacked certification authority had not configured any path length restriction.

The limitation of the path length is defined in the RFC 5280 described. The idea behind this is that the maximum depth of the certification authority hierarchy is stored in the "Basic Constraints" extension of a certification authority certificate.

With each certification authority level, the configured number is reduced by 1 until it is 0.

The last certification authority in the chain thus contains the value 0. No further certificate authorities are allowed below this certification authority. Even if the certification authority were to issue one, applications can detect this violation when verifying the certification authority hierarchy and refuse to process such a certificate.

Configure the limitation of the path length

The path length restriction is specified when the certification authority certificate is issued. It can be implemented in different ways:

  • It can be applied for by the enrollee certification authority.
  • It can be attached to the certificate request by an administrator.
  • It can be enforced by a policy of the parent certification authority.
  • It is basically applied when the certificate of the parent certification authority has a path length restriction.

Application by the certification authority

If a certification authority's certificate request is to request a path length restriction, this must be mapped via capolicy.inf:

[BasicConstraintsExtension]
PathLength=0
Critical=TRUE

It should be noted that the extension must be marked as critical.

Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates.

https://tools.ietf.org/html/rfc5280#section-4.2.1.9

Specifying the limitation of the path length by the parent certification authority

It is generally recommended not to set a path length restriction for root certification authority certificates, as this deprives the root certification authority of much of its flexibility. A change in the value requires the issuance of a new certificate, which in the case of a root certification authority involves a great deal of effort to redistribute the trust status

This option is particularly useful for root certification authorities. Thus, it is not necessary for it to have a path length restriction hardcoded into the certification authority certificate. However, it will act as if this were the case when issuing a subordinate certification authority certificate.

This can be achieved with the following command line command (start command line as administrator):

certutil -setreg Policy\CAPathLength {value}

If you want to limit the certification authority hierarchy to two studen, enter a value of 1.

The certification authority service must be restarted for the change to take effect.

Demonstration: Violating the Path Length Constraint and Detecting the Violation

In the following example, we create a certificate chain where an issuing certification authority has a path length constraint of 0, meaning that it cannot sign any subordinate certification authority certificate. We violate this constraint by establishing another certification authority one level below it, signed with the private key of the constrained certification authority. Last but not least, we then issue an end-entity certificate with this illegitimate certification authority and check if the policy violation is detected.

For the demonstration the PSCertificateEnrollment PowerShell module can be used. It can be used via the PowerShell Gallery obtained and then loaded.

Install-Module -Name PSCertificateEnrollment
Import-Module -Name PSCertificateEnrollment

The following command generates a certificate for a root certification authority and stores the resulting certificate in the variable $a.

$a = New-CertificateRequest -CA -Subject "CN=Root CA" -SelfSign

Subsequently, the following command is used to create a subordinate certification authority which has a path length restriction of 0, i.e. no other certification authorities are allowed under it. The certificate is signed with the root certification authority certificate stored in the variable $a. The resulting certificate is stored in the variable $b.

$b = New-CertificateRequest -CA -Subject "CN=Sub CA" -SigningCert $a -PathLength 0

Now we simulate that the child certification authority stored in $b has been compromised and an attacker has managed to sign a certification authority certificate with it.

So in the variable $c the certificate of the unauthorized certification authority signed with $b is stored.

$c = New-CertificateRequest -CA -Subject "CN=Invalid Path Length CA" -SigningCert $b

With this certification authority, we now issue an end-entity certificate and store it in the variable $d.

$d = New-CertificateRequest -Eku "ServerAuthentication" -Subject "CN=Invalid Path Length Certificate" -Dns "www.demo.org" -SigningCert $c

The four variables now contain the generated certificate chain.

$a,$b,$c,$d

The root CA certificate must be temporarily added to the trusted root CA certificate store for the test. After the test, however, it should be removed again so as not to leave behind any security risk.

If you now open the end-entity certificate, you will notice that a warning is displayed to indicate that the certificate is not recognized as valid:

This certificate is not valid because one of the certification authorities in the certification path does not appear to be allowed to issue certificates or this certificate cannot be used as an end-entity certificate.

In the "Certification Path" tab, you can also see which part of the certificate chain triggered a policy violation. It is the "Sub CA" - the actual legitimate certification authority. It is identified as the culprit, since it is the one that mistakenly issued an unauthorized certificate out of itself of the checking logic.

Related links:

External sources

en_USEnglish
de_DEDeutsch en_USEnglish