Neil, Thank you for posting this detailed incident report. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1568356 to track this issue and I have no questions at this time.
- Wayne On Tue, Jul 23, 2019 at 10:20 AM Neil Dunbar via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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. > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
