To m.d.s.p, The following contains an incident report, compiled as a result of the release of two example certificates with an incorrect CA-Issuers URI included.
Any questions or observations on this incident are gratefully received, and I will endeavour to answer them as quickly as I can. Regards, Neil Dunbar, CA Administrator, TrustCor Systems, S. de R.L. — 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. 2019-07-22 - 11:36:00 UTC - During TrustCor's post-issuance CT log monitoring process, Internal QA identified two (2) certificates which contained an incorrect URI value in the CA Issuers part of the authorityInformationAccess extension. 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. 2019-07-22 - 11:36:00 UTC - TrustCor becomes aware of this issue. 2019-07-22 - 11:37:00 UTC - Certificate issuance for the ECA-1 CA hierarchy suspended, pending investigation of issue. 2019-07-22 - 11:42:45 UTC - Revocation of the two (2) affected certificates completed. 2019-07-22 - 11:45:00 UTC - TrustCor identified the problem - incorrect value stipulated for an Internal Example Certificate profile under the ECA-1 root (no other hierarchies shared this issue). 2019-07-22 - 11:50:00 UTC - Emergency Change Order completed, the profile values for ECA-1 internal example certificates corrected on testing and production platforms. 2019-07-22 - 11:52:00 UTC - Testing issuance now yields corrected certificates. 2019-07-22 - 11:56:00 UTC - TCPA granted permission to reissue corrected certificates. 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. TrustCor stopped issuing certificates identified with this problem and rapidly resolved the issue. 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. Two (2) certificates were identified with this issue. The first was issued at 2019-07-22 11:11:50 UTC, and the second (and last) was issued at 2019-07-22 11:22:10 UTC. 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. Two (2) certificates were identified: one was revoked immediately post production (as it is there to demonstrate a revoked certificate), and the second certificate, which was otherwise valid, was then revoked upon identifying the issue. The crt.sh URIs for the certificates (now revoked) are: https://crt.sh/?id=1695491402 <https://crt.sh/?id=1695491402> https://crt.sh/?id=1695520034 <https://crt.sh/?id=1695520034> 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The problem was that the authorityInformationAccess CA-Issuers URI, (BR Section 7.1.2.3, subsection c) was set to the Basic Secure Site CA certificate, not the ECA-1 External CA certificate. While the BRs do not actually mandate the inclusion of the CA-Issuers URI, providing an incorrect value is certainly a mis-issuance. When TrustCor CA created the new certificate profiles for the ECA-1 example hierarchy, the profile QA tool previously only verified that the CA issuers URI point to a valid TrustCor CA certificate. Certificate profiles being copied from the test CA software are compared with the intended profiles for production as part of the QA process. Because the CA-Issuers URI is always different in test vs. production, and the test URI domain is different from production, the error was missed before the certificates were issued. 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. The profile QA tool has already been adjusted to ensure that the CA Issuers URI points to a certificate within the allowed set of issuing CAs for that profile. This should reduce the chances of this error occurring again. Note that a profile could contain multiple potential CAs (TrustCor CA's configuration is not so configured, but the EJBCA software does permit such an arrangement). We have updated our process to include an extra validation step, by Internal QA, to confirm that the URI path for CA Issuers is identical between testing and production platforms. We are confident that this misconfiguration will be caught at testing time, rather than slip into production again. Additionally, we will implement a new check to improve our certificate sanity process, before any certificate is signed by a trusted key, to alert on a misconfiguration of the URI path. We anticipate that this code will be in production by 2019-08-31.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
