Closed Bug 991823 Opened 10 years ago Closed 10 years ago

(mozilla::pkix) site not getting sec_error_unknown_issuer error when mozilla::pkix on, but get the error when mozilla::pkix is off

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
31 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: kathleen.a.wilson, Assigned: cviecco)

References

Details

Attachments

(2 files)

Screen Shot 2014-04-14 at 4.14.43 PM.png
80.80 KB, image/png
Details
ssltest24
4.28 KB, patch
Details | Diff | Splinter Review 
New profile, but using same profile for both.

Removing cert8.db before starting each time.

Get sec_error_unknown_issuer when mozilla::pkix off (FF29), but don’t get error when mozilla::pkix is on (FF31.0a1, 4/3/2014)

https://ssltest24.bbtest.net/
Chrome 33 and MSIE 11 on Windows both accept the certificate.

Marking "UNCONFIRMED" because this bug may be "mozilla::pkix builds paths better than we did before" which, if true, would mean we should make this RESOLVED INVALID. However, we should confirm why we reject the certificate with NSS classic. We should also find out if libpkix accepts or rejects the cert.
Blocks: mozilla::pkix
Status: NEW → UNCONFIRMED
Ever confirmed: false
OS: Mac OS X → All
Hardware: x86 → All
In case it helps... The intermediate and root certs are 1024-bits.
Chrome 34 does not accept the certificate. Their error is "nonconforming certificate: invalid extension"
(In reply to Monica Chew [:mmc] (please use needinfo) from comment #3)
> Created attachment 8406488 [details]
> Screen Shot 2014-04-14 at 4.14.43 PM.png
> 
> Chrome 34 does not accept the certificate. Their error is "nonconforming
> certificate: invalid extension"

Chrome 34 and MSIE11 on Windows both accept the certificate. Your screenshot shows Chrome 34 on Mac OS X does not accept the certificate. Note that Chrome uses the OS-supplied cert verification library so it isn't totally surprising that the Chrome behavior differs between platforms. CC'd rsleevi in case he's curious about the difference.
Here is the openssl output. I'm trying to find something equivalent using mozpkix and failing. David had suggested using add_connection_test but it seems that that relies on a static cert DB built by a test server.

mchew@mchew-12604:~/mozilla-central$ openssl s_client -connect ssltest24.bbtest.net:443 -showcerts
CONNECTED(00000003)
depth=0 C = US, ST = California, L = Mountain View, O = Symantec Corporation, OU = FOR TESTING - DEMO PURPOSES ONLY, CN = ssltest24.bbtest.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Symantec Corporation, OU = FOR TESTING - DEMO PURPOSES ONLY, CN = ssltest24.bbtest.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Symantec Corporation, OU = FOR TESTING - DEMO PURPOSES ONLY, CN = ssltest24.bbtest.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Symantec Corporation/OU=FOR TESTING - DEMO PURPOSES ONLY/CN=ssltest24.bbtest.net
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
-----BEGIN CERTIFICATE-----
MIIFiTCCBHGgAwIBAgIQMWa9MZaCxx845vMLWiL3pDANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwHhcNMTMxMjMx
MDAwMDAwWhcNMTQxMjMxMjM1OTU5WjCBozELMAkGA1UEBhMCVVMxEzARBgNVBAgM
CkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxHTAbBgNVBAoMFFN5
bWFudGVjIENvcnBvcmF0aW9uMSkwJwYDVQQLDCBGT1IgVEVTVElORyAtIERFTU8g
UFVSUE9TRVMgT05MWTEdMBsGA1UEAwwUc3NsdGVzdDI0LmJidGVzdC5uZXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrIbcRwwaXNte3+PY1U9ayKb5y
WlLuAjNPaDQ7sEi9SnBZmyFoZqNcJ8ydH6jM2FhhIbQ7Zv0O+J69vQxaD65zrhzf
KBRPes3qmyhsoxb4g+2LvAth9N0fomDRrpAkCN+lHY8KdxT1XaFQcNpQmkQX8xbh
xTrLaxRa61jEQXiXGa5zr0b3wVnxa8qdN6wp619j7ATCDExA9IOzo+6AYQnw30Qz
fOcSLzdLLdraUA5jkHwmsUljsWUlls/a/CYe8zecx79fElb7dmfZEbrAKkx/M9yI
Mm8NKB4+dtKI8C9YM+wO761S+T/J+puVcPGxqJ70tb+nBgZQuE5Jr1gc3b8JAgMB
AAGjggGjMIIBnzAJBgNVHRMEAjAAMEMGA1UdIAQ8MDowOAYKYIZIAYb4RQEHNjAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMEUGA1Ud
HwQ+MDwwOqA4oDaGNGh0dHA6Ly9TVlJTZWN1cmUtRzItY3JsLnZlcmlzaWduLmNv
bS9TVlJTZWN1cmVHMi5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MA4GA1UdDwEB/wQEAwIFoDAdBgNVHQ4EFgQU1FB5qKh45Gn2Vkvy8mK5eb351NUw
dgYIKwYBBQUHAQEEajBoMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2ln
bi5jb20wQAYIKwYBBQUHMAKGNGh0dHA6Ly9TVlJTZWN1cmUtRzItYWlhLnZlcmlz
aWduLmNvbS9TVlJTZWN1cmVHMi5jZXIwHwYDVR0RBBgwFoIUc3NsdGVzdDI0LmJi
dGVzdC5uZXQwHwYDVR0jBBgwFoAUehD8PY30NL8VY7iiPXxapNLjSiQwDQYJKoZI
hvcNAQEFBQADggEBAAhO03A5732J5SfNAzx0X0voboUemZtGM4t7YE7knWaqkUwt
PBSRbBlJExFr3V1nsocNSwtD3SOFByxYXWUjVtiHSNoYaCau0FsXKrDRYlBjPPyJ
aEVOrWwNsa820tJGu6O2sMWFeDuCRyjeSn1ORV/b8YgucAfR3yyBe1VFSZJ/Ny5R
GchAR1s8z9EfY8ni7c6aKi/wcY+jx4xFZVZUO9fmayimTLgp6XHb0fCZRmo47/vT
utT/YeR0dUZ2cHlaibqKAy7VQHTo5Z01tFt/gmpzVxXFfRLwJsjkkRy39OXAiTDg
RCn04Alrc0eUbE6LSCsI5qY8/MonPXfTRjKAQQ4=
-----END CERTIFICATE-----
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
-----BEGIN CERTIFICATE-----
MIIGLDCCBZWgAwIBAgIQbk/6s8XmacTRZ8mSq+hYxDANBgkqhkiG9w0BAQUFADCB
wTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQL
EzNDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1
dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmswHhcNMDkwMzI1MDAwMDAwWhcNMTkwMzI0MjM1OTU5WjCBtTELMAkGA1UEBhMC
VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMmVmVyaVNpZ24gQ2xh
c3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDUVo9XOzcopkBj0pXVBXTatRlqltZxVy/iwDSMoJWzjOE3JPMu
7UNFBY6J1/raSrX4Po1Ox/lJUEU3QJ90qqBRVWHxYISJpZ6AjS+wIapFgsTPtBR/
RxUgKIKwaBLArlwH1/ZZzMtiVlxNSf8miKtUUTovStoOmOKJcrn892g8xB85essX
gfMMrQ/cYWIbEAsEHikYcV5iy0PevjG6cQIZTiapUdqMZGkD3pz9ff17Ybz8hHyI
XLTDe+1fK0YS8f0AAZqLW+mjBS6PLlve8xt4+GaRCMBeztWwNsrUqHugffkwer/4
3RlRKyC6/qfPoU6wZ/WAqiuDLtKOVImOHikLAgMBAAGjggKpMIICpTA0BggrBgEF
BQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTAS
BgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwMwVjAo
BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggrBgEF
BQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCsw
KaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMtZzIuY3JsMA4GA1Ud
DwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkwVzBVFglpbWFnZS9naWYw
ITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZLjAlFiNodHRwOi8vbG9n
by52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjApBgNVHREEIjAgpB4wHDEaMBgGA1UE
AxMRQ2xhc3MzQ0EyMDQ4LTEtNTIwHQYDVR0OBBYEFKXvCxHOwEEDo0plkEiyHOBX
LX1HMIHnBgNVHSMEgd8wgdyhgcekgcQwgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMyBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5
OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrghB92f4Hz6getxB5Z/uniTTGMA0G
CSqGSIb3DQEBBQUAA4GBAGN0Lz1Tqi+X7CYRZhr+8d5BJxnSf9jBHPniOFY6H5Cu
OcUgdav4bC1nHynCIdcUiGNLsJsnY5H48KMBJLb7j+M9AgtvVP7UzNvWhb98lR5e
YhHB2QmcQrmy1KotmDojYMyimvFu6M+O0Ro8XhnF15s1sAIjJOUFuNWI4+D6ufRf
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Symantec Corporation/OU=FOR TESTING - DEMO PURPOSES ONLY/CN=ssltest24.bbtest.net
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 3886 bytes and written 423 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 1E71C2949CE7B6AE2AB1B3A266412B63DD06F94A4AED5D63D39EAFD96584BA9E
    Session-ID-ctx: 
    Master-Key: 173EDB2F05C5138B2C99DA4E64C3124DA0AB5C6E7383571940D7FE95DF9EC1B7323B82084E6499A47354F90F5E94FD4D
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 7b 63 e1 57 10 3b ee 83-98 0e 12 10 50 68 8a c0   {c.W.;......Ph..
    0010 - 6f 8a a2 7d c4 73 21 94-f4 20 9c e2 d9 3f f4 24   o..}.s!.. ...?.$
    0020 - 70 e4 b8 4e 0a 52 8a f2-97 ef a0 90 f0 90 0d 81   p..N.R..........
    0030 - db d1 1e eb cf f1 10 53-d8 26 4c 7d 02 8b 1f f6   .......S.&L}....
    0040 - c4 03 1c 68 ef 81 58 e6-0f 1b 09 15 bc bc 5e 28   ...h..X.......^(
    0050 - e0 e0 9f 40 3c 00 d0 40-3b 8f b8 2d 74 22 02 58   ...@<..@;..-t".X
    0060 - d6 49 a8 3e 0a b9 ab 62-73 b2 4c 69 aa 1b 07 ce   .I.>...bs.Li....
    0070 - 87 02 64 c5 c8 b9 96 dd-91 f9 66 67 bc 9f 58 d6   ..d.......fg..X.
    0080 - a8 62 1f 64 41 05 49 df-0e d5 97 c9 b0 99 08 e5   .b.dA.I.........
    0090 - eb b2 af cf fa 48 50 d6-ce 88 ca 59 63 4e b4 df   .....HP....YcN..
    00a0 - 3c 3d bf 4a 8c db b6 99-7d 4d f7 fc b3 d6 79 e3   <=.J....}M....y.
    00b0 - 74 3a 7a 4c d4 3c 26 bf-e7 ff ed 8a b1 aa d2 77   t:zL.<&........w

    Start Time: 1397521693
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
Attached patch ssltest24 — — Splinter Review 
David's other suggestion was to download the cert and use certDB.verifyCertNow. I tried this and ran into problems adding it and finding it in the cert db

0:03.13 TEST-UNEXPECTED-FAIL | /home/mchew/mozilla-central/testing/xpcshell/head.js | NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIX509CertDB.findCertByNickname] - See following stack:
Camilo said he would take this.
Assignee: nobody → cviecco
Here is the reason why it fails on the processing of the subject key id/autority key id.

In particular the EE certificate has a authority key id value(7A:10:FC:3D:8D:F4:34:BF:15:63:B8:A2:3D:7C:5A:A4:D2:E3:4A:24) that does not match the subject key value of the present in the intermediate (A5:EF:0B:11:CE:C0:41:03:A3:4A:65:90:48:B2:1C:E0:57:2D:7D:47)

This makes the verification check fail in classic (filter_subject_certs_for_id) and in libpkix (pkix_CertSelector_Match_SubjKeyId). Mozilla::pkix assumes that these values are optimizations and actually does not attempt to use them

Accoding to rfc 5280:
  ...In conforming CA certificates, the value of the
   subject key identifier MUST be the value placed in the key identifier
   field of the authority key identifier extension (Section 4.2.1.1) of
   certificates issued by the subject of this certificate.  Applications
   are not required to verify that key identifiers match when performing
   certification path validation.

so the current behavior (not caring about matching is OK) however conforming CA MUST have this enforced. So my suggestion is to change this bug to:

require authority key identifier/subject key identifier matching accorting to RFC. Also since this does not violate the rfc I would not make it a blocker. 

Kathleen what do you think?
Flags: needinfo?(kwilson)
Camilo: Thanks for digging into this, I haven't had a chance to look.

Please note that RFC 5280 explicitly discourages applications from making this check (see Section 6.1 of it, specifically:

  "While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks."
(In reply to Ryan Sleevi from comment #9)
> Camilo: Thanks for digging into this, I haven't had a chance to look.
> 
> Please note that RFC 5280 explicitly discourages applications from making
> this check (see Section 6.1 of it, specifically:
> 
>   "While the algorithm could be extended to include checks for
>    conformance to the profiles in Sections 4 and 5, this profile
>    RECOMMENDS against including such checks."

Right. Based on the above, it looks like we should file two bugs:

1. Tech Evangelism bug to notify the CAs in our CA program to be aware of this non-conformance issue.

2. A bug in NSS/libraries to fix NSS's behavior to ignore the mismatch.

Then this bug can be RESOLVED INVALID.
Filed NSS Bug 997917
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
I agree with the resolution of this bug.

> 1. Tech Evangelism bug to notify the CAs in our CA program to be aware of
> this non-conformance issue.


I added this to https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix

Thanks!
Flags: needinfo?(kwilson)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: