- 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 became aware of the problem on Sat 5/11/2019 via our problem reporting mechanism, that is by receiving an email on email@example.com.
- 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.
Sat 5/11/2019 8:36 PM received mail from Alex Cohn firstname.lastname@example.org
„Inspired by Nick Lamb's comment a week or so ago on m.d.s.p about "Default City" being an OpenSSL default value in CSRs, I ran some more searches on the OpenSSL defaults and found almost 100 certificates with a stateOrProvinceName of "Some-State". BR section 188.8.131.52.2(f) requires this field to be verified if present in a certificate. “
Sat 5/11/2019 8:36 PM – 9:30 PM On https://misissued.com/batch/53/ we identified only one certificate issued by us with the mentioned problem.
Sat 5/11/2019 10:14 PM the certificate was revoked.
Monday 5/13/2019 we started to investigate the cause of the problem.
Tue 5/14/2019 3:54 AM – a bug with the problem was raised on bugzilla. mozilla.org
Friday 5/17/2019 6:00 PM – we have finalised the investigation and identified the cause of the issue as human error + insufficient technical controls regarding certificate subject fields data validation.
During Monday 5/20/2019 and Thursday 5/23/2019 we decided the changes to be made and implemented and communicated those changes to all those concerned.
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.
There was only one certificate issued with the mentioned problem. See next the measures we have taken.
- 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.
There was only one certificate issued with the mentioned problem. See next.
- 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.
There was only one certificate issued crt.sh ID 1012576297
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
We have an issuance procedure is in place at RA. The RA Officer checked the CSR she received from the client. When checking the CSR she failed to verify the field stateOrProvinceName. The second RA Officer performed the cross-check verification and also failed to verify the filed stateOrProvinceName. The RA interface visually distinguish DN subject fields provided by the customer CSR and validation errors (e.g. missing mandatory DN fields, invalid field length, invalid country, invalid characters in CN) are shown in the interface.
The CSR provided by the client was created using OpenSSL with the default value for stateOrProvinceName ‘Some-State’. During the checks performed by our Registration Authority Officers this was not detected which led to the issue of the certificate mentioned. One reason for this issue was the fact that there was no technical control in place for the content of field stateOrProvinceName. Also, the second reason is the fact that both RA officers failed to verify subject information. RA officers reported that sometimes they are disturbed by other colleagues while performing the verifications and they may have lost focus and missed to observe the wrong information.
- 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.
We already implemented technical controls to check the default value in stateOrProvinceName=”Some-State” and L="Default City". Also we decided that the RA Officers that check SSL certificates information before issuance, while doing this, will concentrate solely on this type of activity and will not allow to be disturbed by other activities. We will provide trainings to our RA staff twice a year as opposed to once per year as the situation is currently . Also, we will increase the percentage of the sample certificates verified during the internal audit from 3% to 10%.