(In reply to Wayne Thayer )
Please provide an incident report as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
- 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.
Entrust Datacard discovered the miss-issue through testing when renewing certificates for the root embedding test sites. The multi-problems were discovered on July 4 and July 8, 2019.
- 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.
July 4, 2019, 13:55 UTC - Manually issued an EV SSL certificate using the wrong profile; as such, the certificate was signed using SHA-1, had no SAN and the CDP was missing the HTTP URL. This certificate expired on July 6, 2019, 2:22 UTC.
July 4, 2019, 14:15 UTC - Started to manually issuing 3 certificate using the correct profile. Unfortunately, this profile had a spelling error in the URL for the OCSP responses. Note that one certificate was revoked during this process as it was issued for a test site showing a revoked certificate.
July 8, 2019, 10:05 UTC - Discovered the spelling error in the certificates.
July 8, 2019, 20:51 UTC - Revoked one certificate. The others did not need to be addressed as they had either already been revoked or had expired.
- 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 CA has stopped issuing certificates using the incorrect policy and with spelling errors.
- 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.
One certificate signed with SHA-1 was issued on 4 July 2019.
Three certificates with the incorrect OCSP URL were issued on 4 July 2019.
- The complete certificate data for the problematic certificates.
The following certificate was issued with the incorrect policy and was signed using SHA-1.
The following 3 certificates were issued to the correct profile, but there was a spelling error in the url for the OCSP response.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The issuing CA is not set up for production as there are no third party certificates currently being issued. There is no automated issuance nor is there any pre-issuance linting set for a non-production CA. The certificates to support the BR required test sites were issued manually.
The problems occurred due to two reasons:
- The incorrect CA policy was chosen as a result the certificate was issued signed with SHA-1, no subjectAltName and no HTTP URL for the CRL.
- A new certificate profile was created. This was not necessary as the CA already had a legitimate EV SSL certificate profile implemented. The new profile was tested in QA and a test certificate was issued. Multiple reviewers did not detect the typo in the OCSP URL.
- 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.
First, we will be limiting the number of certificates issued manually and move to a more automated issuance solution as noted in Bug 1561013. This solution will also be supported by our policy engine and pre-issuance linting.
In the interim, the CAs which are used to manually issue certificates have the correct default policy implemented and have an EV certificate profile which already meets the industry requirements. New certificates will be reissued as a recovery of existing certificates which use the current approved policy and profile.
In some cases the certificate cannot be issued by recovery. This is the case when the company data does not pass verification and must be updated. In this case, the manual issuance process will include the subject DN, SANs, certificate profile and validity period. The subject DN will be updated and the certificate will be issued using the same certificate policy as the certificate which it is replacing. The goal is the manual process will not change the configuration of the CA and the previous approved and usable configuration will be used.