pem_verify.sh fails on recent Mozilla root certificates (as of Apr 26 2022)
chazzmcdaniels opened this issue · comments
The pem_create.sh script downloads the most recent Mozilla root certificates from https://curl.se/ca/cacert.pem. As of Apr 26 2022 (or maybe before that) these certificates cause the pem_verify.sh to fail in X509Certificate::GetSubjectKeyUsage().
Load root certificates from Mozilla
Assertion failed: x509cert.cpp(1854): GetSubjectKeyUsage
./pem_verify.sh: line 30: 45335 Trace/breakpoint trap (core dumped) ./pem_test.exe
Failed to execute pem_test.exe
The CRYPTOPP_ASSERT(values.size() == 1) fails here as some of the certificates give a values.size() of 2 after BERDecodeBitString(store, values, unused).
Output of some custom debugging output:
serial number: 4151900041497450638097112925.
values.size(): 2, unused: 7
values[0]: 00000110
values[1]: 00000000
The CRYPTOPP_ASSERT(values.size() == 1) fails here as some of the certificates give a values.size() of 2 after BERDecodeBitString(store, values, unused).
It sounds like there's an invalid certificate in the bundle. (That assumes the code does not have a bug and the standard did not change).
Can you provide the certificate, please?
There are two certificates that make the assertion fail:
Trustwave Global ECC P256 Certification Authority
=================================================
-----BEGIN CERTIFICATE-----
MIICYDCCAgegAwIBAgIMDWpfCD8oXD5Rld9dMAoGCCqGSM49BAMCMIGRMQswCQYDVQQGEwJVUzER
MA8GA1UECBMISWxsaW5vaXMxEDAOBgNVBAcTB0NoaWNhZ28xITAfBgNVBAoTGFRydXN0d2F2ZSBI
b2xkaW5ncywgSW5jLjE6MDgGA1UEAxMxVHJ1c3R3YXZlIEdsb2JhbCBFQ0MgUDI1NiBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTAeFw0xNzA4MjMxOTM1MTBaFw00MjA4MjMxOTM1MTBaMIGRMQswCQYD
VQQGEwJVUzERMA8GA1UECBMISWxsaW5vaXMxEDAOBgNVBAcTB0NoaWNhZ28xITAfBgNVBAoTGFRy
dXN0d2F2ZSBIb2xkaW5ncywgSW5jLjE6MDgGA1UEAxMxVHJ1c3R3YXZlIEdsb2JhbCBFQ0MgUDI1
NiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABH77bOYj
43MyCMpg5lOcunSNGLB4kFKA3TjASh3RqMyTpJcGOMoNFWLGjgEqZZ2q3zSRLoHB5DOSMcT9CTqm
P62jQzBBMA8GA1UdEwEB/wQFMAMBAf8wDwYDVR0PAQH/BAUDAwcGADAdBgNVHQ4EFgQUo0EGrJBt
0UrrdaVKEJmzsaGLSvcwCgYIKoZIzj0EAwIDRwAwRAIgB+ZU2g6gWrKuEZ+Hxbb/ad4lvvigtwjz
RM4q3wghDDcCIC0mA6AFvWvR9lz4ZcyGbbOcNEhjhAnFjXca4syc4XR7
-----END CERTIFICATE-----
Trustwave Global ECC P384 Certification Authority
=================================================
-----BEGIN CERTIFICATE-----
MIICnTCCAiSgAwIBAgIMCL2Fl2yZJ6SAaEc7MAoGCCqGSM49BAMDMIGRMQswCQYDVQQGEwJVUzER
MA8GA1UECBMISWxsaW5vaXMxEDAOBgNVBAcTB0NoaWNhZ28xITAfBgNVBAoTGFRydXN0d2F2ZSBI
b2xkaW5ncywgSW5jLjE6MDgGA1UEAxMxVHJ1c3R3YXZlIEdsb2JhbCBFQ0MgUDM4NCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTAeFw0xNzA4MjMxOTM2NDNaFw00MjA4MjMxOTM2NDNaMIGRMQswCQYD
VQQGEwJVUzERMA8GA1UECBMISWxsaW5vaXMxEDAOBgNVBAcTB0NoaWNhZ28xITAfBgNVBAoTGFRy
dXN0d2F2ZSBIb2xkaW5ncywgSW5jLjE6MDgGA1UEAxMxVHJ1c3R3YXZlIEdsb2JhbCBFQ0MgUDM4
NCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTB2MBAGByqGSM49AgEGBSuBBAAiA2IABGvaDXU1CDFH
Ba5FmVXxERMuSvgQMSOjfoPTfygIOiYaOs+Xgh+AtycJj9GOMMQKmw6sWASr9zZ9lCOkmwqKi6vr
/TklZvFe/oyujUF5nQlgziip04pt89ZF1PKYhDhloKNDMEEwDwYDVR0TAQH/BAUwAwEB/zAPBgNV
HQ8BAf8EBQMDBwYAMB0GA1UdDgQWBBRVqYSJ0sEyvRjLbKYHTsjnnb6CkDAKBggqhkjOPQQDAwNn
ADBkAjA3AZKXRRJ+oPM+rRk6ct30UJMDEr5E0k9BpIycnR+j9sKS50gU/k6bpZFXrsY3crsCMGcl
CrEMXu6pY5Jv5ZAL/mYiykf9ijH3g/56vxC+GCsej/YpHpRZ744hN8tRmKVuSw==
-----END CERTIFICATE-----
Thanks @chazzmcdaniels,
That's perfect. It is a malformed certificate. I reported it to the cURL team.
To verify, I saved the first certificate to truestwave-1.pem. Then:
$ openssl x509 -in trustwave-1.pem -inform PEM -out trustwave-1.der -outform DER
$ dumpasn1 trustwave-1.der
0 608: SEQUENCE {
4 519: SEQUENCE {
8 3: [0] {
10 1: INTEGER 2
: }
13 12: INTEGER 0D 6A 5F 08 3F 28 5C 3E 51 95 DF 5D
27 10: SEQUENCE {
29 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
: }
39 145: SEQUENCE {
42 11: SET {
44 9: SEQUENCE {
46 3: OBJECT IDENTIFIER countryName (2 5 4 6)
51 2: PrintableString 'US'
: }
: }
55 17: SET {
57 15: SEQUENCE {
59 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
64 8: PrintableString 'Illinois'
: }
: }
74 16: SET {
76 14: SEQUENCE {
78 3: OBJECT IDENTIFIER localityName (2 5 4 7)
83 7: PrintableString 'Chicago'
: }
: }
92 33: SET {
94 31: SEQUENCE {
96 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
101 24: PrintableString 'Trustwave Holdings, Inc.'
: }
: }
127 58: SET {
129 56: SEQUENCE {
131 3: OBJECT IDENTIFIER commonName (2 5 4 3)
136 49: PrintableString
: 'Trustwave Global ECC P256 Certification Authorit'
: 'y'
: }
: }
: }
187 30: SEQUENCE {
189 13: UTCTime 23/08/2017 19:35:10 GMT
204 13: UTCTime 23/08/2042 19:35:10 GMT
: }
219 145: SEQUENCE {
222 11: SET {
224 9: SEQUENCE {
226 3: OBJECT IDENTIFIER countryName (2 5 4 6)
231 2: PrintableString 'US'
: }
: }
235 17: SET {
237 15: SEQUENCE {
239 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
244 8: PrintableString 'Illinois'
: }
: }
254 16: SET {
256 14: SEQUENCE {
258 3: OBJECT IDENTIFIER localityName (2 5 4 7)
263 7: PrintableString 'Chicago'
: }
: }
272 33: SET {
274 31: SEQUENCE {
276 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
281 24: PrintableString 'Trustwave Holdings, Inc.'
: }
: }
307 58: SET {
309 56: SEQUENCE {
311 3: OBJECT IDENTIFIER commonName (2 5 4 3)
316 49: PrintableString
: 'Trustwave Global ECC P256 Certification Authorit'
: 'y'
: }
: }
: }
367 89: SEQUENCE {
369 19: SEQUENCE {
371 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
380 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7)
: }
390 66: BIT STRING
: 04 7E FB 6C E6 23 E3 73 32 08 CA 60 E6 53 9C BA
: 74 8D 18 B0 78 90 52 80 DD 38 C0 4A 1D D1 A8 CC
: 93 A4 97 06 38 CA 0D 15 62 C6 8E 01 2A 65 9D AA
: DF 34 91 2E 81 C1 E4 33 92 31 C4 FD 09 3A A6 3F
: AD
: }
458 67: [3] {
460 65: SEQUENCE {
462 15: SEQUENCE {
464 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
469 1: BOOLEAN TRUE
472 5: OCTET STRING, encapsulates {
474 3: SEQUENCE {
476 1: BOOLEAN TRUE
: }
: }
: }
479 15: SEQUENCE {
481 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
486 1: BOOLEAN TRUE
489 5: OCTET STRING, encapsulates {
491 3: BIT STRING 7 unused bits
: '001100000'B
: Error: Spurious zero bits in bitstring.
: }
: }
496 29: SEQUENCE {
498 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
503 22: OCTET STRING, encapsulates {
505 20: OCTET STRING
: A3 41 06 AC 90 6D D1 4A EB 75 A5 4A 10 99 B3 B1
: A1 8B 4A F7
: }
: }
: }
: }
: }
527 10: SEQUENCE {
529 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
: }
539 71: BIT STRING, encapsulates {
542 68: SEQUENCE {
544 32: INTEGER
: 07 E6 54 DA 0E A0 5A B2 AE 11 9F 87 C5 B6 FF 69
: DE 25 BE F8 A0 B7 08 F3 44 CE 2A DF 08 21 0C 37
578 32: INTEGER
: 2D 26 03 A0 05 BD 6B D1 F6 5C F8 65 CC 86 6D B3
: 9C 34 48 63 84 09 C5 8D 77 1A E2 CC 9C E1 74 7B
: }
: }
: }
0 warnings, 1 error.
Thank you for the quick replies. I fed the certificates through several online PEM decoders and Java Keystore Explorer but none of them complained. I should have checked with OpenSSL as well. I hope you don't mind that I doubted the cryptopp-pem code. You would think that Mozilla would get the certificates right.
Thanks again.
No problems @chazzmcdaniels,
I reported it to curl-users mailing list (due to cacret.pem) and Mozilla's dev-security-policy mailing list (the source of cacert.pem).
Let's see where things go.
Thanks again @chazzmcdaniels,
It looks like you found a bug missed by most x509 linters. Good job.
Also see Malformed Trustwave certificates in Mozilla's ca cert collection on Mozilla's dev-security-policy mailing list.
This should be fixed at Commit aac70de16f29. The certificates will still assert in Debug builds, but the certificates will be handled properly in all builds.