On June 4, Apple submitted an incident report: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1556906, which is reposted below.

Incident Report

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 2019-05-21 14:30 PT, the CA compliance team was notified by an internal 
developer that during the course of a code review, it was discovered that 
certificates had been issued with Common Names (CNs) longer than 64 characters. 

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 

2019-05-15 9:00 PT - Code review identified that the software that checks 
certificates for Baseline compliance was not enforcing a max length of 64 
characters for CNs.
2019-05-15 11:24 PT - The only two impacted certificates that were still valid 
were revoked by the developer who identified the issue.
2019-05-21 14:30 PT - Compliance team was notified about the issue.
2019-05-21 18:00 PT -  Risk assessment was completed. 
2019-05-22: 10:00 PT - Software fix was deployed to the production environment.
2019-05-23: 8:42 PT - Requested meeting with DigiCert (the Root CA) to discuss 
the incident.
2019-05-24: 13:00 PT - Notified Ernst & Young (WebTrust assessors).

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.

A software update that prevents issuance of certificates with CNs longer than 
64 characters was deployed in production on 2019-05-22 at 10:00 PT.

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.

28 certificates were impacted between 2014-11-28 and 2019-03-25.

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.

A file has been attached with a list of all impacted certificates.

6. Explanation about how and why the mistakes were made or bugs introduced, and 
how they avoided detection until now.

The software that checks certificates for Baseline compliance prior to issuance 
and for quarterly self audits was not enforcing a max length of 64 characters 
for the CN.

7. 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.

i.  A software fix that enforces a maximum of 64 character CNs was deployed in 
production on May 22nd. 
ii.  The internal notification process will be enhanced by mid-June to minimize 
the time between identification of a suspected issue and communication to the 
compliance team.
iii.  We plan to implement a second linter (most likely zLint) by end of June, 
which is based on a separate code base, to strengthen the ability to prevent 
and detect mis-issuance.
dev-security-policy mailing list

Reply via email to