Basics: Path Length Constraint

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 a path length constraint.

The path length constraint is described in RFC 5280 . 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 certification 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.

Configuring the path length constraint

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

• It can be requested by the requesting 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 always applied when the certificate of the parent certification authority has a path length constraint.

Request by the certification authority

If a certification authority's certificate request is to request a path length constraint, this must be configured 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 path length constraint by the parent certification authority

This option is particularly useful for root certification authorities. Thus, it is not necessary for it to have a path length constraint 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 {Wert}

Demonstration: Violating the Path Length Constraint and Detecting the Violation

In the following example, we create a certificate chain in which an issuing certification authority has a path length constraint of 0, meaning that it cannot sign any subordinate certification authority certificates. We violate this constraint by creating another certification authority one level below, which is signed with the private key of the restricted certification authority. Finally, we use this illegitimate certification authority to issue an end entity certificate and check whether the policy violation is detected.

For the demonstration the PSCertificateEnrollment PowerShell module can be used. It can be obtained via the PowerShell Gallery 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 constraint 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 subordinate 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

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, from the point of view of the checking logic, it is the one that wrongly issued an unauthorized certificate.

Related links:

• Requesting a certification authority certificate fails with error message "The certification authority's certificate contains invalid data. 0x80094005 (-2146877435 CERTSRV_E_INVALID_CA_CERTIFICATE)"
• Use name constraints to allow a certification authority to issue certificates only for specific domain names

External sources

• MD5 considered harmful today (Eindhoven University of Technology)
• RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)