AW: AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.
Understood. My main reason for telling them is that Google Chrome complains bitterly when asked to download a http link from a page that was fetched with https. I hadn't noticed that yesterday because I was analyzing the problem on a Linux VM and copy-pasted all the URLs from Chrome on my desktop to wget in the VM. -Ursprüngliche Nachricht- Von: openssl-users Im Auftrag von Viktor Dukhovni Gesendet: Freitag, 16. September 2022 16:22 An: openssl-users@openssl.org Betreff: Re: AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?. On Fri, Sep 16, 2022 at 02:11:38PM +, Andrew Lynch via openssl-users wrote: ... > > I’ve also asked my colleagues why the download is http instead of > https… You should look to multiple independent sources to validate the authenticity of a trust anchor public key. Trusting "https" to prove the validity of a WebPKI trust anchor is a bit too circular. Also "https" is redundant for CRL and intermediate CA distribution, since these are signed by the issuing CA. That said, the same ".crt" file is availabe via "https": ... Trust anchor certificates are often delivered as an operating system "package", and ideally the package maintainers apply proper due diligence. -- Viktor.
Re: AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.
On Fri, Sep 16, 2022 at 02:11:38PM +, Andrew Lynch via openssl-users wrote: > http://sm-pkitest.atos.net/cert/Atos-Smart-Grid-Test.CA.2.crt > > I’ve also asked my colleagues why the download is http instead of https… You should look to multiple independent sources to validate the authenticity of a trust anchor public key. Trusting "https" to prove the validity of a WebPKI trust anchor is a bit too circular. Also "https" is redundant for CRL and intermediate CA distribution, since these are signed by the issuing CA. That said, the same ".crt" file is availabe via "https": https://sm-pkitest.atos.net/cert/Atos-Smart-Grid-Test.CA.2.crt Trust anchor certificates are often delivered as an operating system "package", and ideally the package maintainers apply proper due diligence. -- Viktor.
AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.
Oops, sorry. The correct intermediate is of course also SN2. http://sm-pkitest.atos.net/cert/Atos-Smart-Grid-Test.CA.2.crt Fingerprint a0 6d 32 c3 56 7d 8e 20 0f a3 8e d3 d0 0a 04 21 2a 0a 1e ae I’ve also asked my colleagues why the download is http instead of https… Von: openssl-users Im Auftrag von Andrew Lynch via openssl-users Gesendet: Freitag, 16. September 2022 15:53 An: Corey Bonnell ; openssl-users@openssl.org Betreff: AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?. Hi Corey, I believe Victor has explained the issue sufficiently (thanks!). Just for completeness here are the actual root certificates relevant to the question. They are part of the German national Smart Metering environment: SM-Test-Root-CA SN1 (O=SM-Test-PKI) CN=SM-Test-Root.CA, SERIALNUMBER=1, gültig bis 19.05.2023 SHA256: 97 C2 68 C8 67 D7 6C 0E 13 4C B6 C9 AF F7 A9 E3 BD 9C 4E 30 E1 F6 CB F7 8E DE 4C 3F 11 A3 8D 4D https://www.telesec.de/assets/downloads/Smart-Metering-PKI/sm-test-root.ca_sn1.der SM-Test-Root-CA Link-Zertifikat (1>2) Download CN=SM-Test-Root.CA, SERIALNUMBER=2, gültig bis 19.05.2023 SHA256: ED 54 7F 5D F0 BC 41 D9 D7 3D 92 8B 75 FE 7D B9 9C D9 23 31 78 95 BD 26 BF D2 4A AF DE EF AE 10 https://www.telesec.de/assets/downloads/Smart-Metering-PKI/sm-test-root.ca_sn2_link.der SM-Test-Root-CA SN2 Download CN=SM-Test-Root.CA, SERIALNUMBER=2, gültig bis 19.10.2025 SHA256: 1D 77 21 17 16 69 66 41 AA B2 A3 61 5F E7 8E 76 73 C9 0E 16 E0 69 66 71 47 0F A4 6A 74 FC 18 36 https://www.telesec.de/assets/downloads/Smart-Metering-PKI/sm-test-root.ca_sn2.der (All from https://www.telesec.de/de/service/downloads/branchen-und-eco-systeme/. There is an English language downloads page but that does not show the Smart Metering PKI section.) Our intermediate CA that issued the end entity certificate is http://sm-pkitest.atos.net/cert/Atos-Smart-Grid-Test.CA.3.crt Fingerprint 14 f3 d2 f8 cd 00 ca 9d f6 41 ca 5b 10 55 9c d3 ac eb cc 5a The chain Atos-Smart-Grid-Test.CA.3.crt <- sm-test-root.ca_sn2.der is fine. It is a straightforward self-signed root plus intermediate setup. The chain Atos-Smart-Grid-Test.CA.3.crt <- sm-test-root.ca_sn2_link.der <- sm-test-root.ca_sn1.der is problematic because the “link” certificate has SN2 as subject but SN1 as issuer. So I believe it is effectively adding another intermediate layer which then violates pathlen:1 in sm-test-root.ca_sn1.der. My (naïve) understanding of such link or cross-certified CA certificates is that they are intended to help systems that only have SN1 as a trust anchor to verify certificates issued by SN2. But wouldn’t they stumble over pathlen too? My colleague doing the verifying initially had all three sm-test-root.ca certificates in his CAfile and OpenSSL 1.1.1 picked the path with the link certificate. Once he removed that everything was fine as the verify then used the self-signed SN2 root directly. Regards, Andrew. Von: Corey Bonnell mailto:corey.bonn...@digicert.com> > Gesendet: Freitag, 16. September 2022 14:23 An: Andrew Lynch mailto:andrew.ly...@atos.net> >; 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?. 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 mailto:openssl-users-boun...@openssl.org> > On Behalf Of Andrew Lynch via openssl-users Sent: Friday, September 16, 2022 4:32 AM To: openssl-users@openssl.org <mailto: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
AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.
Hi Corey, I believe Victor has explained the issue sufficiently (thanks!). Just for completeness here are the actual root certificates relevant to the question. They are part of the German national Smart Metering environment: SM-Test-Root-CA SN1 (O=SM-Test-PKI) CN=SM-Test-Root.CA, SERIALNUMBER=1, gültig bis 19.05.2023 SHA256: 97 C2 68 C8 67 D7 6C 0E 13 4C B6 C9 AF F7 A9 E3 BD 9C 4E 30 E1 F6 CB F7 8E DE 4C 3F 11 A3 8D 4D https://www.telesec.de/assets/downloads/Smart-Metering-PKI/sm-test-root.ca_sn1.der SM-Test-Root-CA Link-Zertifikat (1>2) Download CN=SM-Test-Root.CA, SERIALNUMBER=2, gültig bis 19.05.2023 SHA256: ED 54 7F 5D F0 BC 41 D9 D7 3D 92 8B 75 FE 7D B9 9C D9 23 31 78 95 BD 26 BF D2 4A AF DE EF AE 10 https://www.telesec.de/assets/downloads/Smart-Metering-PKI/sm-test-root.ca_sn2_link.der SM-Test-Root-CA SN2 Download CN=SM-Test-Root.CA, SERIALNUMBER=2, gültig bis 19.10.2025 SHA256: 1D 77 21 17 16 69 66 41 AA B2 A3 61 5F E7 8E 76 73 C9 0E 16 E0 69 66 71 47 0F A4 6A 74 FC 18 36 https://www.telesec.de/assets/downloads/Smart-Metering-PKI/sm-test-root.ca_sn2.der (All from https://www.telesec.de/de/service/downloads/branchen-und-eco-systeme/. There is an English language downloads page but that does not show the Smart Metering PKI section.) Our intermediate CA that issued the end entity certificate is http://sm-pkitest.atos.net/cert/Atos-Smart-Grid-Test.CA.3.crt Fingerprint 14 f3 d2 f8 cd 00 ca 9d f6 41 ca 5b 10 55 9c d3 ac eb cc 5a The chain Atos-Smart-Grid-Test.CA.3.crt <- sm-test-root.ca_sn2.der is fine. It is a straightforward self-signed root plus intermediate setup. The chain Atos-Smart-Grid-Test.CA.3.crt <- sm-test-root.ca_sn2_link.der <- sm-test-root.ca_sn1.der is problematic because the “link” certificate has SN2 as subject but SN1 as issuer. So I believe it is effectively adding another intermediate layer which then violates pathlen:1 in sm-test-root.ca_sn1.der. My (naïve) understanding of such link or cross-certified CA certificates is that they are intended to help systems that only have SN1 as a trust anchor to verify certificates issued by SN2. But wouldn’t they stumble over pathlen too? My colleague doing the verifying initially had all three sm-test-root.ca certificates in his CAfile and OpenSSL 1.1.1 picked the path with the link certificate. Once he removed that everything was fine as the verify then used the self-signed SN2 root directly. Regards, Andrew. Von: Corey Bonnell Gesendet: Freitag, 16. September 2022 14:23 An: Andrew Lynch ; openssl-users@openssl.org Betreff: RE: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?. 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 mailto:openssl-users-boun...@openssl.org> > On Behalf Of Andrew Lynch via openssl-users Sent: Friday, September 16, 2022 4:32 AM To: openssl-users@openssl.org <mailto: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
Re: AW: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.
On Fri, Sep 16, 2022 at 08:32:27AM +, Andrew Lynch via openssl-users wrote: > So is this a possible bug or a feature of OpenSSL 1.1.1? (using > 1.1.1n right now) OpenSSL 1.1.1 is doing the right thing. > 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 There are two intermediate CA certificates (C and D) in this path. This path should be rejected when the path length constraint of A is set to 1. > If I create the first root certificate (A) with pathlen:2 instead of > pathlen:1 then validation succeeds As expected. > So it appears to me that OpenSSL 1.1.1n is definitely taking the > pathlen constraint of certificate A into account. As expected. While A's self-signed certificate is not counted in the path length, its path length constraint is honoured and applied to the rest of the non-EE (and not self-issued) CA certificates in the chain. On Fri, Sep 16, 2022 at 12:23:12PM +, Corey Bonnell via openssl-users wrote: > 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. There's no need. Everything is working as expected. -- Viktor.
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 Gesendet: Donnerstag, 15. September 2022 19:51 An: Andrew Lynch Cc: 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.
