HARICA reported and remediated a CP/CPS mismatch that allowed TLS certificates to keep clientAuth EKU past the documented deadline

HARICA disclosed that it issued Server TLS certificates containing the `id-kp-clientAuth` KeyPurposeID after the removal deadline stated in its own CP/CPS. The thread says the mismatch existed because HARICA’s CP/CPS still reflected an outdated 2026-06-15 cutoff even though Chrome Root Program Policy had moved the applicable deadline to 2027-03-15. HARICA said it halted issuance, updated the affected TLS certificate profiles, and later published a corrected CP/CPS. The incident was first reported by a third party, but HARICA itself opened the bug and posted the preliminary and full incident reports. In later updates, HARICA said action items 2 and 3 were completed on time, while action item 1 remained ongoing, and it requested the next update be set for 2026-10-30.

1. 2025-02-15 Chrome Root Store Policy v1.6 required removal of `id-kp-clientAuth` from TLS certificates, effective 2026-06-15 for existing CAs.
2. 2025-03-14 HARICA updated its CP/CPS v4.9 to incorporate the 2026-06-15 deadline.
3. 2026-06-15 HARICA’s TLS profiles still included `clientAuth` EKU after the CP/CPS deadline had taken effect.
4. 2026-07-15 HARICA received a report about the inconsistency between its CP/CPS and actual TLS certificates.
5. 2026-07-15 HARICA halted issuance and began emergency profile changes.
6. 2026-07-16 HARICA published CP/CPS v4.13 with corrected language for the `clientAuth` EKU.
7. 2026-07-31 HARICA posted the full incident report.

1. 2026-07-16 HARICA — HARICA filed a preliminary incident report saying it had continued issuing TLS certificates with `id-kp-clientAuth` after its CP/CPS cutoff and would replace and revoke affected certificates within 5 days.
2. 2026-07-17 Google representative — Chrome Root Program asked HARICA to answer detailed questions about the controls that should have prevented or detected the misissuance sooner.
3. 2026-07-20 HARICA — HARICA acknowledged the issue, confirmed the CP/CPS language problem, halted issuance, and said a bug would be registered within 24 hours.
4. 2026-07-21 Molgen representative — A Mozilla participant noted that the HARICA-GEANT-TLS-R1 CRL showed at least one affected certificate as revoked.
5. 2026-07-24 HARICA — HARICA said the summary, impact, timeline, related incidents, and appendix were complete, while root cause analysis, lessons learned, and action items were still under analysis.
6. 2026-07-30 HARICA — HARICA said it needed one more day to post the final root cause analysis, lessons learned, and action items, and noted the report was being aligned with bug 2056668.
7. 2026-07-31 HARICA — HARICA posted the full incident report, including the updated timeline and the explanation that the non-compliance ended when the TLS profiles were corrected.
8. 2026-08-06 HARICA — HARICA clarified that the timeline wording about enabling clientAuth EKU was a typographical error and that the profiles were updated to remove the TLS client auth EKU.
9. 2026-08-14 HARICA — HARICA said it had no new updates and requested deferring the next update until 2026-09-18.
10. 2026-09-20 HARICA — HARICA said action items 2 and 3 were on track and requested the next update be set to 2026-10-03.
11. 2026-10-02 HARICA — HARICA said action items 2 and 3 were completed on time and provided a status update showing action item 1 ongoing.