A number of certificates issued by the Yandex CA subordinate have unallowed key usage: https://crt.sh/?cablint=775&iCAID=2014&minNotBefore=2017-01-01 Please provide an incident report for this problem, as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report The incident report should be posted to the mozilla.dev.security.policy forum and added to this bug.
I will prepare it soon.
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. From Bugzilla bug 1495518 created by Wayne Thayer on October 1 2018 at 18:42 GMT. 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. Oct 1, 2018 18:42 GMT - The Bugzilla bug 1495518 was created. Oct 2, 2018 - We analyzed this case and found the reason for misissues. We started to prepare the fix. We found all affected certificates. We informed our customers about this bug and necessity to revoked certificates. Oct 3, 2018 12:00 GMT - We deployed fix on production. 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. Oct 3, 2018 at 12:00 GMT. 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. Total number of affected valid certificates: 43. All certificates, except two, already have been revoked. These two certificates will be revoked by the end of this week. 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. In attachement. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. We did not properly choose the profile name for certification request with EC public key in our software. Instead of choose EC profile where Key Encipherment value in Key Usage extension is disallowed we choose RSA profile where Key Encipherment value in Key Usage extension is allowed. The bug was not found by our tests suite because we did not have scenario for such case. 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. - We have fixed our software. Now, if a certification request contains EC public key only EC certificate profile is allowed to use. - We have added the appropriate test case. Now, for every software release we check that appropriate profile is chosen for given type of public key. - We have added an additional protection at the certificate profile level in the CA issuing system. Now, the CA system for issuing certificates will block the issuance of the certificate if it receives unmatched combination of public key and profile.
Full list of the affected certificates for bug 1495518.
Thank you for the incident report. I believe it does a good job of explaining how you will prevent this specific problem from happening again, but it does not address the broader problem of misissuance and Certum's failure to detect it. How can the Mozilla community be assured that Certum will detect and prevent all types of certificate misissuance in the future?
In addition to the things that I described earlier we have added to our periodic verification procedure the point where a check of "CA/B Forum lint: Summary" site from crt.sh is required at least every 5 days. It should help us to detect any misissuance related to inconsistency with RFC 5280/CABF BR. In order to prevent such misissuances in the future we are going to add pre-issuance linting in first half of 2019.
Please update this bug when pre-issuance linting is in place.
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-July 2019
Sure, I will update this bug.
QA Contact: kwilson → wthayer
Whiteboard: [ca-compliance] - Next Update - 01-July 2019 → [ca-compliance] - Next Update - 01-August 2019
Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Next Update - 01-August 2019 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.