1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
On 16-October, when we reviewed the items listed in our CCADB task "Check failed Audit Letter Validation (ALV) results", we found there are 30 ICA certificates, that although technically capable of TLS issuance (due to lack of EKUs) are not actually capable of TLS issuance as they are not provided TLS certificate profiles nor TLS workflows in our certificate management system. These ICAs do not issue TLS certificates. These ICAs are older, before GlobalSign commenced using explicit EKU in line with changing industry expectations. These ICAs are listed in the table below.
All these ICAs were disclosed in CCADB, and have always been disclosed in the annual WebTrust for CAs audit, which is conducted concurrently with the WebTrust audits for BRs and EVG. The complete population of GlobalSign issued certificates in the audit period is provided to the WebTrust auditors.
2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
- 16-October-2019: discover 30 ICA in CCADB without EKU but not intended for TLS issuance are listed in WebTrust audit for CAs audit report, but not listed in WebTrust audit for BR report.
- 17-October-2019: Performed investigation on EKUs and WebTrust CA scope
- 18-October-2019: We met with the WebTrust auditors to work out the plan to amend the WTBR report for the 1-April-2018 to 31-March-2019 audit period.
- 23-October-2019: Further workshops with auditor to revalidate the EE certs issued from these impacted ICAs to confirm none of them are TLS EE certs. We expect the revalidation to be completed by within around 3 weeks.
3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
N/A - no TLS server certificates have been issued from these CAs.
4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
N/A - no TLS server certificates have been issued from these CAs.
5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
GlobalSign did not include these unconstrained CAs in our most recent WTBR report. These CAs were however included in the WebTrust Principles and Criteria for Certification Authorities (WTCA) report. All of them were disclosed in CCADB. These ICAs missing in the WTBR report was an oversight of the intent of the Mozilla policy for covering them in a BR audit even though these ICAs were purposely built not for TLS issuance.
No TLS certificates were issued from these CAs.
Please refer to the file attached to the initial bug report for an overview of the affected ICA.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The mistake was due to our false understanding of the meaning of technical capability of ICAs.
In Mozilla root policy up to v2.4 (Publication date: February 28, 2017), Audit Requirements #2 states,
2. CA operations relating to issuance of certificates capable of being used for SSL-enabled servers must also conform to the latest version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.
Then Mozilla root policy since v2.4.1 (Publication date: March 31, 2017), 3.1.2 Required Audits states,
If being audited to the WebTrust criteria, the following audits are required (see section 3.1.1 for specific version numbers):
•For the SSL trust bit, a CA and all subordinate CAs technically capable of issuing server certificates must have all of the following:
◦WebTrust for CAs
◦WebTrust for CAs - SSL Baseline with Network Security
◦WebTrust for CAs - EV SSL (if applying for EV recognition)
•For the email trust bit, a CA and all subordinate CAs technically capable of issuing email certificates must have all of the following:
◦WebTrust for CAs
While in the Mozilla 'April 2017 CA Communication' survey, ACTION 3: UPDATED MOZILLA CA CERTIFICATE POLICY stated,
Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been published. Differences between versions 2.4 and 2.3 (published Dec 2016), and between versions 2.4 and 2.2 (published July 2013) may be viewed on Github. Version 2.4.1 contains exactly the same normative requirements as version 2.4 but has been completely reorganized. Please review version 2.4.1 of Mozilla's CA Certificate Policy and confirm that your CA complies with it.
So when we read the 18.104.22.168 WebTrust audit requirements, we thought the trust bit refers to the Mozilla trusted root store setting, and “technically capable of issuing server certificates” still has the same mean as in v2.4, “CA operations relating to issuance of certificates capable of being used for SSL-enabled servers”, and both were referring to issuing system control in all of operational, procedural, technical aspects.
Another factor enforced our wrong interpretation regarding purpose or capability of ICAs, was actual via reading of Microsoft policy. Microsoft policy has been had the separation of purposes quite some time ago. In Sept 2016, before creating a bundle of ICAs, we specifically arranged a meeting with Microsoft root policy team to clarify their policy about the purpose and separation of ICAs. Microsoft advised us that, the conclusion, is pretty simple. You must put EKUs in end entities and you may put them in intermediates. Intermediates can therefore also have AnyEKU (or no EKU) but end entities cannot have this as the risk is a code signing certificate that could be used for SSL (or Visa Versa) if the root is marked for SSL and no EKUs are present in the chain. Old and new roots are really treated the same, the only difference being that new roots are specifically marked for certain EKUs where as old roots were not, so that’s why they originally separated in the root program text to rule 11 and 12.
This reinforced our wrong understanding that the procedure control will also be a deciding factor when looking at the capability of an ICA. Because of this false impression we had, we didn‘t realised that the Mozzila policy ver 2.4.1 audit requirement only based on EKUs, without considering the technical and procedural controls we put in on these ICAs.
We think the new ALV feature provided in CCADB now is very useful to communicate and clarify our wrong understanding about this Mozilla audit expectation.
7. List of steps your CA is taking to resolve the situation and ensure such issuace will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
- We are now working with our WebTrust auditor to revalidate the EE certs issued from these impacted ICAs to confirm none of them are TLS EE certs. We expect the revalidation to be completed by within around 3 weeks.
- When this revalidation work is completed, we will work with our WebTrust auditor to amend our most recent WTBR audit to explicitly disclose these impacted ICAs. We will update this disclosure when that is complete, which should be shortly after the completion of revalidation work.
- Although not reflected in the ALV report of CCADB, we went ahead and further requested the WebTrust auditor to review all the ICAs in the WTBR report and amend the WTEVSSL report for the same period, if any ICAs are technically capable of issuing EV EE certs due to unconstrained policy OIDs.
- We are in the process of performing a review of all GlobalSign ICAs to ensure that audit scoping is appropriate and have updated our processes to ensure that any future ICAs are named in appropriate audits per Mozilla’s requirements, in accordance with Mozilla Root Program Policy 22.214.171.124 WebTrust.