515472 - Add "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate to NSS

Status: RESOLVED FIXED

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

Description

[Kathleen Wilson]

This bug requests inclusion in the NSS root certificate store of the following certificate, owned by VeriSign.

Friendly name: 
VeriSign Class 3 Public Primary Certificate Authority - G4

Certificate location: 
https://bugzilla.mozilla.org/attachment.cgi?id=335538
 (will also attach to this bug)

SHA1 Fingerprint: 
22:D5:D8:Df:8F:02:31:D1:8D:F7:9D:B7:CF:8A:2D:64:C9:3F:6C:3A

Trust flags: web sites, email, code signing

Test URL:  https://205.180.234.250

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

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.

Comment 1

[Kathleen Wilson]

Attachment: VRSN-C3-PCA-G4 root cert

Comment 2

[Kathleen Wilson]

Jay, Please see step #1 above.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

taking.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Jay and Kathleen,
Over the weekend, I was working on the current crop of approved CA cert 
additions to NSS, and I noticed an inconsistency in the new friendly names.
Here are the 6 new friendly names requested, in ASCII sorting order:

"GeoTrust Primary Certificate Authority - G2"
"GeoTrust Primary Certification Authority - G3"
"VeriSign Class 1 Public Primary Certification Authority (PCA1 G1 SHA1)"
"VeriSign Class 3 Public Primary Certificate Authority - G4"
"VeriSign Class 3 Public Primary Certification Authority (PCA3 G1 SHA1)"
"VeriSign Universal Root Certification Authority"

Notice that some are "Certificate" Authority and others are "Certification" 
Authority.  Is that intentional or accidental?   Do you want to change them
to be consistent?  If so, which ones do you want to change? 

Speak now, or forever hold it.  :)
I'll make a test .dll file as soon as I hear from you.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Wait, there's another issue. 

As you will recall, NSS requires that all certificates with the same exact 
identical subject name also share the same exact identical friendly name.
Some of these new certs have the same subject name as other older certs
already in nssckbi.  I believe I *MUST* give the new ones the same friendly 
name as the previous cert(s) with the same subject name.  

At first glance, this issue appears to affect all of the new Verisign Root 
CA certs in this batch, but not the GeoTrust certs.  I need to double check 
that in detail.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Please ignore my comment 5 until I complete my investigation of that issue.
 
However, I have noticed another inconsistency in friendly names. 
In all friendly names used for Verisign roots prior to this request,
the name Verisign has been spelled just like that, only one capital 
letter, capital V.  Now, some certs are being requested to have friendly
names with two capital letters: VeriSign.  Again, my question is: in this
intentional?  The only alternatives available here are to 
a) leave them as they are now proposed, or 
b) make the new names consistent with the old ones.

Comment 7

[Jay Schiavo]

(In reply to comment #4)
> Jay and Kathleen,
> Over the weekend, I was working on the current crop of approved CA cert 
> additions to NSS, and I noticed an inconsistency in the new friendly names.
> Here are the 6 new friendly names requested, in ASCII sorting order:
> "GeoTrust Primary Certificate Authority - G2"
> "GeoTrust Primary Certification Authority - G3"
> "VeriSign Class 1 Public Primary Certification Authority (PCA1 G1 SHA1)"
> "VeriSign Class 3 Public Primary Certificate Authority - G4"
> "VeriSign Class 3 Public Primary Certification Authority (PCA3 G1 SHA1)"
> "VeriSign Universal Root Certification Authority"
> Notice that some are "Certificate" Authority and others are "Certification" 
> Authority.  Is that intentional or accidental?   Do you want to change them
> to be consistent?  If so, which ones do you want to change? 
> Speak now, or forever hold it.  :)
> I'll make a test .dll file as soon as I hear from you.

That was accidental. They should all have Certification and not Certificate. Please update the GeoTrust G2 and VeriSign G4 ones.

Comment 8

[Jay Schiavo]

(In reply to comment #6)
> Please ignore my comment 5 until I complete my investigation of that issue.
> However, I have noticed another inconsistency in friendly names. 
> In all friendly names used for Verisign roots prior to this request,
> the name Verisign has been spelled just like that, only one capital 
> letter, capital V.  Now, some certs are being requested to have friendly
> names with two capital letters: VeriSign.  Again, my question is: in this
> intentional?  The only alternatives available here are to 
> a) leave them as they are now proposed, or 
> b) make the new names consistent with the old ones.

The proper spelling is VeriSign with both the V and S capital. Please leave them as they are now proposed.

Comment 9

[Kai Engert [:KaiE:]]

I made a test build.

Sorry, when I did the test build, I had not read the most recent comments in this bug. What I did, I checked for nickname conflicts with existing certs.

I haven't seen any old verisign certs with "g4" in their name, therefore I used the nickname as proposed in the initial comment in this bug. I hope that's ok.


VeriSign Class 3 Public Primary Certificate Authority - G4

Comment 10

[Kai Engert [:KaiE:]]

While Jay responded to Nelson's questions in this, I don't see the confirmation that is being asked for initially.

Jay, could you please confirm the data in this bug is correct, as asked for in the initial comment? Thanks.

Comment 11

[Kai Engert [: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/[e-mail]-bug527759-11/

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).

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Kai, unfortunately, the discussion of the nickname issue is spread over 
several bugs.  In another bug, Jay (or some Verisign representative) agreed
that use of the old nickname would be OK.  (I'll try to find that comment and cite it in a subsequent comment in this bug.) Bob and I have agreed that we 
really want to use the same nickname everywhere for the same subject name.

So, in answer to comment 9, NO, the nickname requested in comment 0 is NOT OK.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

In bug 515462 comment 14, Jay Schiavo wrote:
> Verisign is ok with accepting the old nickname.

Comment 14

[Kai Engert [:KaiE:]]

Nelson, I believe the issue you had raised is limited to scenarios where a new certificate is to be included that uses the same subject/issuer as some other old certificate still being included.

In that particular scenario, you agreed that it's mandatory to keep using the same nickname for both old and new certs.

However, as far as I can tell, this bug is not an embodiment of the mentioned scenario.

This bug proposes to add a certificate using the following subject:

    CN=VeriSign Class 3 Public Primary Certification Authority - G4,OU="(c) 2007 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US

I was unable to find any existing certificate, currently being included in the NSS roots module, having the string "G4" in its common name (CN) field.

My conclusion is, the subject name in this new cert has not been used previously, and therefore there is no need to worry about keeping a nickname.

Please, I may be wrong, I may not have seen all the details of this particular history.

Please, if the nickname proposed in comment 0 is not appropriate, then please, tell me exactly what nickname you want me to use. Thanks.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

In comment 7 above, Jay wrote:

> They should all have Certification and not Certificate.
> Please update the GeoTrust G2 and VeriSign G4 ones.

So, if the new cert's subject name is not already among the known certs' 
subject names, then I suggest giving it the nickname

VeriSign Class 3 Public Primary Certification Authority - G4

Comment 16

[Jay Schiavo]

We checked the test build above and confirmed the VeriSign Class 3 Public Primary Certificate Authority - G4 root is added to the build and we could successfully access the test site listed above using a cert issued from this root. The trust bits (SSL/TLS) and Email (SMIME) that we requested, were enabled. However, we did request this root to have the code signing trust bit enabled, which we did not see.

Comment 17

[Kai Engert [:KaiE:]]

Jay, according to my own verification, the code signing trust bit is enabled
for this root.

In order to verify, I used the following steps:
- start firefox
- open certificate manager
- go to authorities tab
- scroll down to Verisign, Inc.
- select Verisign Class 3 ... G4
- click "Edit"

A dialog opens which has the following 3 checkboxes checked:
- identify web sites
- identify mail users
- identify software makers


I believe code signing is enabled.

What do you see when you perform above steps?
Is "identify software makers" checked or not checked?

Please tell me, how did you test and reach your conclusion that code signing
bit is missing?

Comment 18

[Jay Schiavo]

Hi Kai, 

Thanks for the instructions. I followed those steps and did verify "identify software makers" is checked. From our side the testing is complete and everything looks correct.

Jay

Comment 19

[Kai Engert [:KaiE:]]

Resolved fixed by Bug 527759