Closed Bug 751954 Opened 7 years ago Closed 7 years ago

Add Renewed StartCom root certificates to NSS

Categories

(NSS :: CA Certificates Code, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED
3.13.6

People

(Reporter: kwilson, Unassigned)

References

Details

(Whiteboard: In FF16)

Attachments

(2 files)

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

Friendly name: StartCom Certification Authority
Certificate location: https://www.startssl.com/certs/ca-sha2.pem
SHA1 Fingerprint: A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
Trust flags: Websites, Email, Code Signing
Test URL: https://www.startssl.com/

Friendly name: StartCom Certification Authority G2
Certificate location: https://bugzilla.mozilla.org/attachment.cgi?id=572356
SHA1 Fingerprint: 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
Trust flags: Websites, Email, Code Signing
Test URL: https://g2.startcom.org/

This CA has been assessed in accordance with the Mozilla project guidelines, and the certificates approved for inclusion in bug #602750 and bug #640368.

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 certificates have been attached.

2) A Mozilla representative creates a patch with the new certificates, and provides a special test version of Firefox.

3) A representative of the CA uses the test version of Firefox to confirm (by adding a comment in this bug) that the certificates have been correctly imported and that websites work correctly.

4) The Mozilla representative requests that another Mozilla representative review the patch.

5) The Mozilla representative adds (commits) the patch to NSS, then closes this bug as RESOLVED FIXED.

6) At some time after that, various Mozilla products will move to using a version of NSS which contains the certificates. This process is mostly under the control of the release drivers for those products.
Eddy, Please see step #1 above.
I confirm the certificates and fingerprints thereof as stated above are the correct ones.
Blocks: 751960
(In reply to Kathleen Wilson from comment #0)
> 
> Friendly name: StartCom Certification Authority
> Certificate location: https://www.startssl.com/certs/ca-sha2.pem
> SHA1 Fingerprint: A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
> Trust flags: Websites, Email, Code Signing

I have a request for clarification regarding this certificate 

The NSS trust module already contains a certificate with this identical friendly name.
I think we should not have two certificates with the same friendly name.

Please clarify which of the following you want:

(a) REMOVE the old certificate with this friendly name,
    and REPLACE it with the specified new certificate
    (new = A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0)

or 

(b) KEEP the old certificate with this friendly name,
    and ADD the new certificate in addition.


Please state whether you want (a) or (b).


If your intention is (b),
then please provide a new, unique friendly name for this new certificate
(new = A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0).
(In reply to Kai Engert (:kaie) from comment #5)
>
> I think we should not have two certificates with the same friendly name.

Well, I just checked, and we already have such a duplicate.

Our trust module already contains two certificates with an identical friendly name
(see "Verisign Class 3 Public Primary Certification Authority").

I think this is unfortunate, and I would prefer to avoid confusion when referring to certificate.

However, given that your certificate wouldn't be the first one with such a naming conflict, I'm updating my question and request:


Please state whether you want (a) or (b).


If your intention is (b),
then please state how you want to proceed regarding the friendly name.

Is your choice
  (1) use the duplicate friendly name as originally requested in this bugzilla
or
  (2) use a different, unique friendly name 


Please state whether you want (1) or (2).

If your choice is (2), then please suggest the new friendly name,
Blocks: 757197
I think the correct answer is to remove the SHA1 root and add the SHA2 root instead (old root) - option (A). 

I do not expect any negative effect by removing the SHA1 hashed root, should this not be the case we'd have to look at it again. Basically two identical roots with the same public key and friendly name can co-exist within NSS without any problem too.

(Additionally we add the G2 root which is not related to anything so far - just mentioning it so that this doesn't get mixed up.)
Eddy, Firefox and NSS are independent products.

Firefox might run in an upgraded environment, where it still has ONLY the old list of EV-activated roots,
but already a newer NSS.

In that environment, if the newer NSS contains ONLY the newer root,
then you will lose EV in those environments.

(e.g. environments that use a modern snapshots of NSS for security reasons, but still use an older version of Firefox, e.g. the ESR version.)
I didn't thought about that scenario - in that case we'll need both OIDs for the older root at least for the time-being?
Let's do all EV related discussion should happen in bug 751960, not here.
The test build is available at
  http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/kaie@kuix.de-b51f34a5b5c1/
or from
  http://kuix.de/mozilla/tryserver-roots-20120604/

Can a CA representative please verify the trust settings for correctness?

(see initial comments in this bug,
 and you should make sure that you're using a fresh profile
 to make sure you really see the trust bits provided by this build,
 not trust settings that you had set manually in an application profile.)
Tested and the trust settings are correct. Thanks.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: In FF16
Target Milestone: --- → 3.13.6
You need to log in before you can comment on or make changes to this bug.