cryptography 🚀 - Some leaf certificates have path_length = 0 and CA = false

Just out of curiosity, are these publicly trusted CAs, or private ones?

alex on 10 Aug 2017

@alex those were issued by Wosign. Here is an example.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 8335778418196226 (0x1d9d58a78aff02)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CN, O=WoSign eCommerce Services Limited, CN=WoSign Class 3 Code Signing CA
        Validity
            Not Before: Apr  9 06:39:19 2013 GMT
            Not After : Apr 11 16:01:08 2016 GMT
        Subject: C=CN, ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81, L=\xE5\xB9\xBF\xE5\xB7\x9E\xE5\xB8\x82, O=\xE5\xB9\xBF\xE5\xB7\x9E\xE6\xB5\xB7\xE7\x84\xB6\xE6\x95\xB0\xE7\xA0\x81\xE7\xA7\x91\xE6\x8A\x80\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8, CN=\xE5\xB9\xBF\xE5\xB7\x9E\xE6\xB5\xB7\xE7\x84\xB6\xE6\x95\xB0\xE7\xA0\x81\xE7\xA7\x91\xE6\x8A\x80\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a1:d7:66:0c:82:d7:35:7a:e3:b7:b3:36:10:15:
                    10:d2:84:98:4e:5e:fa:bd:93:0d:9f:9f:e3:d9:22:
                    d0:a1:e6:2f:77:75:a0:12:5e:4a:41:d7:b7:a7:fe:
                    c1:78:78:e4:8b:84:ad:3c:64:54:6a:ad:e1:c8:72:
                    f9:ac:8c:d3:43:fb:23:a5:6a:c4:5d:d8:72:c1:ab:
                    57:65:f9:75:0c:f8:67:fb:f1:40:6c:d2:9c:cf:04:
                    86:43:54:b7:42:03:12:8f:5e:3b:d6:d9:f6:f7:4c:
                    62:53:76:e9:54:89:a6:c9:65:ed:ad:0c:41:46:13:
                    1b:df:a4:dc:6d:05:6e:1a:c0:ea:45:4a:e1:21:ce:
                    a5:96:a8:3d:f8:c3:6b:39:de:90:93:d2:d9:64:ce:
                    9e:4d:0e:92:f5:3c:2e:57:c4:70:f0:82:61:6f:62:
                    c9:7e:f2:ca:60:06:9e:d7:05:37:ab:22:ce:78:60:
                    ba:e3:98:c8:b5:e2:3a:24:99:4c:4d:ab:56:65:1c:
                    04:18:21:e6:97:9a:09:e7:4e:b7:b5:2b:a6:b9:2f:
                    0c:5d:15:e0:91:72:ee:97:68:ea:d3:d9:d4:bf:31:
                    33:98:74:ad:67:56:70:c9:b1:b2:0d:02:dd:85:ae:
                    2b:b8:cb:0e:6e:97:b9:fc:fb:2d:f5:02:f5:b9:57:
                    d4:4f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                Code Signing, Microsoft Commercial Code Signing
            X509v3 Subject Key Identifier:
                3B:8F:41:95:33:1B:4A:32:E1:BD:81:C2:49:DC:73:60:DF:50:67:64
            X509v3 Authority Key Identifier:
                keyid:F5:02:AA:4B:D3:E0:1A:8E:77:50:D6:1A:BB:EB:DF:B9:83:70:B0:4E

            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.36305.1.3.3.1.2
                  CPS: http://www.wosign.com/policy/
                  User Notice:
                    Organization: WoSign eCommerce Services Limited
                    Number: 1
                    Explicit Text: Limited Liability, see the WoSign Certification Authority Policy at http://www.wosign.com/policy/

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.wosign.com/code-3.crl

            Authority Information Access:
                OCSP - URI:http://ocsp.wosign.com/class3/code/ca
                CA Issuers - URI:http://aia.wosign.com/class3.code.ca.cer

            X509v3 Issuer Alternative Name:
                URI:http://www.wosign.com/
    Signature Algorithm: sha1WithRSAEncryption
         b6:3d:22:e0:72:ff:27:86:59:21:b9:1c:0b:c5:f1:f9:1a:9b:
         52:ab:71:6b:4e:19:01:e8:d1:a8:15:b5:cc:28:21:ff:59:33:
         27:a7:69:5b:ad:31:be:63:4c:87:b0:b8:10:92:be:97:54:9c:
         82:76:3e:3f:10:b0:08:98:52:d7:d6:83:f9:0e:a4:b4:c3:bc:
         28:20:32:ec:3f:80:30:ad:d5:c1:f4:e4:3f:b9:43:64:cf:5e:
         31:02:14:26:30:7e:04:cd:b9:80:32:0c:7a:f2:19:97:72:41:
         ae:37:f5:56:10:11:58:bf:97:61:6e:f4:53:f9:12:62:11:e2:
         31:fc:5b:97:67:4a:a7:22:4b:3c:33:3f:3c:f8:28:71:fe:e5:
         3e:b6:4b:9c:f2:29:29:cb:85:26:4c:c0:f9:ab:67:94:b4:fb:
         fe:4d:ea:ca:6d:21:72:be:37:7d:d8:70:9f:23:b3:31:a6:23:
         de:18:48:e2:52:52:b2:c2:27:ef:96:4b:b7:c6:33:23:d6:c8:
         82:6e:20:fc:11:ba:b6:7d:7e:18:3f:46:bb:ae:d0:b3:5b:03:
         d0:72:f9:f8:d4:75:01:23:50:f1:38:59:fd:bf:5b:f4:5a:3a:
         25:92:66:06:cc:61:c6:ac:45:6f:87:a5:c3:b4:96:8f:ed:bc:
         9a:f1:c1:58
-----BEGIN CERTIFICATE-----
MIIF3jCCBMagAwIBAgIHHZ1Yp4r/AjANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQG
EwJDTjEqMCgGA1UEChMhV29TaWduIGVDb21tZXJjZSBTZXJ2aWNlcyBMaW1pdGVk
MScwJQYDVQQDEx5Xb1NpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgQ0EwHhcNMTMw
NDA5MDYzOTE5WhcNMTYwNDExMTYwMTA4WjCBtzELMAkGA1UEBhMCQ04xEjAQBgNV
BAgMCeW5v+S4nOecgTESMBAGA1UEBwwJ5bm/5bee5biCMS0wKwYDVQQKDCTlub/l
t57mtbfnhLbmlbDnoIHnp5HmioDmnInpmZDlhazlj7gxLTArBgNVBAMMJOW5v+W3
nua1t+eEtuaVsOeggeenkeaKgOaciemZkOWFrOWPuDEiMCAGCSqGSIb3DQEJARYT
amFuZ29nb2NoYW5AbXNuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKHXZgyC1zV647ezNhAVENKEmE5e+r2TDZ+f49ki0KHmL3d1oBJeSkHXt6f+
wXh45IuErTxkVGqt4chy+ayM00P7I6VqxF3YcsGrV2X5dQz4Z/vxQGzSnM8EhkNU
t0IDEo9eO9bZ9vdMYlN26VSJpsll7a0MQUYTG9+k3G0FbhrA6kVK4SHOpZaoPfjD
aznekJPS2WTOnk0OkvU8LlfEcPCCYW9iyX7yymAGntcFN6siznhguuOYyLXiOiSZ
TE2rVmUcBBgh5peaCedOt7UrprkvDF0V4JFy7pdo6tPZ1L8xM5h0rWdWcMmxsg0C
3YWuK7jLDm6Xufz7LfUC9blX1E8CAwEAAaOCAkEwggI9MA8GA1UdEwEB/wQFMAMC
AQAwDgYDVR0PAQH/BAQDAgeAMB8GA1UdJQQYMBYGCCsGAQUFBwMDBgorBgEEAYI3
AgEWMB0GA1UdDgQWBBQ7j0GVMxtKMuG9gcJJ3HNg31BnZDAfBgNVHSMEGDAWgBT1
AqpL0+AajndQ1hq769+5g3CwTjCB6AYDVR0gBIHgMIHdMIHaBg0rBgEEAYKbUQED
AwECMIHIMCkGCCsGAQUFBwIBFh1odHRwOi8vd3d3Lndvc2lnbi5jb20vcG9saWN5
LzCBmgYIKwYBBQUHAgIwgY0wKBYhV29TaWduIGVDb21tZXJjZSBTZXJ2aWNlcyBM
aW1pdGVkMAMCAQEaYUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgdGhlIFdvU2lnbiBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXQgaHR0cDovL3d3dy53b3Np
Z24uY29tL3BvbGljeS8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybHMud29z
aWduLmNvbS9jb2RlLTMuY3JsMHcGCCsGAQUFBwEBBGswaTAxBggrBgEFBQcwAYYl
aHR0cDovL29jc3Aud29zaWduLmNvbS9jbGFzczMvY29kZS9jYTA0BggrBgEFBQcw
AoYoaHR0cDovL2FpYS53b3NpZ24uY29tL2NsYXNzMy5jb2RlLmNhLmNlcjAhBgNV
HRIEGjAYhhZodHRwOi8vd3d3Lndvc2lnbi5jb20vMA0GCSqGSIb3DQEBBQUAA4IB
AQC2PSLgcv8nhlkhuRwLxfH5GptSq3FrThkB6NGoFbXMKCH/WTMnp2lbrTG+Y0yH
sLgQkr6XVJyCdj4/ELAImFLX1oP5DqS0w7woIDLsP4AwrdXB9OQ/uUNkz14xAhQm
MH4EzbmAMgx68hmXckGuN/VWEBFYv5dhbvRT+RJiEeIx/FuXZ0qnIks8Mz88+Chx
/uU+tkuc8ikpy4UmTMD5q2eUtPv+TerKbSFyvjd92HCfI7MxpiPeGEjiUlKywifv
lku3xjMj1siCbiD8Ebq2fX4YP0a7rtCzWwPQcvn41HUBI1DxOFn9v1v0WjolkmYG
zGHGrEVvh6XDtJaP7bya8cFY
-----END CERTIFICATE-----

doowon on 10 Aug 2017

Currently we use the same classes in parsing as we do in generating new certificates (including using their __init__ methods, which enforce certain sanity restrictions). However, this is problematic in cases where an actual certificate violates the constraints we set on generation. RFC 5280 doesn't actually prohibit this behavior, it just says that pathLen is meaningless unless CA is true and the keyCertSign bit is set in keyUsage.

We should probably consider how to fix this scenario (representable by our objects but prohibited by sanity checks that are meant for certificate construction) for all our extensions. To kickstart the conversation: we could add an undocumented boolean kwarg _novalidate that would bypass checks and pass True when parsing all certificates.

reaperhulk on 10 Aug 2017

RFC 5280 does prohibit it:

CAs MUST NOT include the pathLenConstraint field unless the cA
boolean is asserted and the key usage extension asserts the
keyCertSign bit.

On Wed, Aug 9, 2017 at 7:21 PM, Paul Kehrer notifications@github.com
wrote:

Currently we use the same classes in parsing as we do in generating new
certificates (including using their __init__ methods, which enforce
certain sanity restrictions). However, this is problematic in cases where
an actual certificate violates the constraints we set on generation. RFC
5280 doesn't actually prohibit this behavior, it just says that pathLen
is meaningless unless CA is true and the keyCertSign bit is set in keyUsage.

We should probably consider how to fix this scenario (representable by our
objects but prohibited by sanity checks that are meant for certificate
construction) for all our extensions. To kickstart the conversation: we
could add an undocumented boolean kwarg _novalidate that would bypass
checks and pass True when parsing all certificates.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pyca/cryptography/issues/3856#issuecomment-321407881,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAADBMNEBKYc5weg3yKKvVlU0eVk89DPks5sWj8KgaJpZM4Oyu-9
.

--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

alex on 10 Aug 2017

Oops, didn't scroll far enough! I saw

The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).

and didn't notice the end of the section.

reaperhulk on 10 Aug 2017

Oh lovely, yet another Wosign FUBAR?

tiran on 10 Aug 2017

Hanno pointed out that the cert is only valid for code signing, https://twitter.com/hanno/status/895606507902914560 . RFC 5280 is about PKI in general and also applies to code signing. I asked @zooba for his opinion.

tiran on 10 Aug 2017

FWIW, because of this I went and searched for some publicly trusted TLS certs that this affected. I found 5and reported them, see mdsp for details.

alex on 10 Aug 2017

As I posted on Twitter, WoSign is having their trusted root CA status revoked in Windows 10. No idea whether problematic certificates like this are the reason (the blog post mentions "multiple CAB Forum Baseline Requirements violations" but I'm not 100% sure what those are), but it could be part of it.

My general opinion on this kind of thing is to loosely validate on usage (e.g. treat "path_length = None" and "path_length = 0" as the same, since the intent is fairly obvious) and have a "strict" mode for those who are deliberately doing QA. Otherwise you end up punishing users for a mistake they don't have the power to fix.

zooba on 10 Aug 2017

WoSign had a massive pattern of misissuance far in excess of these mistakes, but these are a small part of it.

I'm going to put up a PR for discussion that disables our sanity checks when parsing certificates ~soon.

reaperhulk on 10 Aug 2017

This is actually affecting my company. We have certs that are issued from an internal CA, nothing's otherwise weird about them but they are giving us this ValueError. It's impacting the datadog agent, making it impossible for us to run some of our monitoring. This wasn't an issue for years, it seems a requests upgrade cause a cryptography upgrade and introduced this bug.

openssl, and by proxy,curl, do not have an issue with these certs. From my perspective it's cryptography causing the issue. I see that this has been open for almost a year and a half now so I don't expect much but in case anyone is still subbed to this, please know that it is still a problem.

2rs2ts on 12 Jan 2019

👎2 👍1

We definitely still care. Datadog is parsing these certs? I don’t think we were aware of that consumer.

On Jan 11, 2019, at 4:24 PM, Andrew Garrett notifications@github.com wrote:

This is actually affecting my company. We have certs that are issued from an internal CA, nothing's otherwise weird about them but they are giving us this ValueError. It's impacting the datadog agent, making it impossible for us to run some of our monitoring. This wasn't an issue for years, it seems a requests upgrade cause a cryptography upgrade and introduced this bug.

openssl, and by proxy,curl, do not have an issue with these certs. From my perspective it's cryptography causing the issue. I see that this has been open for almost a year and a half now so I don't expect much but in case anyone is still subbed to this, please know that it is still a problem.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

reaperhulk on 12 Jan 2019

Hi
I am in the same situation as the previous commenter :

We have some CA certificates that raise this ValueError with python/requests, but the same certificates don't raise any error with any other tools we use (curl, browsers, java, ...).

I have no other solution but disabling SSL verification, which is far from ideal.

Any chance to have at least a flag to disable this check only... it would be cleaner that disabling the whole SSL check.

Thanks

jpays on 16 Jan 2019

@reaperhulk they are using the requests library so really it's the requests library that's your consumer. Which is a pretty big one.

We did find a way to reissue the certs to remove the pathlen constraint so we personally are good now but I think that if openssl is fine with these certs then cryptography should at least have a compatibility mode with them.

2rs2ts on 17 Jan 2019

@2rs2ts yeah the message from jpays made it clear requests was doing parsing in this vein. @alex and I spent quite a bit of time talking about this yesterday and we have some ideas on ways forward. Hopefully we can get something merged and released soon.

reaperhulk on 17 Jan 2019

🎉1

This problem affects me unfortunately in annoying regularity. Is it foreseeable when this will be solved?

weddige on 25 May 2020

@doowon :

I have seen some leaf (end entity) code signing certificates have path length = 0 even though the CA is False

… those were issued by Wosign. Here is an example.

Moreover, in fact, this certificate contains only pathlen:0 (i.e. without CA:FALSE). This can be seen by looking at the certificate data structure:

Copy the certificate (PEM) to Online ASN.1 Dumper
> > -----BEGIN CERTIFICATE----- > MIIF3jCCBMagAwIBAgIHHZ1Yp4r/AjANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQG > EwJDTjEqMCgGA1UEChMhV29TaWduIGVDb21tZXJjZSBTZXJ2aWNlcyBMaW1pdGVk > MScwJQYDVQQDEx5Xb1NpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgQ0EwHhcNMTMw > NDA5MDYzOTE5WhcNMTYwNDExMTYwMTA4WjCBtzELMAkGA1UEBhMCQ04xEjAQBgNV > BAgMCeW5v+S4nOecgTESMBAGA1UEBwwJ5bm/5bee5biCMS0wKwYDVQQKDCTlub/l > t57mtbfnhLbmlbDnoIHnp5HmioDmnInpmZDlhazlj7gxLTArBgNVBAMMJOW5v+W3 > nua1t+eEtuaVsOeggeenkeaKgOaciemZkOWFrOWPuDEiMCAGCSqGSIb3DQEJARYT > amFuZ29nb2NoYW5AbXNuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC > ggEBAKHXZgyC1zV647ezNhAVENKEmE5e+r2TDZ+f49ki0KHmL3d1oBJeSkHXt6f+ > wXh45IuErTxkVGqt4chy+ayM00P7I6VqxF3YcsGrV2X5dQz4Z/vxQGzSnM8EhkNU > t0IDEo9eO9bZ9vdMYlN26VSJpsll7a0MQUYTG9+k3G0FbhrA6kVK4SHOpZaoPfjD > aznekJPS2WTOnk0OkvU8LlfEcPCCYW9iyX7yymAGntcFN6siznhguuOYyLXiOiSZ > TE2rVmUcBBgh5peaCedOt7UrprkvDF0V4JFy7pdo6tPZ1L8xM5h0rWdWcMmxsg0C > 3YWuK7jLDm6Xufz7LfUC9blX1E8CAwEAAaOCAkEwggI9MA8GA1UdEwEB/wQFMAMC > AQAwDgYDVR0PAQH/BAQDAgeAMB8GA1UdJQQYMBYGCCsGAQUFBwMDBgorBgEEAYI3 > AgEWMB0GA1UdDgQWBBQ7j0GVMxtKMuG9gcJJ3HNg31BnZDAfBgNVHSMEGDAWgBT1 > AqpL0+AajndQ1hq769+5g3CwTjCB6AYDVR0gBIHgMIHdMIHaBg0rBgEEAYKbUQED > AwECMIHIMCkGCCsGAQUFBwIBFh1odHRwOi8vd3d3Lndvc2lnbi5jb20vcG9saWN5 > LzCBmgYIKwYBBQUHAgIwgY0wKBYhV29TaWduIGVDb21tZXJjZSBTZXJ2aWNlcyBM > aW1pdGVkMAMCAQEaYUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgdGhlIFdvU2lnbiBD > ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXQgaHR0cDovL3d3dy53b3Np > Z24uY29tL3BvbGljeS8wMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybHMud29z > aWduLmNvbS9jb2RlLTMuY3JsMHcGCCsGAQUFBwEBBGswaTAxBggrBgEFBQcwAYYl > aHR0cDovL29jc3Aud29zaWduLmNvbS9jbGFzczMvY29kZS9jYTA0BggrBgEFBQcw > AoYoaHR0cDovL2FpYS53b3NpZ24uY29tL2NsYXNzMy5jb2RlLmNhLmNlcjAhBgNV > HRIEGjAYhhZodHRwOi8vd3d3Lndvc2lnbi5jb20vMA0GCSqGSIb3DQEBBQUAA4IB > AQC2PSLgcv8nhlkhuRwLxfH5GptSq3FrThkB6NGoFbXMKCH/WTMnp2lbrTG+Y0yH > sLgQkr6XVJyCdj4/ELAImFLX1oP5DqS0w7woIDLsP4AwrdXB9OQ/uUNkz14xAhQm > MH4EzbmAMgx68hmXckGuN/VWEBFYv5dhbvRT+RJiEeIx/FuXZ0qnIks8Mz88+Chx > /uU+tkuc8ikpy4UmTMD5q2eUtPv+TerKbSFyvjd92HCfI7MxpiPeGEjiUlKywifv > lku3xjMj1siCbiD8Ebq2fX4YP0a7rtCzWwPQcvn41HUBI1DxOFn9v1v0WjolkmYG > zGHGrEVvh6XDtJaP7bya8cFY > -----END CERTIFICATE----- >

Get as a result:

...

       SEQUENCE

         ObjectIdentifier basicConstraints (2 5 29 19)

         BOOLEAN TRUE

         OCTETSTRING, encapsulates

           SEQUENCE

             INTEGER 00

...

But the BasicConstraints in a correct certificate _MUST_ look like:

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }

Note: openssl omits CA:FALSE because FALSE is the DEFAULT value for cA.

As @alex mentioned:

CAs _MUST_ NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit.

Result: if BasicConstraints SEQUENCE length == 1 then parsers expect the type of SEQUENCE first element to be BOOLEAN and will fail when it is INTEGER :flushed:

i-to-r on 30 May 2020

@2rs2ts, @jpays, @weddige
Perhaps you are using certificates generated by openssl.
openssl can generate any certificates, including invalid (https://github.com/openssl/openssl/issues/11819#issuecomment-631474930 ; nonstandard).

@diabonas described the situation best in https://github.com/openssl/openssl/issues/11456#issuecomment-607460998 :

This is not a downstream packaging issue, commit openssl/openssl@ba4356ae4002a04e28642da60c551877eea804f7 changed the validation result for self-signed certificates with invalid certificate extensions. To reproduce, generate a self-signed certificate with inconsistent extensions (with any OpenSSL version) using
openssl genrsa -out private.pem 4096

openssl req -new -key private.pem -out csr.pem

openssl x509 -req -signkey private.pem -in csr.pem -out cert.pem \
             -extfile <(echo "basicConstraints=CA:FALSE,pathlen:0")
Now try verifying the generated certificate cert.pem using
openssl verify -CAfile cert.pem cert.pem
In OpenSSL 1.1.1e, this yields
cert.pem: OK
while OpenSSL 1.1.1f gives
C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
error 20 at 0 depth lookup: unable to get local issuer certificate
error cert.pem: verification failed
I suspect your VPN provider's certificate has inconsistent extensions (and is therefore broken and should not be used), but previous OpenSSL versions didn't report this because it is a self-signed certificate.

That is, the problem with the certificates you use - they will have to be reissued with the correct parameters.

PS The standard is written in such a way to make it possible to create fast and simple parsers. If you generate/accept certificates that do not meet the standard, then only slower and complex parsers will survive.

i-to-r on 30 May 2020

That is, the problem with the certificates you use - they will have to be reissued with the correct parameters.

PS The standard is written in such a way to make it possible to create fast and simple parsers. If you generate/accept certificates that do not meet the standard, then only slower and complex parsers will survive.

I think nobody here questions that the certificates are invalid. However, these certificates do occur in the wild and cause problems. And I don't have any control over the certificates I have to work with and in the end, I need a library, that can handle them.

I really would appreciate a solution for this. Especially as it does not affect the efficiency of the parser in any way. The constraint to not allow CA:FALSE and pathlen:0 does not affect the implementation level in any way. I could understand this concern regarding #3857 (that I also encountered). But even there I would tend to support it, if it doesn't break anything else.

weddige on 30 May 2020

However, these certificates do occur in the wild and cause problems.

Now many tools will inherit the new behavior of openssl. ~So, it will only get worse.~

_offtopic_:
IMHO the best way (for openssl) is to add the check (pseudocode):

if (  (cert.tbsCertificate.validity.notBefore + time_to_deploy_new_openssl > OpenSSL_v1_1_1f_release_date)
      OR STRICT_MODE
   ) AND cert.hasInconsistentExtensions() then ERR_INVALID_EXTENSION
else OK

The constraint to not allow CA:FALSE and pathlen:0 does not affect the implementation level in any way.
... if it doesn't break anything else.

Unfortunately... (I highlighted the _fall place_ in the code):

Qt v5.13 (from v5.6 to latest commits) (description in my previous comment)
jsrsasign (RSA-Sign JavaScript Library)
other RFC 5280 based tools/libs ...

This is a more global problem, which (ideally) requires an addition (update or new Best Current Practice) to the RFC - what to do in such case. Currently, RFC 5280 says to ~feel the pain~ reject:

A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a _critical extension that contains information that it cannot process_. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.

UPD (from ASN.1 Notes):

If an extension containing _unexpected values_ is marked as critical, the implementation MUST reject the certificate or CRL containing the unrecognized extension.

And unfortunately, in all such certs, basicConstraints is critical:

...
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE, pathlen:0
...

...
       SEQUENCE
         ObjectIdentifier basicConstraints (2 5 29 19)
         BOOLEAN TRUE
         OCTETSTRING, encapsulates
           SEQUENCE
             INTEGER 00
...

i-to-r on 30 May 2020

The constraint to not allow CA:FALSE and pathlen:0 does not affect the implementation level in any way.
... if it doesn't break anything else.

Unfortunately... (I highlighted the _fall place_ in the code):

Qt v5.13 (from v5.6 to latest commits) (description in my previous comment)

jsrsasign (RSA-Sign JavaScript Library)

other RFC 5280 based tools/libs ...

As we are discussing this topic in a cryptography issue, I'm only concerned about cryptography. And I didn't mean that there are no implementations, that can't handle it (cryptography cant handle it for example). What I meant with "[it] does not affect the implementation level" is, that in the case CA:FALSE, there is no need to access pathlen at all. Therefore after the validation step, there should be no need to write any special handling for the case.

Still, it has to be a conscious decision of the library to do so. But I don't see any reason not to support it.

This is a more global problem, which (ideally) requires an addition (update) to the RFC - what to do in such case. Currently, RFC 5280 says to ~feel the pain~ reject:

A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a _critical extension that contains information that it cannot process_. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.

IMHO this passage doesn't apply here. Because cryptography does recognize the extension and as there is no ambiguity how to handle it, it clearly knows how to handle it.

The RFC conform case would be, that the path length has to be undefined if CA:FALSE, because it is not processed in any way after that. Setting path length to any other value, doesn't raise the question how to process it.

weddige on 30 May 2020

👎1

What I meant with "[it] does not affect the implementation level" is, that in the case CA:FALSE, there is no need to access pathlen at all.

as there is no ambiguity how to handle it, it clearly knows how to handle it.

I understood. You consider basicConstraints=critical,CA:FALSE,pathlen:0 (or basicConstraints=critical,pathlen:0) only as the first scenario:

A certificate creator wanted to generate an _end entity certificate_ (CA:FALSE) and made a mistake during configuration (misunderstood a HOWTO/Tutorial, or copied from an incorrect HOWTO/Tutorial).
A certificate creator wanted to generate a _CA certificate_ with pathlen:0 (only end entity certificates are allowed to sign, not CA certificates) and made a configuration error.

These are quite common cases — if someone has not read the RFC before generating the certificate (moreover, some find it hard to understand the man pages). Or when editing an existing old configuration. The result is basicConstraints=critical,pathlen:0 for the CA certificate (for example).

At the same time, this does not directly apply to code signing (the author of issue was interested in the code signing purpose and end entity certificates), and basicConstraints (and its fields) is directly mentioned only in Revocation Inputs and a few more places. _So yes, for the code signing purposes, implementations can try to ignore it in the first case_:

[ignoring possible] certification path:
CA/CA/…/CA/<inconsistent BasicConstraints extension>{code signing}
[???] certification path:
CA/CA/…/<inconsistent BasicConstraints extension>/end-entity{code signing}

What I meant with "[it] does not affect the implementation level" is, that in the case CA:FALSE, there is no need to access pathlen at all. Therefore after the validation step, there should be no need to write any special handling for the case. … But I don't see any reason not to support it.

The main reason is to prevent the further distribution of such certificates (with configuration errors) as soon as possible after issue (generation).
UPD: It is possible to say that limiting all possible options (combinations*, permutations*) of parameters and their values to logically consistent ones works as a error-signalling trigger in mapping _the certificate creator wants/meaning_ to _the format described in the standard_.

And I didn't mean that there are no implementations, that can't handle it (cryptography cant handle it for example)

Typo? Did you mean "can"?

i-to-r on 31 May 2020

Regarding your thoughts on what the intention of the issuer was: If the issuer didn't set CA:TRUE, it's not a CA. There is no possible justification for an implicit assumption based on pathlen.

The main reason is to prevent the further distribution of such certificates (with configuration errors) as soon as possible after issue (generation).

But these certificates exist and are being distributed and browsers are supporting it. I agree, that certificates like this shouldn't be issued. But not being able to read them doesn't make anything better.

My use case for example is analyzing server configurations with https://github.com/nabla-c0d3/sslyze. I'm not the issuer and the issuer doesn't care as long as I can't point out a security issue. So I have more work to do by hand, because cryptography can't load the certificate.

And I didn't mean that there are no implementations, that can't handle it (cryptography cant handle it for example)

Typo? Did you mean "can"?

No, I meant can't, because this is what this issue is about. Currently it's not possible to read certificates with this configuration, as cryptography raises a validation error.

weddige on 31 May 2020

Cryptography: Some leaf certificates have path_length = 0 and CA = false

All 23 comments

Related issues