- 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.
The issue was discovered via post issuance linting on 1/22 at 22:00 GMT.
- 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.
- The issue was discovered via post issuance linting on 1/22 at 22:00 GMT. The customer was informed.
- An investigation was immediately made of the certificate management system and a fix was deployed in Development systems on the evening of 1/22. That was moved to Production systems on 1/23.
- On 1/28 at 13:30 GMT the certificates were revoked.
- 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.
Yes, a fix has been deployed in our certificate management system.
- 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 certificates triggered the following zLints as they included a SAN with a leading “.” (equivalent to an empty label).
ERROR: Characters in labels of DNSNames MUST be alphanumeric, - , _ or *
ERROR: DNSName MUST NOT start with a period
ERROR: DNSNames should not have an empty label.
These requests were made sequentially on 1/22. A review was made of other QV issuance to verify that no other certificates of this type exist.
- 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.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Our certificate management system did not have a filter in place for this, and had never had a previous request that included the leading dot, before these 8. The circumstance is so rare that Censys is only aware of 11 currently valid trusted certs with this error (including these 8).
- 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.
The fix was deployed in production systems on the evening of 1/23.