Closed
Bug 700359
Opened 14 years ago
Closed 14 years ago
duplicate CKA_LABEL in certdata.txt
Categories
(NSS :: CA Certificates Code, task)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: mozilla.bugzilla, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110927 Fedora/3.6.23-1.fc14 Firefox/3.6.23
Build ID: 20110927162800
Steps to reproduce:
CKA_LABELS in certdata.txt rev 1.78 are now not unique across certificates. The labels below are each attached to two certificates in the file.
CKA_LABEL UTF8 "Verisign Class 1 Public Primary Certification Authority"
CKA_LABEL UTF8 "Verisign Class 3 Public Primary Certification Authority"
Actual results:
This came to my attention via two unfortunate effects: (1) The certificate manager, which displays certs by their label, now shows multiple certificates with the same label, which is confusing, and (2) the trusted certificate bundle for openssl on Fedora (and possibly Debian) derives from the Mozilla certdata.txt in a way that relies on label uniqueness. Duplicates are being excluded, causing previously trustworthy sites that rely on those roots (e.g. paypal, vonage) to be deemed untrusted.
Expected results:
Please consider adjusting the labels on these certs so that the labels are unique.
(In reply to Brad Rubenstein from comment #0)
> CKA_LABELS in certdata.txt rev 1.78 are now not unique across certificates.
> The labels below are each attached to two certificates in the file.
>
> CKA_LABEL UTF8 "Verisign Class 1 Public Primary Certification Authority"
> CKA_LABEL UTF8 "Verisign Class 3 Public Primary Certification Authority"
No, that observation is incorrect. Both strings appear twice in certdata.txt, that's true - but this applies to *all* certs: the first CKA_LABEL is for the certificate itself (CKO_CERTIFICATE object) and the second for the trust settings (CKO_NSS_TRUST object).
> This came to my attention via two unfortunate effects: (1) The certificate
> manager, which displays certs by their label, now shows multiple
> certificates with the same label, which is confusing,
Most likely you have additional copies of these certs in your cert DB. (I'd bet that if you look at the "Security Device" column, these will show "Software Security Device".)
> Duplicates are being excluded, causing previously trustworthy sites that
> rely on those roots (e.g. paypal, vonage) to be deemed untrusted.
My guess is that this is a consequence of the fix applied in bug 515462, in the end.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
I apologize for being to terse in my previous comment. I'll add these notes to make the bug clear.
I agree with Kaspar that the regression was introduced by the fix to bug 515462, which included two new certificates, whose CKA_LABEL's were identical to two other certificates already (and currently) existing in certdata.txt.
> No, that observation is incorrect. Both strings appear twice in certdata.txt, that's true > - but this applies to *all* certs: the first CKA_LABEL is for the certificate itself
> (CKO_CERTIFICATE object) and the second for the trust settings (CKO_NSS_TRUST object).
As Kaspar observes, CKA_LABEL appears twice for every certificate block, once for CKO_CERTIFICATE and once for CKO_NSS_TRUST. However, as of r1.78, for two and only two certificates (those introduced by bug 515462), the CKA_LABEL is duplicated between multiple CKO_CERTIFICATES (leaving the CKO_NSS_TRUST components aside).
> Most likely you have additional copies of these certs in your cert DB. (I'd bet that if
> you look at the "Security Device" column, these will show "Software Security Device".)
I have confirmed that in the Certificate Manager on a clean install of Firefox, one sees that "Verisign Class 3 Public Primary Certification Authority" does appear twice, both times with security device "Builtin Object Token".
The only way to distinguish these two is to drill down and notice they have different serial numbers and Certificate Signing Algorithms.
Again this problem does not affect every certificate. There are only two bad CKA_LABEL's in the database as of r1.78 (the two added to address bug 515462), and my request is that they be made unique, both to distinguish them at the user interface, and to allow downstream processes (such as Fedora's certdata2pem.py in ca-certificates rpms) which rely on unique CKA_LABEL's to not break.
For example, the CKA_LABEL on the new certificate added in the fix to bug 515462 could be renamed:
CKA_LABEL UTF8 "Verisign Class 1 Public Primary Certification Authority, SHA1 signature"
and
CKA_LABEL UTF8 "Verisign Class 3 Public Primary Certification Authority, SHA1 signature"
Let me know if I can provide any additional information.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(In reply to Brad Rubenstein from comment #2)
> However, as of r1.78,
> for two and only two certificates (those introduced by bug 515462), the
> CKA_LABEL is duplicated between multiple CKO_CERTIFICATES (leaving the
> CKO_NSS_TRUST components aside).
Again, this isn't true. In r1.78, there are exactly 335 lines starting with CKA_LABEL, and 168 distinct ones ("Mozilla Builtin Roots" only occurs one). The labels you quoted in comment 0 *do* differ, it's Class 1 vs. Class 3.
> I have confirmed that in the Certificate Manager on a clean install of
> Firefox, one sees that "Verisign Class 3 Public Primary Certification
> Authority" does appear twice, both times with security device "Builtin
> Object Token".
Then that's an issue of the Firefox and NSS version bundled with Fedora, I assume - you should perhaps file this on bugzilla.redhat.com.
> For example, the CKA_LABEL on the new certificate added in the fix to bug
> 515462 could be renamed:
> CKA_LABEL UTF8 "Verisign Class 1 Public Primary Certification Authority,
> SHA1 signature"
> and
> CKA_LABEL UTF8 "Verisign Class 3 Public Primary Certification Authority,
> SHA1 signature"
See bug 515462 comment 5 and bug 515462 comment 8 as to why this is considered a bad idea.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•