Closed Bug 515462 Opened 15 years ago Closed 14 years ago

Add VeriSign PCA1 G1 SHA1 and PCA3 G1 SHA1 root certificates to NSS

Categories

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

Product:
NSS
Component:
CA Certificates Code
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
3.12.8

People

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

References

Details

Attachments

(2 files)

PCA1-G1-SHA1 root cert
846 bytes, application/x-x509-ca-cert
Details
PCA3-G1-SHA1 root cert
846 bytes, application/x-x509-ca-cert
Details 
This bug requests inclusion in the NSS root certificate store of the following two certificates, owned by VeriSign.

Friendly name: 
VeriSign Class 1 Public Primary Certification Authority (PCA1 G1 SHA1)
Certificate location: 
https://bugzilla.mozilla.org/attachment.cgi?id=375224
 (will also attach to this bug)
SHA1 Fingerprint: 
CE:6A:64:A3:09:E4:2F:BB:D9:85:1C:45:3E:64:09:EA:E8:7D:60:F1
Trust flags: email
Test URL: 
https://bugzilla.mozilla.org/attachment.cgi?id=390566

Friendly name: 
VeriSign Class 3 Public Primary Certification Authority (PCA3 G1 SHA1)
Certificate location: 
https://bugzilla.mozilla.org/attachment.cgi?id=375222
(will also attach to this bug)
SHA1 Fingerprint: 
A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
Trust flags: web sites, email, code signing
Test URL: 
https://shop.spiegel.de

This CA has been assessed in accordance with the Mozilla project guidelines,
and the root certificates have been approved for inclusion in bug 490895.

The next steps are as follows:

1) A representative of the CA must confirm that all the data in this bug is
correct, and that the correct certificate(s) have been attached. They must also
specify what OS they would like to use to perform the verification below.

2) A Mozilla representative creates a test build of NSS with the new
certificate(s), and attaches nssckbi.dll to this bug. A representative of the
CA must download this, drop it into a copy of Firefox and/or Thunderbird on the
OS in question and confirm (by adding a comment here) that the certificate(s)
have been correctly imported and that websites work correctly.

3) The Mozilla representative checks the certificate(s) into the NSS store, and
marks the bug RESOLVED FIXED.

4) At some time after that, various Mozilla products will move to using a
version of NSS which contains the certificate. This process is mostly under the
control of the release drivers for those products.
Attached file PCA1-G1-SHA1 root cert — 

    
    

    
  

      
      
      
      

        Attached file
          
        PCA3-G1-SHA1 root cert
        — 
      

    


  

    
    

    
  
Jay, Please see step #1 above.

    
    

    
  
taking.
Assignee: kaie → nelson
Priority: -- → P2
Target Milestone: --- → 3.12.5

    
    

    
  
NSS has a LONG standing design characteristic (it was deliberate, so it's not
a "bug") that, within any single PKCS#11 token, all the certificates that 
share a single identical subject name must also share a single identical "nickname" (also known as the "Friendly name" or the "CKA_LABEL").  

NSS's store of root CA certs is a single PKCS#11 token.  It already bears 
certificates with these subject names and nicknames:

Subject name:
   OU=Class 3 Public Primary Certification Authority,
    O="VeriSign, Inc.",
    C=US
Nickname: "Verisign Class 3 Public Primary Certification Authority"


Subject name:
   OU=Class 1 Public Primary Certification Authority,
    O="VeriSign, Inc.",
    C=US
Nickname: "Verisign Class 1 Public Primary Certification Authority"

This RFE proposes to add two more certificates to that same PKCS#11 token,
certificates with the same exact subject names given above, but with 
different proposed nicknames.  The technical limitations of NSS may leave 
us with no choice but to reuse the old Nicknames with the new certificates.
I am conferring with my fellow NSS developers about this problem this week.

    
    

    
  
This is to confirm for the OS to do the verification, we will use Window
XP Pro SP2.

    
    

    
  
Bob, we need to come to some resolution on the nickname conflict issue 
presented by this bug pretty quickly.  (See comment 5.)

Here are the old and new names juxtaposed

Verisign Class 1 Public Primary Certification Authority
VeriSign Class 1 Public Primary Certification Authority (PCA1 G1 SHA1)
....^..................................................^^^^^^^^^^^^^^^

Verisign Class 3 Public Primary Certification Authority
VeriSign Class 3 Public Primary Certification Authority (PCA3 G1 SHA1)
....^..................................................^^^^^^^^^^^^^^^
Whiteboard: CONCALL

    
    

    
  
I agree it's a bad idea to put two different nicknames for the same Subject name.

It won't break outright, but it will certainly confuse users as NSS will always treat the to certs as having a single nickname  (whether there is a single name or not).

(Firefox has avoided referencing things by nickname because of this).

I suggest we either always use the old name, or set both certs to the new name. I suggest the vendor make the choice here.

Issues with using the new name -- the confusion could still exist if the user has loaded the old cert into his softoken database.

bob

    
    

    
  
I have a problem with the suggestion of letting the vendor choose to change
the existing nickname of an existing cert.  It won't be an issue for Firefox,
but as we all know, NSS is used by many more products than merely firefox.
Changing the nickname will break programs that are presently relying on the 
existing nicknames.  I believe we would be violating our backwards binary 
compatibility promises if we allowed that change.

I think there's really only one option here that doesn't break compatibility
and that is to require the new cert to use the same nickname as the old one.

    
    

    
  
> Changing the nickname will break programs that are presently relying on the 
> existing nicknames.

Only if the cert was stored outside of ckbi, which is possible. If both certs within ckbi are changed, the nicknames will still be consistent.

> I think there's really only one option here that doesn't break compatibility
> and that is to require the new cert to use the same nickname as the old one.

I'm OK with this position.

bob

    
    

    
  
> Only if the cert was stored outside of ckbi,
I think you mean: if the cert's nickname is stored by the application,
which is the norm.

    
    

    
  
> > Only if the cert was stored outside of ckbi,
>
> I think you mean: if the cert's nickname is stored by the application,
> which is the norm.

No, I mean the cert. and I mean stored in another token, like softoken, as in someone has changed their view of the trust flags of the certificate.

Storing the nickname of a root cert in some application specific space certainly isn't the norm. Though I guess it's possible.

I would lay money on the first case being more prevalent, though either alone would argue for your proposal of only accepting the new nickname.

bob

    
    

    
  
> your proposal of only accepting the new nickname.

That should be:
your proposal of only accepting the *old* nickname.

bob

    
    

    
  
Verisign is ok with accepting the old nickname.

    
  
Depends on: 527759

    
    

    
  
removing CONCALL entry from whiteboard, as I believe the issue has been clarified => we'll go with the old nicknames

We'll not use the "friendly names" from comment 0, but the first choice for each of both certs, as listed in comment 7:

Verisign Class 1 Public Primary Certification Authority
Verisign Class 3 Public Primary Certification Authority

I confirmed these are the labels used by the current roots module.
Whiteboard: CONCALL

    
  
Assignee: nelson → kaie

    
    

    
  
Please perform the test (3) mentioned in the initial comment in this bug.

Instead of using a separate nssckbi.dll, I've produced a full test firefox build, please download from:
https://build.mozilla.org/tryserver-builds/kaie@kuix.de-bug527759/

We'll wait for you to confirm your root(s) have been added correctly to this test build (cert listed in cert manager, trust flags as expected, you can connect to your test site as expected).

    
    

    
  
An updated test build that contains the roots from this bug, plus some roots from other bugs, is now available at

https://build.mozilla.org/tryserver-builds/kaie@kuix.de-bug527759-11/

    
    

    
  
Downloaded the self extracting archive under the "install" directory of

https://build.mozilla.org/tryserver-builds/kaie@kuix.de-bug527759-11/

Installed "Shiretoko" on Windows XP SP2.  The requested roots were NOT included and the MD2 roots remain listed under the "Authorities" Tab when viewing certificates.

=Alan Dundas - VeriSign

    
    

    
  
OK... Old roots and new roots *are* there, however, web sites are still chaining to the old roots.   https://wellsfargo.com should chain to the new sha-1 root and still chains to old MD2 root.

    
    

    
  
(In reply to comment #19)
> OK... Old roots and new roots *are* there, however, web sites are still
> chaining to the old roots.   https://wellsfargo.com should chain to the new
> sha-1 root and still chains to old MD2 root.

If I understand correctly, NSS' cert selection mechanism when searching for issuer certs uses the timestamp.

But, both your old md2 and your sha certs seem to use identical timestamps.

Why do you expect that there is a guarantee that NSS will always prefer the SHA signed cert? Well, maybe you simply expect that, but I guess, NSS doesn't consider the strength of the signing algorithm when selecting potential issuer certs?

My guess is, NSS looks for a cert, and stops searching as soon as it finds a good match, and the old one is a good match.

Maybe Nelson or Bob want to comment as well.

    
    

    
  
Kai,

The timestamps aren't identical. The SHA-1 versions have an end date one day later than the MD2 versions. We did that in case clients favored certs with later end dates. So it seems that NSS' cert selection mechanism doesn't use the timestamp?

-Rick

    
    

    
  
NSS definitely pays attention to notBefore and notAfter dates.
I did an experiment.  I took a browser which does not yet have the above
two certs in it, I visited https://wellsfargo.com, and I confirmed that the
cert chained up to the root in the builtin token.  Then I downloaded and 
trusted the 2 roots attached above, and repeated the experiment with 
wellsfargo.com.  The second time, the certs chained to the newly downloaded
root.

    
    

    
  
Nelson, two of our guys tried it independently, and see that site chaining up to the MD2 root. Do you have any suggestions on how to troubleshoot this?

    
    

    
  
It'll be good to figure out the test results that VeriSign is seeing, but...

Perhaps we should consider removing the old MD2 root at this time.

    
    

    
  
Kathleen, we don't think we can do that because in the past, VeriSign issued certs from intermediate CAs that had the serial number of the MD2 root in their AKI extension. Those sites would appear untrusted in a new version of Firefox that did not contain the MD2 root.

    
    

    
  
Is the MD2 root affected by "or authority key IDs that include both the key ID and the issuer's issuer name and serial number" as stated in the Mozilla CA Policy? See http://www.mozilla.org/projects/security/certs/policy/ section 4.

As such, without removing the MD2 root, I'm not sure what would have been gained in terms of security?

    
    

    
  
I don't believe VeriSign has violated Mozilla's policy. Here's an example of one of those old intermediate CAs that had an AKI pointing to the MD2 root:
-----BEGIN CERTIFICATE-----
MIIEnDCCBAWgAwIBAgIQdTN9mrDhIzuuLX3kRpFi1DANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDUwMTE5MDAwMDAwWhcNMTUwMTE4MjM1OTU5WjCBsDELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwNTEqMCgGA1UEAxMhVmVyaVNpZ24gQ2xhc3Mg
MyBTZWN1cmUgU2VydmVyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAlcMhEo5AxQ0BX3ZeZpTZcyxYGSK4yfx6OZAqd3J8HT732FXjr0LLhzAC3Fus
cOa4RLQrNeuT0hcFfstG1lxToDJRnXRkWPkMmgDqXkRJZHL0zRDihQr5NO6ziGap
paRa0A6Yf1gNK1K7hql+LvqySHyN2y1fAXWijQY7i7RhB8m+Ipn4G9G1V2YETTX0
kXGWtZkIJZuXyDrzILHdnpgMSmO3ps6wAc74k2rzDG6fsemEe4GYQeaB3D0s57Rr
4578CBbXs9W5ZhKZfG1xyE2+xw/j+zet1XWHIWuG0EQUWlR5OZZpVsm5Mc2JYVjh
2XYFBa33uQKvp/1HkaIiNFox0QIDAQABo4IBgTCCAX0wEgYDVR0TAQH/BAgwBgEB
/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwMQYDVR0fBCowKDAmoCSgIoYgaHR0
cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMy5jcmwwDgYDVR0PAQH/BAQDAgEGMBEG
CWCGSAGG+EIBAQQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRQ2xhc3Mz
Q0EyMDQ4LTEtNDUwHQYDVR0OBBYEFG/sr6DdiqTv9SoQZy0/VYK81+8lMIGABgNV
HSMEeTB3oWOkYTBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xNzA1BgNVBAsTLkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHmCEHC65B0Q2Sk0tjjKewPMur8wDQYJKoZIhvcNAQEFBQADgYEA
w34IRl2RNs9n3Nenr6+4IsOLBHTTsWC85v63RBKBWzFzFGNWxnIu0RoDQ1w4ClBK
Tc3athmo9JkNr+P32PF1KGX2av6b9L1S2T/L2hbLpZ4ujmZSeD0m+v6UNohKlV4q
TBnvbvqCPy0D79YoszcYz0KyNCFkR9MgazpM3OYDkAw=
-----END CERTIFICATE-----

The value of the AKI extension is this:
  X509v3 Authority Key Identifier: 
      DirName:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
      serial:70:BA:E4:1D:10:D9:29:34:B6:38:CA:7B:03:CC:BA:BF

As you can see, it contains the issuer name and serial number, but not the issuer's key id.

I can't say that keeping the MD2 root provides a security gain, but it provides a usability gain in that certs that are now live and trusted by Firefox and other browsers will continue to be trusted by Firefox.

    
    

    
  
I can't explain why NSS prefers to chain to old md2 cert rather to new sha1 cert.

If I understand correctly, should the md2 root ever get removed/disabled, then NSS will chain up to the newer root.

I agree it's unfortunate that we can't do a real test now, because of NSS' unexpected preference to chain to the old root.

I did an experiment as well, I used the test build and used certificate manager and used "edit cert" to configure the old md2 root and removed all trust flags.

Afterwards, using certificate manager to view this old md2 root (class 3), I get the report "could not verify as expected".

Now, visiting https://shop.spiegel.de I get a result which surprises me.
- site is shown as trusted
- cert chains up to class 3
- root cert is md2 cert

If MD2 has its trust removed on software level, why does NSS still chain up to it?

Then I went to https://wellsfargo.com/ and I see another unexpected result. Firefox reports the site as untrusted, it apparently can't find a trusted root.

I propose to file a NSS bug to investigate the behavior of NSS when both roots are included.
I propose to postpone this inclusion task until this issue get's clarified.

The builds mentioned on comment 17 unfortunately are automatically deleted after 14 days, however, I saved them locally and can provide a download link from another location, if necessary, please let me know.

    
    

    
  
Nelson, do you know how to use NSS command line tools to dump the list of roots from a pkcs#11 module?
(I created a new db, I used modutil to add the nssckbi module, but still, certutil -L doesn't list the roots.)

    
    

    
  
> The builds mentioned on comment 17 unfortunately are automatically deleted
> after 14 days, however, I saved them locally and can provide a download link
> from another location, if necessary, please let me know.

http://kuix.de/mozilla/bug527759/bug527759-11-linux.tar.bz2
http://kuix.de/mozilla/bug527759/bug527759-11-win32.zip

035d7ccf3ccd7cf6f081c2cdfe6d5ddfa4eca020  bug527759-11-linux.tar.bz2
3a5c2a44a32a017bb8d16dadde2a115f810c8efc  bug527759-11-win32.zip

    
  
No longer depends on: 527759

    
    

    
  
In answer to the question in comment 29:

certutil -d DB -L -h "Builtin Object Token"

or more generally

certutil -d DB -L -h [token name]


In answer to comment 28: 
Are you sure that PSM is builing the cert chain that it displays in the 
same way that NSS does when it builds the chain to verify it?  

I think it is possible that PSM is displaying a different chain than the 
one that NSS builds and tests when it validates the cert chain.

How does PSM get the chain that it displays?

    
    

    
  
(In reply to comment #31)
> certutil -d DB -L -h "Builtin Object Token"

Thanks

I found a difference between the listing of old and new Class 3 certs.
The old one has the step-up approval flag set.
Do we need to specify step-up for the new one, too?


> How does PSM get the chain that it displays?

PSM is still using the old (pre-PKIX) way of obtaining the chain.

    
    

    
  
> > How does PSM get the chain that it displays?
> 
> PSM is still using the old (pre-PKIX) way of obtaining the chain.

In particular, PSM calls CERT_GetCertChainFromCert

    
    

    
  
(In reply to comment #33)
> > > How does PSM get the chain that it displays?
> > 
> > PSM is still using the old (pre-PKIX) way of obtaining the chain.
> 
> In particular, PSM calls CERT_GetCertChainFromCert

I would like to add:

The only time when PSM calls into new PKIX verification APIs is when PSM verifies a cert for EV. The EV verification only takes place after the cert could be verified by using classical NSS APIs.

PSM may report a cert chain that is different from the one that grants EV verification.

But the verification result I refered to earlier in this bug were obtained using classic APIs CERT_VerifyCertificate / CERT_VerifyCert.

I'd expect CERT_GetCertChainFromCert to return the same chain that NSS selects when it verifies a cert using classic APIs CERT_VerifyCertificate / CERT_VerifyCert.

    
    

    
  
(In reply to comment #32)
> I found a difference between the listing of old and new Class 3 certs.
> The old one has the step-up approval flag set.
> Do we need to specify step-up for the new one, too?

Yes, please. We still sell SGC (aka step-up) certs that chain up to this root.

    
    

    
  
(In reply to comment #32)
> Do we need to specify step-up for the new one, too?

IMO, we have no such need, and have not since year 2000.
On the other hand, it wouldn't hurt any, and wouldn't help much, if any.

That flag only was used in the old "export" browsers, which would not do 
strong ciphers in SSL/TLS without a step-up cert from an approved CA. 
It serves no purpose in "domestic" browsers, which do all ciphers without
restriction.  All Netscape and Mozilla browsers made in the year 2001 and
since then have been domestic browsers, AFAIK.  NSS still supports the old
"export" mode of operation, but AFAIK, no products use it, and we don't 
even test it in our QA tests.  

So, IMO, setting that flag is pointless.  Maybe someone out there is still
using a 10 year old export browser and is still relying on step-up.  But if
so, that user won't be using the newest nssckbi when it comes out, so your 
patch won't affect that user anyway.

Also, SSL Step-Up depends on renegotiation, which (as you probably know) is
now considered to be a vulnerability.

    
    

    
  
(In reply to comment #34)
> I'd expect CERT_GetCertChainFromCert to return the same chain that NSS 
> selects when it verifies a cert using classic APIs CERT_VerifyCertificate /
> CERT_VerifyCert.

I would expect that, too, but at the moment, I think that hypothesis needs to
be tested. :-/

    
    

    
  
Could the difference in step-up flags between old and new verisign cert have any effect on NSS' preference to select one or the other cert?

    
    

    
  
In reply to comment 38, No, I don't believe it would have any such effect.

    
    

    
  
Is there a way to move forward on this request?

    
  
Target Milestone: 3.12.5 → Future

    
    

    
  
Why was this pushed off to "Future"?

    
    

    
  
(In reply to comment #41)
> Why was this pushed off to "Future"?

This was simply a cleanup measure, because the previous target milestone 3.12.5 was incorrect, and I don't know what new target milestone is realistic.

    
    

    
  
(In reply to comment #40)
> Is there a way to move forward on this request?

If Bob, Nelson and Rick all agree,
we could add the new root, despite the fact that NSS still chains up to the old root.

Bob, Nelson, Rick, do you agree or disagree to add the root anyway?


Fixing the unexpected preference of the older root requires that an engineer debugs and analyzes the issue, as I had proposed in comment 28. As a general reminder, please note this is an open source project, and I'm sure the NSS team is open to contributed developers resources from parties who are interested in quick resolution.

    
    

    
  
Kai, IMO, it's better to use target "--" than "future" because "future" 
has been used by developers to mean "not in my lifetime".  

The concern here is over the possibility that adding the new root might
break something, especially if the certs don't chain up to it. No one seems
to have the time to prove or disprove the hypothesis that it will have no 
unintended detrimental effects.  If it can be shown to have no detrimental
effects, then I have no objections.

    
  
Assignee: kaie → nobody
Whiteboard: needs-analysis
Target Milestone: Future → ---

    
    

    
  
(In reply to comment #43)
> (In reply to comment #40)
> > Is there a way to move forward on this request?
> 
> If Bob, Nelson and Rick all agree,
> we could add the new root, despite the fact that NSS still chains up to the old
> root.
> 
> Bob, Nelson, Rick, do you agree or disagree to add the root anyway?

I agree.

    
    

    
  
In comment 43, back in March, Kai asked;
> Bob, Nelson, Rick, do you agree or disagree to add the root anyway?

Unfortunately, questions like that often get lost.  They're not findable 
in bugzilla searches.  There's no way for me to search for bugs that are
waiting for me to answer some question, unless it's a review request.

Anyway, I have no objection to adding the new root.

    
    

    
  
Thirded...

bob

    
  
Depends on: 582575

    
    

    
  
Ok, since everyone agrees, I've included the two roots from this bug in the current batch of added roots.

Current test builds (Mozilla experimental) for various platforms can be found at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/kaie@kuix.de-92eacf382419/

Please note the builds at above location will be automatically deleted after two weeks, so please make copies if you need them.

Please test and confirm that your roots have been added correctly, with the correct trust flags (use certificate manager, find your cert, click "view" to see the trust flags).

    
    

    
  
Kai,

Thanks - I downloaded the 4.0b3pre build, and verified that the two certs have been added. The trust bits are consistent between the MD2 and SHA-1 versions of the roots; however I'm a bit confused about the "uses" lists.

For example, I see these certs and uses:
VeriSign Class 3 Public Primary Certification Authority (MD2):
  Status Responder Certificate

VeriSign Class 3 Public Primary Certification Authority (SHA-1):
  SSL Client Certificate
  SSL Server Certificate
  Email Signer Certificate
  Email Recipient Certificate
  SSL Certificate Authority
  Status Responder Certificate

VeriSign Class 3 Public Primary Certification Authority - G2:
VeriSign Class 3 Public Primary Certification Authority - G3:
  SSL Server Certificate
  Email Signer Certificate
  Email Recipient Certificate
  SSL Certificate Authority
  Status Responder Certificate

VeriSign Class 3 Public Primary Certification Authority - G4
  SSL Certificate Authority

VeriSign Class 3 Public Primary Certification Authority - G5:
  SSL Certificate Authority

Since these are essentially different generations of the same root, why the big discrepancy in uses? What does "Status Responder Certificate" mean?

I'm not too concerned because (a) the SHA-1 version of the G1 root has a superset of uses that the MD2 version has, and (b) except for the SHA-1 version of the G1 root, these uses seem identical to what's in my 3.6.6 version of Firefox. But I am confused.

-Rick

    
    

    
  
> What does "Status Responder Certificate" mean?

= cert valid for being used by an OSCP server

    
    

    
  
(In reply to comment #49)
> 
> For example, I see these certs and uses:
> VeriSign Class 3 Public Primary Certification Authority (MD2):
>   Status Responder Certificate

When looking at a regular build which contains only this old cert, I get the same output (when using "view cert" in cert manager).

I conclude this limited set of uses is NOT a regression caused by adding the newer root.

I agree the output is strange, given that it's correctly used by NSS as a CA root for verifying server certs, e.g. at https://shop.spiegel.de

I agree this would deserve investigation, (helpwanted), should be one in a separate bug, since the symptoms are not specific to the new roots.


> VeriSign Class 3 Public Primary Certification Authority (SHA-1):
>   SSL Client Certificate
>   SSL Server Certificate
>   Email Signer Certificate
>   Email Recipient Certificate
>   SSL Certificate Authority
>   Status Responder Certificate

... and I agree it's strange that we list an additional set of uses for the newer root.

    
    

    
  
(In reply to comment #49)
> 
> Thanks - I downloaded the 4.0b3pre build, and verified that the two certs have
> been added. The trust bits are consistent between the MD2 and SHA-1 versions of
> the roots; ...

Thanks for confirming, I conclude we can proceed getting these roots added.

    
    

    
  
fixed with bug 582575
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: needs-analysis
Target Milestone: --- → 3.12.8
Assignee: nobody → kaie

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: