Closed Bug 367245 Opened 13 years ago Closed 13 years ago
Please add the Global
Sign Root certificate to the NSS
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) Build Identifier: Current NSS build level not known The latest GlobalSign root certificate will be avaialable here http://secure.globalsign.net/cacert/Root-R2.crt from the 29th January. Please can this be added to the NSS in line with CABForum work undertaken to issue new certificates. This will be sent to Nelson and Frank by separate signed e-mail. The SHA 1 is 75 e0 ab b6 13 85 12 27 1c 04 f8 5f dd de 38 e4 b7 24 2e fe Reproducible: Always Steps to Reproduce: 1. 2. 3.
I gather this new cert will be an EV root?
Assignee: nobody → hecker
Status: UNCONFIRMED → NEW
Component: Libraries → CA Certificates
Ever confirmed: true
Product: NSS → mozilla.org
QA Contact: libraries
Version: unspecified → other
Yes this is the root we created for EV backward compatibility on XP. The GlobalSign Root CA (2014) is also used to create EV cerifiactes for Windows Vista. CA GlobalSign Status Hopefully approved soon ;-) Related Bug, 367245 Documents Certificate Practice Statement(s) http://www.globalsign.com/repository/index.cfm Audits https://cert.webtrust.org/ViewSeal?id=327 Certificate(s) GlobalSign Root CA https://secure.globalsign.net/cacert/root.crt 2f 17 3f 7d e9 96 67 af a5 7a f8 0a a2 d1 b1 2f ac 83 03 38 GlobalSign Root CA - R2 https://secure.globalsign.net/cacert/root-r2.crt 75 e0 ab b6 13 85 12 27 1c 04 f8 5f dd de 38 e4 b7 24 2e fe Attached in ZIP format to this bug. Roots Trusted for all CRL’s GlobalSign Root CA http://crl.globalsign.net/root.crl GlobalSign Root CA - R2 http://crl.globalsign.net/root-r2.crl
Steve: just to be certain, the certificate you label "GlobalSign Root CA" is already included, and you are asking for inclusion of "GlobalSign Root CA - R2"? Gerv
Do you plan to use OCSP with this new cert? If so, what is the OCSP URL? Gerv
We will in the future be adding OCSP services, however to date we are keeping the CRL's in operation for the GlobalSign root CA. The new R2 Root will not be directly used for SSL certficates on its own for several years (until the ubiquity is sufficient, which is why we need the R2 root adding now). I hope that these replies answer your questions?
I have gathered together all the information you have provided, and placed it in the "pending" CA root certificate request list, which is here: http://www.mozilla.org/projects/security/certs/pending/ Please confirm that the information for your CA is correct, and add a comment to this bug to that effect. Once you have done that, your application will turn "green" and be ready for consideration. If your CA or certificate does not have a summary paragraph, please feel free to provide one. Note: these paragraphs are not supposed to be marketing statements :-) Gerv
The information in http://www.mozilla.org/projects/security/certs/pending/ is correct. Please add to the comment section at the end. GlobalSign, as the first WebTrust compliant CA in Europe, is currently celebrating a decade of delivering a portfolio of digital certificate solutions to customers around the globe and is proud to have additional roots of trust included in future Mozilla products.
Steve: thanks for the para, but the comments section is for my comments, not yours! I'm sure every CA applying feels similarly honoured that we would deign to consider them. :-P I'll turn your entry green in the next update. Gerv
I have begun this assessment. Some questions: - What is the expiry date of your current WebTrust audit? Is a new one currently being done? - The details for Domain ServerSign specifically state that domain control is verified (section 1.9.4), but those for Organization ServerSign do not. Can you confirm that your procedure for this certificate type includes a domain control verification step? (I'm sure it does :-) - Do you have a certificate hierarchy diagram? - Can you provide the URL of a website with an example end entity certificate issued by this root? Thanks, Gerv
A new webtrust audit is scheduled to take place in May 2007. We have recently signed the engagement letter. This will be done by the current auditors (Deloitte) Nice to see you have read the CPS! Section 1.8.2 states :- Upon verification of identity of the Internet Server.... which does mean the domain name. I'll see if we can improve the wording to be more specific in the future however yes, we do check domain control. We check everything that we include in our certificates. I don't have a public facing diagram that I can point you to. https://ev.globalsign.com/ will function however you'll need to ensure the browser first installs the new root CA as this page is cross signed with the Legacy GlobalSign Root which will display by default.
I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at: http://www.mozilla.org/projects/security/certs/policy/ . On behalf of the Mozilla project, I apologise for the delay. Here follows my assessment. If anyone sees any factual errors, please point them out. 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: they are a Belgian commercial CA selling certificates to the general public. Policies are documented in the documents published on their website and listed in the entry on the pending applications list. Section 7 [Validation]. GlobalSign appears to meet the minimum requirements for subscriber verification, as follows: * Email: For certificates with the E-mail Protection EKU (220.127.116.11.18.104.22.168.4), GlobalSign verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate (see sections 1.3.3, 1.4.3 and 1.5.2 of CPS v5.3). * SSL: For certificates with the TLS Web Server Authentication EKU (22.214.171.124.126.96.36.199.1), GlobalSign verifies domain control (see section 1.8.2 and 1.9.4 of CPS v5.3). GlobalSign also issues organisationally-validated server certs, with additional verification requirements. * Code: For certificates with the Code Signing EKU (188.8.131.52.184.108.40.206.3) GlobalSign confirms the identity of the applicant (see section 1.12.4 of CPS v5.3). Section 8-10 [Audit]. GlobalSign has successfully completed an audit using the WebTrust for CAs criteria. The auditors were Deloitte (Denmark). The audit is valid until May 2007. Section 13 [Certificate Hierarchy]. GlobalSign has multiple intermediate CAs under 2 roots. These intermediate CAs are used for different classes of certificate (see section 220.127.116.11 of CPS v5.3). Other: GlobalSign issues CRLs (on a 1 week schedule). They do not offer OCSP service. I am therefore minded to approve the application. Before I do, I'm opening up a period of public discussion of this request. I'll post in the mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period, unless discussion continues beyond that time, is two weeks. Gerv
Status: NEW → ASSIGNED
Reassign all open CA bugs to me. Apologies for the bugspam. Gerv
Assignee: hecker → gerv
Status: ASSIGNED → NEW
The comment period has passed without incident; I have therefore opened bug 378163 to cover the actual inclusion of the certificates in the store. Gerv
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.