Closed Bug 966350 Opened 11 years ago Closed 11 years ago

Distrust a pb.com certificate that does not comply with the baseline requirements

Categories

(NSS :: CA Certificates Code, task, P1)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rick_andrews, Assigned: cviecco)

Details

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; MS-RTC LM 8) Steps to reproduce: At the end of 2013, Symantec issued a cert to one of its customers that did not comply with several provisions of the CA/Browser Forum Baseline Requirements. We did this knowingly because if we had not, the customer would have experienced a significant loss of business. In addition, Symantec believed that this certificate posed very little or no risk to browser users. I don't have permission to reveal the name of the customer, but they are a major maker of devices that communicate over the Internet to the company's web server. The certificate is not intended to be used by a browser. We exhausted all other possible technical options before taking this step. Due to the limitations of their devices, they needed us to reissue a certificate directly off one of our 1024-bit roots, with a 1024-bit key in the end-entity cert, and with a Valid From backdated to 2010. Here are the details you will need if you wish to blacklist this certificate in NSS: Issuer = OU = Equifax Secure Certificate Authority, O = Equifax, C = US CDP = http://crl.geotrust.com/crls/secureca.crl AKI = 48 e6 68 f9 2b d2 b2 95 d7 47 d8 23 20 10 4f 33 98 90 9f d4 EKU = serverAuth, clientAuth Serial Number = ‎15 79 14 SKI = e3 79 a4 fd fb 77 0f bb bb 5d 95 11 7b c0 54 7e 0e 90 1c bb KU = Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0) Thumbprint (SHA-1) = 30 f1 82 ca 1a 5e 4e 4f f3 6e d0 e6 38 18 b8 b9 41 cb 5f 8c Valid From = ‎Monday, ‎February ‎01, ‎2010 6:54:04 AM Valid To = ‎Monday, ‎September ‎29, ‎2014 4:00:00 PM
(In reply to Rick Andrews from comment #0) > I don't have permission to reveal the name of the customer, but they > are a major maker of devices that communicate over the Internet to the > company's web server. Oh my, why do CAs believe they can keep such things secret? It didn't work in the Trustwave case (bug 724929 comment 88), and doesn't in this case, either. I'm under no NDA, do not have any insider knowledge, but here we go: it's Pitney Bowes. Specifically, it's the following certificate for *.pb.com: -----BEGIN CERTIFICATE----- MIIDUjCCArugAwIBAgIDFXkUMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTAwMjAxMTQ1NDA0WhcNMTQwOTMwMDAwMDAw WjBwMQswCQYDVQQGEwJVUzEUMBIGA1UECBMLQ29ubmVjdGljdXQxEDAOBgNVBAcT B0RhbmJ1cnkxFTATBgNVBAoTDFBpdG5leSBCb3dlczEPMA0GA1UECxMGTWV0ZXJz MREwDwYDVQQDDAgqLnBiLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA w6IuzcPeE723idfqifJshU3sa06s/EhL2QRFHkh3VETh2MJpAiHG3F6RALelCnc9 xfp6ankzVFv4FelJzjslt80Ug7DHAcGeETnKId2yEo0eGYHmokRA9XUdUQxJYqmy U2CgyegSpwjbaWpqHoWRmhypgPamhfHVTOIoRTVMBOsCAwEAAaOCARowggEWMB8G A1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA4GA1UdDwEB/wQEAwIE8DAd BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0RBBQwEoIIKi5wYi5j b22CBnBiLmNvbTA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0 LmNvbS9jcmxzL3NlY3VyZWNhLmNybDAdBgNVHQ4EFgQU43mk/ft3D7u7XZURe8BU fg6QHLswTAYDVR0gBEUwQzBBBgpghkgBhvhFAQc2MDMwMQYIKwYBBQUHAgEWJWh0 dHA6Ly93d3cuZ2VvdHJ1c3QuY29tL3Jlc291cmNlcy9jcHMwDQYJKoZIhvcNAQEF BQADgYEAVfZxkAkvtlL55G2nrD1N9ec0BcJ9/WOwnK+6Tf9egSl0CBFTxA/5iJ9A s98Gx8An8qgHXypp49Aru0NeKFLZotcE9tTZvc1ooYTjG6tJQbu2NMEfYEbSSdgL 4T+0dsJIw6/gBIUKNgHdcgbnvyi2lx4E045ua7cQ/spi4E4reOg= -----END CERTIFICATE----- which is a replacement for this certificate which has expired on 31 December 2013: -----BEGIN CERTIFICATE----- MIIDAjCCAmugAwIBAgIDFN1TMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTAwMjAxMTQ1NDA0WhcNMTMxMjMxMTQ1NDA0 WjBwMQswCQYDVQQGEwJVUzEUMBIGA1UECBMLQ29ubmVjdGljdXQxEDAOBgNVBAcT B0RhbmJ1cnkxFTATBgNVBAoTDFBpdG5leSBCb3dlczEPMA0GA1UECxMGTWV0ZXJz MREwDwYDVQQDDAgqLnBiLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA w6IuzcPeE723idfqifJshU3sa06s/EhL2QRFHkh3VETh2MJpAiHG3F6RALelCnc9 xfp6ankzVFv4FelJzjslt80Ug7DHAcGeETnKId2yEo0eGYHmokRA9XUdUQxJYqmy U2CgyegSpwjbaWpqHoWRmhypgPamhfHVTOIoRTVMBOsCAwEAAaOByzCByDAfBgNV HSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAdBgNVHQ4EFgQU43mk/ft3D7u7 XZURe8BUfg6QHLswDgYDVR0PAQH/BAQDAgTwMB0GA1UdJQQWMBQGCCsGAQUFBwMB BggrBgEFBQcDAjA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0 LmNvbS9jcmxzL3NlY3VyZWNhLmNybDAbBgNVHREEFDASgggqLnBiLmNvbYIGcGIu Y29tMA0GCSqGSIb3DQEBBQUAA4GBAAKg+JCZaTxjteSehMWrKorovivKujXy7kSm Gqv6zF2LRKekSpnN9Tkc9tnOuiKmKDzeKtWKa1V/0ah/RsvwcG9BAND5XVeLYr0d qSX1akFzv1OhWJVLXWUy/vpxUWr7dIuHZbLLt+jV2Quw7AoU/VBBfVKNNzpsBPY7 M5rbfMhx -----END CERTIFICATE----- Other differences besides the serial number and the notAfter field in detail: - the new cert also has a SAN extension (*.pb.com, pb.com) - the new cert includes a certificatePolicies extension with the 2.16.840.1.113733.1.7.54 OID, for which the GeoTrust CPS v1.1.13 ([1], November 7, 2013) states: "Symantec has assigned a reserved OID value for asserting conformance with the current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. This OID value is reserved for use by any brand of Symantec CA as a means of asserting compliance with these CABF Requirements and as such does not distinguish a particular brand or class of Certificate." [1] http://www.geotrust.com/resources/cps/pdfs/GeoTrustCPS-Version1.1.13.pdf
Status: UNCONFIRMED → NEW
Ever confirmed: true
Kaspar: are you saying the new cert asserts a "BR Compliance" OID? Rick: is that correct? If so, given that the entire point of the new cert involves it not being BR compliant, how did that happen? Gerv
Hi Camilo, Brian assigned the other one of these to you, so I'm assigning this one similarly. Sorry if that's wrong :-) Gerv
Assignee: nobody → cviecco
Gerv that is fine. Expected release 3.16
Attached patch patch-bug-966350 (obsolete) (deleted) — Splinter Review
Attachment #8378340 - Flags: review?(kaie)
I propose to use a different comment for the distrust record. We aren't distrusting pb.com in general. For example the comment could say "Distrust wrongly issued pb.com certificate".
(In reply to Kaspar Brand from comment #1) > - the new cert also has a SAN extension (*.pb.com, pb.com) It seems that isn't a difference, the old one had the same SAN extension, it's just that the order of extensions in the certificate has changed.
Comment on attachment 8378340 [details] [diff] [review] patch-bug-966350 r-, but only because of the comment. Otherwise the patch is correct. Please create a new patch using a different label (the different should be visible in both the comment and the actual label).
Attachment #8378340 - Flags: review?(kaie) → review-
(In reply to Kai Engert (:kaie) from comment #6) > I propose to use a different comment for the distrust record. We aren't > distrusting pb.com in general. For example the comment could say "Distrust > wrongly issued pb.com certificate". Camilo asked me to clarify what to change about the patch. I think he missed Kai's comment that I quoted above. The only thing that needs to be changed about the patch is the comment. Saying "Distrust pb.com" could be read to mean that we're going to distrust all or several pb.com certificates. I don't think "wrongly issued" is the right characterization either though; in the source code, we should avoid making opinionated statements like that unnecessarily. Instead, I suggest "Distrust a pb.com certificate that does not comply with the baseline requirements."
(In reply to comment #9) > I suggest > "Distrust a pb.com certificate that does not comply with the baseline requirements." This comment sounds good to me.
Attached file text dump of certificate to blacklist (deleted) —
This is a text dump of the certificate that Kaspar provided in comment 1, and which appears to match the certificate mentioned by Symantec in the initial comment.
Attached patch patch-bug-966350 (deleted) — Splinter Review
Attachment #8378340 - Attachment is obsolete: true
Attachment #8379075 - Flags: review?(kaie)
Comment on attachment 8379075 [details] [diff] [review] patch-bug-966350 r=kaie
Attachment #8379075 - Flags: review?(kaie) → review+
Target Milestone: --- → 3.16
Summary: Blacklist SSL certificate → Distrust a pb.com certificate that does not comply with the baseline requirements
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Brian, Please would you remove the unnecessary double-quote at the end of this line... CKA_LABEL UTF8 "Distrust a pb.com certificate that does not comply with the baseline requirements."" ...and from the corresponding comment? Thanks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Rob: I made the change you suggested: https://hg.mozilla.org/projects/nss/rev/17ea3e0f798f Is the change correct?
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Priority: -- → P1
Resolution: --- → FIXED
(In reply to Wan-Teh Chang from comment #17) > Rob: I made the change you suggested: > https://hg.mozilla.org/projects/nss/rev/17ea3e0f798f Thanks Wan-Teh. > Is the change correct? Yes.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: