IdenTrust: Issuance of Subordinate CA’s Without EKU

IdenTrust reported that, during a final review before production deployment, it discovered that two subordinate CA certificates issued from its DST Root CA X3 on September 30, 2020 were missing the required EKU extension required by BR 1.7.2, section 7.1.2.2g. IdenTrust stated it had stopped issuing certificates from those two subordinate CA certificates and that zero production end-entity certificates were issued from them. The CA obtained approval to revoke/re-issue, created new subordinate certificates including the EKU extension, and revoked the two mis-issued subordinate CA certificates. IdenTrust also updated Mozilla’s CCADB records accordingly. In the thread, Mozilla asked for more specificity about procedural controls, and IdenTrust provided details of its compliance validation controls and how they were tightened for new, renewed, or replaced subordinate CA certificates. Mozilla indicated no further questions and stated the matter could be closed on 27-Jan-2021 unless additional comments were raised. The bug is marked RESOLVED with resolution FIXED.

1. 2020-09-30 IdenTrust issued two subordinate CA certificates from DST Root CA X3 that were missing the required EKU extension.
2. 2020-10-06 IdenTrust discovered the missing EKU issue during a final review before production deployment.
3. 2020-10-07 IdenTrust created new subordinate CA certificates including the EKU extension and revoked the two mis-issued subordinate CA certificates.
4. 2020-10-16 IdenTrust added the incident report to the bug.
5. 2021-01-27 Mozilla planned to close the matter unless there were additional comments or areas to explore.

1. 2020-10-06 IdenTrust Services, LLC — IdenTrust stated it discovered two subordinate CAs issued from DST Root CA X3 were missing required EKU extensions and said remediation was being planned and executed, with an incident report to follow.
2. 2020-10-15 Mm representative — A third party asked whether the referenced intermediate certificate lacking EKU was one of the two certificates mentioned and questioned why an incident report had not yet been provided.
3. 2020-10-15 IdenTrust Services, LLC — IdenTrust confirmed the certificate was one of the two and provided the other crt.sh reference, stating an incident report would be supplied by October 16, 2016.
4. 2020-10-16 IdenTrust Services, LLC — IdenTrust provided the incident report details, including how it became aware, a timeline, that issuance was stopped, revocation actions, and an explanation of how the mistakes occurred.
5. 2020-10-17 Community commenter — Mozilla asked for more specificity about procedural controls and requested detailed information about existing and current controls.
6. 2020-10-23 IdenTrust Services, LLC — IdenTrust described its compliance validation controls and noted updates to make profile review stricter for new, renewed, or replaced subordinate CAs.
7. 2020-10-26 Mozilla representative — Mozilla stated it had no other questions at that time.
8. 2021-01-22 Mozilla representative — Mozilla suggested wording changes related to CCADB updates and noted a side note about notice-and-approval for new external CA operators.
9. 2021-01-22 IdenTrust Services, LLC — IdenTrust agreed and stated its process includes a second pair of eyes reviewing CCADB updates via a screen-sharing session.
10. 2021-01-22 Mozilla representative — Mozilla said the matter could be closed next Wednesday (27-Jan-2021) unless there were other comments or areas to explore.