User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763
Steps to reproduce:
We have tried to update our audits in the CCADB to close the case (00000435) but we have not been able to do it because of a 25-day gap between the two last audit reports.
We have covered the period until April 14th with the WebTrust audits performed in 2017 and the period for the year 2018 for Standard Audit, but we do not have covered the period between April 14th, 2018 and May 8th, 2018 for BR and EV SSL Audit.
The GAP between the two audits took place because two major non-conformities were detected during the audit. Due to the scheme of the eIDAS audit, we had to solve the nonconformities before obtaining the favourable report and the certification.
It is important to stand out that those major non-conformities were already solved before May 8th and that is why the auditors issued the certificate of compliance at that time.
- 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.
We tried to update the audit information in the CCADB but we could not do that.
With Mozilla staff help, we discovered that this 25-day gap is the reason that we could not update our audits in CCADB. The related information appears in the case number 00000435.
- 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.
When we discovered the problem, we gave the details about the problem to Mozilla team. Finally, they recommend that we open an incident report with all the information about the non-conformities detected that did not permit to obtain the eIDAS certificate in time and provoked the 25-day gap between audits.
- 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.
The SubCA involved has never stopped issuing certificates because of this problem
- 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.
- 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.
We have tried to update our audits in the CCADB in order to close the case (00000435) but we have not been able to do it because of a 25-day gap between the two last audit reports.
We have covered the period until April 14th, 2018 with the WebTrust audits that took in place in 2017 for Standard Audit and for BR and EV SSL Audit.
In 2018 we decided to change the WebTrust audit and obtain the eIDAS certification for BR and EV SSL Audit to cover the requirements. eIDAS certification is based on the ETSI EN 319 411 and its requirements are different.
We have the report that covers the period since April the 14th, 2018 in the case of Webtrust for CA (for Standard Audit), but not for ETSI EN 319 411 (for BR and EV SSL Audit)
In the case of ETSI EN 319 411 (for BR and EV SSL Audit), the auditors found several non-conformities under eIDAS scheme and in this case, we had to solve the non-conformities before obtaining the favourable report and the certification.
The non-conformities detected were the following:
a) Test certificates (SMIME): Some not allowed types are included in ASN.1 structure (in paragraph 4.2.3 of ETSI EN 319 412-5, annex B -wrong ASN.1 structure for qcType field-).
b) QCP-n (SMIME): Some certificates have been found without CountryName in the subject, and some certificates for public workers has been issued without Surname neither Pseudonym.
c) QCP-l (SMIME): There are some TSA certificates with a eIDAS QCP-l-qscd OID (0.4.0.194112.1.3), but they miss the qcStatement qscd (QcSSCD) .
d) QCP-w (TLS): There are some certificates that not fit the EVCP profile. There were missmatches like: subject field without businessCategory, jurisdictionCountryName, organizationName, serialNumber neither localityName, which is required in EV 9.2
e) (TLS) Additionally, certificates with length 0 in some fields have been found.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
We did not detect the problem until we tried to update the new audit information in the CCADB.
We started the audits in time, but the problem is that we could not avoid the GAP because of the non-conformities detected.
- List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
All the non-conformities detected were solved even before we detected the gap problem with the CCADB. We had to take the appropriate measures to solve each of the non-conformities and obtain the eIDAS certification, so we elaborated a remediation plan to solve them:
a) Although Camerfirma received the audit report from AENOR (2010/1041/PSC/01) on March 23rd, 2018, AC Camerfirma already detected and solved this issue on July 14th, 2017.
b) Camerfirma first became aware after the reception of the audit report from AENOR (2010/1041/PSC/01) on March, the 23rd of 2018 and solved it on April 10th, 2018.
c) Camerfirma first became aware after the reception of the audit report from AENOR (2010/1041/PSC/01) on March, the 23rd of 2018 and solved it on April 10th, 2018.
d) Camerfirma first became aware after the reception of the audit report from AENOR (2010/1041/PSC/01) on March 23rd, 2018. After reviewing this issue, this problem was discussed with the auditors and it was determined that there wasn’t any error and the non-conformity was retired.
e) Although Camerfirma received the audit report from AENOR (2010/1041/PSC/01) on March, 23rd, 2018, AC Camerfirma already detected (March 7th, 2018) and solved this issue in March 2017. We opened a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1443857) with this issue. This bug was solved on May 17th, 2018.