Closed Bug 406796 Opened 13 years ago Closed 12 years ago

Enable GlobalSign Root for EV


(NSS :: CA Certificate Root Program, task)

Not set


(Not tracked)



(Reporter: steve.roylance, Assigned: hecker)



(Whiteboard: EV - approved)


(1 file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: 

* Name of the CA certificate
(1) GlobalSign Root CA  (Currently in the NSS but due to be refreshed (Bug 406794) by GlobalSign Root CA.  The latter expires in 2028 rather than 2014.
(2) GlobalSign Root CA - R2

* Published CP/CPS.
The GlobalSign CPS (Currently Version 5.6) is located in our repository 

* Published report describing how you're meeting the audit requirements of secton J of the EV guidelines.
GlobalSign is currently covered by the EV WebTrust readiness audit performed by Deloitte and approved by Microsoft for inclusion within IE.   This is not a public report.   The next audit for EV is due in April 2008 at the same point as the WebTrust for CA Audit.  The latter report is here:- 

* EV OID(s) for the CA certificate in question.

Reproducible: Always

Steps to Reproduce:
Ever confirmed: true
Whiteboard: EV
Independent of approval process, for technical testing purposes: Could you please supply an https:// URL to an example SSL server (customer or demo) that uses a server cert issued (directly or through intermediates) by this root? Should you request multiple roots to be enabled for EV, please provide one example URL for each root. Thank you.

No problem.  Here's a customer we press released so it's fine to use them as an example.

We issue from a single issuing CA which is itself linked to the two roots we want to mark as EV compliant.   i.e. both the newer root that expires in 2021 and the older root that is currently being refreshed from 2014 to 2028 should equally be marked up as supporting EV.  i.e. if vista encounters the 2014 root first via e-mail it will download to the user and it will be marked as EV, but if Vista encounters via SSL first it will see the shorter chain to the 2021 root and download and mark that as EV.   I hope that's clear? has some details

CA R2 is the 2021 root and CA R1 is teh 2014/refreshed 2028 root.

Kind Regards

Steve, another request for clarification: We already have a "GlobalSign Root CA - R2" in Mozilla, that expires on 12/15/2021, with SHA-1 fingerprint of

75 E0 AB B6 13 85 12 27 1C 04 F8 5F DD DE 38 E4 B7 24 2E FE

This appears to be the exact same certificate downloadable from

So you're not referring to adding a new cert, you just want this existing cert to be enabled for EV, correct?
That's correct Frank.   Today we already have 2 roots in the browser, but one is due to be refreshed under bug 406794.  Once refreshed, both roots should be enabled for EV.

Depends on: 406794
(In reply to comment #4)
> That's correct Frank.   Today we already have 2 roots in the browser, but one
> is due to be refreshed under bug 406794.  Once refreshed, both roots should be
> enabled for EV.

Thanks. I've marked this bug as being dependent on bug 406794.

Steve, please check the GlobalSign entry in te pending list:

and let me know of any corrections/additions.
Making EV root cert requests have uniform summaries.
Summary: Request GlobalSign CA certificate be enabled for EV → Enable GlobalSign Root for EV
According to 
as of this date, the information in this request is incomplete. 
The request is waiting for more information from the applicant.
Whiteboard: EV → EV - information incomplete
Assigning this to Kathleen Wilson, who will gather more information as needed.
Assignee: hecker → kathleen95014
Hi Steve,

Just a couple of questions in regards to this request, as many of your responses in #406794 also apply here.

1) Does your response in 40694 in regards to OCSP also apply to this root?
“We will be implementing OCSP soon, but not yet, so yes in effect we are
waiting for the OCSP bug to be fixed.”

2)  Please provide either a list or description of subordinate CAs operated internally. (For example, this might include subordinate CAs created to issue different classes or types of end entity certificates: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, EV certificates vs. non-EV certificates, SSL certificates vs. email certificates, and so on.)

3) Please list any other root CAs that have issued cross-signing certificates for this root CA.


(1) - OCSP will be implemented later this week as we can't now wait for the OCSP bug to be fixed.  OCSP certs are issued based on the end entity certs (i.e. the Extended validation SSL cert itself).  As EV has a cross cert it's effectively linked to two roots.  Our 2021 expiry root and 2014 expiry which will be replaced with 2028.    

(2) The certificates issued from our roots are covered in our CPS  (Page 5).  listed here again for speed.
PersonalSign 1 Demo	A personal certificate of low assurance
PersonalSign 2	        A personal certificate of medium assurance
PersonalSign 2 Pro	A personal certificate of medium assurance with reference to professional context
PersonalSign 3	        A personal certificate of high assurance
PersonalSign 3 Pro	A personal certificate of high assurance with reference to professional context
GlobalSign OrganizationSSL	A certificate to authenticate web servers
GlobalSign DomainSSL	        A certificate to authenticate web servers
GlobalSign ExtendedSSL	        A certificate to authenticate web servers *
GlobalSign Educational ServerSignSSL	A certificate to authenticate web servers
ObjectSign	A certificate to authenticate data objects
TrustedRoot	A certificate for CAs that enter the GlobalSign hierarchy

3) No other Root CAs have issued cross certs to us.  Our root is very ubiqutous on it's own.
Thanks for the info.

When you get OCSP set up, please provide the responder url.

Also, please indicate that the EV Guidelines in section 26(a) are met: “OCSP responses from this service MUST have a maximum expiration time of ten days.”

Hi Kathleen,

The OCSP responder URL has already been fixed in our spec, but will not resolve at the time of writing. It's going to be set up in 2-3 weeks. 

It will have a ten day maximum as per section 26(a).

This is a PDF version of the latest informational document on GlobalSign, as collected and verified by Kathleen Wilson. Note that two additional pieces of information were received after creation of this document:

WebTrust EV report URL:

I think we now have all the information we need to start the first public comment period for this request, so I'm formally declaring it open. Based on prior experience I'm going to fine-tune things a bit and set this first comment period at a week long, unless we need more time. So my tentative plan is to make a preliminary decision on these requests late next week.
Reassigning this bug to myself.
Assignee: kathleen95014 → hecker
Whiteboard: EV - information incomplete → EV - information complete, in public discussion
The first public comment period for this request is now over. I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at

On behalf of the Mozilla project, I apologise for any delay.

Here follows my assessment. If anyone sees any factual errors, please point them out.

Note that this assessment is specifically for the request to upgrade the GlobalSign Root CA - R2 certificate already present in Mozilla for EV, as well as to upgrade for EV use the new (refreshed) GlobalSign Root CA certificate requested to be included in bug 406794.

Also note that the GlobalSign Root CA - R2 certificate is a legacy root that has been present since before we adopted our current Mozilla policy. For that reason I'm going to include an review of GlobalSign's practices in relation to our policy. (This essentially duplicates the discussion in bug 406794 relating to the GlobalSign Root CA certificate, since the relevant policy and audit documents cover both roots and their hierarchies.)

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by GlobalSign, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. GlobalSign appears to provide a service relevant to Mozilla users: It's a commercial CA offering certificates to the general public worldwide. Policies are documented in the documents published on their website and listed in the entry on the pending applications list. Of these the most relevant for present purposes is the CPS:

Section 7 [Validation]. GlobalSign appears to meet the minimum requirements for subscriber verification, as follows:

    * Email: For certificates with the E-mail Protection EKU (, GlobalSign verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate, using an email-based challenge/response mechanism. (See the discussion of this point in the GlobalSign information checklist attached to this bug.) 

    * SSL: For certificates with the TLS Web Server Authentication EKU (, GlobalSign verifies domain ownership/control by various mechanisms. (See, among others, sections 1.9 and of the CPS.) 

For EV certificates GlobalSign verifies subscriber identity in accordance with the EV guidelines (See sections 1.10 and of the CPS.) 

    * Code: For certificates with the Code Signing EKU ( 
GlobalSign verifies that the entity submitting the certificate signing request is the same entity referenced in the certificate. (See sections 1.10 and of the CPS.)

Section 8-10 [Audit]. GlobalSign has successfully completed an audit using the WebTrust for CAs criteria. The auditors were Ernst & Young. The audit is current (covering the period up to March 31, 2008).

GlobalSign has also successfully completed an audit using the WebTrust EV criteria. The auditors and audit period were the same as for the WebTrust for CAs audit.

Note that (as has been the case for other CAs) our copy of the WebTrust EV report was obtained from the CA. Final approval of this request is contingent on verifying with the auditors that the report is in fact genuine.

Section 13 [Certificate Hierarchy]. GlobalSign has multiple intermediate CAs under a single root. Different types of certificates (e.g., personal vs. SSL vs. object signing) and different classes of certificates (e.g., personal class 1 vs. class 2, DV SSL vs. OV vs. EV) are issued by different subordinates.

Other: GlobalSign issues CRLs (on a 3-hour schedule) and also plans to stand up an OCSP responder in future.

Potentially problematic practices: As noted in the information checklist document, the only potentially problematic practice associated with GlobalSign is authorization of third parties to operate subordinate CAs. As noted in the information checklist document, GlobalSign exercises contractual control and audit oversight over the practices of such subordinates.

Based on the information available to me I am minded to approve this request to upgrade the new (refreshed) GlobalSign Root CA and the existing GlobalSign Root CA - R2 for EV use. Before I issue my final decision, I'm opening up a second one-week period of public discussion of this request in the newsgroup [1].

[1] The newsgroup is accessible via NNTP-capable
newsreaders at:


via email by subscribing to the associated mailing list:

and via the web at:
The second comment period is now over. Based on my evaluation and the comments received thus far, I am officially approving this specific request to enable both the new (refreshed) GlobalSign Root CA cert and the existing GlobalSign Root CA - R2 cert for EV, and have filed bug 446409 against PSM for the actual change.
Whiteboard: EV - information complete, in public discussion → EV - approved
Depends on: 446409
Since the PSM change (bug 446409) was resolved as FIXED, I'm resolving this as FIXED as well.
Closed: 12 years ago
Resolution: --- → FIXED
Product: → NSS
You need to log in before you can comment on or make changes to this bug.