Hi Andrew,
Can you provide the actual subject DNs for each certificate? RFC 5280 specifies
that self-issued certificates (i.e., issuer DN == subject DN) are not
considered in the pathLen calculation, so knowing whether these certificates
are self-issued or not may be helpful in better diagnosing the issue.
Thanks,
Corey
From: openssl-users On Behalf Of Andrew
Lynch via openssl-users
Sent: Friday, September 16, 2022 4:32 AM
To: openssl-users@openssl.org
Subject: AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to
1.0.2?.
So is this a possible bug or a feature of OpenSSL 1.1.1? (using 1.1.1n right
now)
If I set up the content of CAfile or CApath so that E <- D <- C <- A is the
only path that can be taken then the validation fails with
error 25 at 3 depth lookup: path length constraint exceeded
If I create the first root certificate (A) with pathlen:2 instead of pathlen:1
then validation succeeds
user1_cert.pem: OK
Chain:
depth=0: C = DE, O = Test Org, CN = Test User (untrusted) E
depth=1: C = DE, O = Test Org, CN = Test Sub-CA D
depth=2: C = DE, O = Test Org, CN = Test Root 2-CA C
depth=3: C = DE, O = Test Org, CN = Test Root 1-CA A
So it appears to me that OpenSSL 1.1.1n is definitely taking the pathlen
constraint of certificate A into account.
Andrew.
Von: Erwann Abalea mailto:erwann.aba...@docusign.com> >
Gesendet: Donnerstag, 15. September 2022 19:51
An: Andrew Lynch mailto:andrew.ly...@atos.net> >
Cc: openssl-users@openssl.org <mailto:openssl-users@openssl.org>
Betreff: Re: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to
1.0.2?.
Assuming that all self-signed certificates are trusted (here, A and B), then
providing a CAfile with D+C+B+A to validate E, the different possible paths
are:
- E <- D <- B: this path is valid
- E <- D <- C <- A: this path is valid
In the validation algorithm described in RFC5280 and X.509, the
pathlenConstraints contained in the certificate of the Trust Anchor (here, A or
B) is not taken into account. Therefore, the only ones that matter are the
values set in C and D, and these values are coherent with both chains.
On Thu, Sep 15, 2022 at 7:34 PM Andrew Lynch via openssl-users
mailto:openssl-users@openssl.org> > wrote:
Hi,
I would like to have my understanding of the following issue confirmed:
Given a two-level CA where the different generations of Root cross-sign each
other, the verification of an end-entity certificate fails with OpenSSL 1.1.1 –
“path length constraint exceeded”. With OpenSSL 1.0.2 the same verify succeeds.
All Root CA certificates have Basic Constraints CA:TRUE, pathlen:1. The Sub CA
certificate has pathlen:0.
A) Issuer: CN=Root CA, serialNumber=1
Subject: CN=Root CA, serialNumber=1
B) Issuer: CN=Root CA, serialNumber=2
Subject: CN=Root CA, serialNumber=2
C) Issuer: CN=Root CA, serialNumber=1
Subject: CN=Root CA, serialNumber=2
D) Issuer: CN=Root CA, serialNumber=2
Subject: CN=Sub CA, serialNumber=2
E) Issuer: CN=Sub CA, serialNumber=2
Subject: Some end entity
With a CAfile containing D, C, B, A in that order the verify of E fails. If I
remove the cross certificate C then the verify succeeds.
I believe OpenSSL 1.1.1 is building a chain of depth 3 (D – C – A) and so
pathlen:1 of A is violated. Without the cross certificate the chain is only
depth 2 (D – B).
Is my understanding of the reason for this failure correct?
Why is OpenSSL 1.0.2 verifying successfully? Does it not check the path length
constraint or is it actually picking the depth 2 chain instead of the depth 3?
Regards,
Andrew.
--
Cordialement,
Erwann Abalea.
smime.p7s
Description: S/MIME cryptographic signature
