Our goal is to reissue all the certificates within the next 30 days. We have started the revocation process. We have a significant number of customers that use manual methods for managing their certificates, so being agile for them is difficult. We want to keep our customers using https through the entire revocation period. Due to the large number of certificates and the benign nature of the issue, our plan is to revoke in a responsible way.
Once this is completed, I think we need to get together and have a serious discussion around how to handle potential incidents like this in the future. Having a discussion about if this is right or wrong in the middle of an incident doesn’t help anyone. On Thursday, March 7, 2019 at 7:01:41 PM UTC-7, Daymion Reynolds wrote: > As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate > Serial Number issue. We have identified a significant quantity of > certificates (> 1.8million) not meeting the 64bit serial number requirement. > We are still performing accounting so certificate quantity is expected to > change before we finalize the 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. > > 9pm 3/6/2019 AZ Time, due to reviewing a discussion in > mozilla.dev.security.policy. > > 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 done. > > 9pm 3/6/2019 AZ Time, identified a hot issue with serial numbers in Mozilla > group. > 10am 3/7/2019 AZ Time, identified the issue was pervasive, and identified > root cause. > 6:30pm 3/7/2019 AZ Time, fix deployed to production to correct the serial > number issue. > We are still quantifying and classifying the certificate scope of impact. > > 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. > > We have deployed a fix to the issue, and are no longer issuing certificates > with the defect. > > 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. > > Issue was introduced with a change in 2016. Impacted certificates still being > aggregated. Will update with information and timeline on issue closure. > > 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. > > Still being aggregated. Will update with certificate information on issue > closure. > > 6. Explanation about how and why the mistakes were made or bugs > introduced, and how they avoided detection until now. > > Ambiguity in language led to different interpretations of BR 7.1. It was > believed a unsigned 64bit integer was sufficient to satisfy the new > requirement. Additionally, industry tools like CABLint/ZLint were not > catching this issue, which provided a false sense of compliance. We are > submitting CABLint/Zlint updates as part of the fix. > > 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. > > Defect has been resolved, we are also updating linting tools (CABLint/Zlint) > and upstreaming to patch for other peoples usage. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
