HARICA issued Server TLS certificates with clientAuth EKU contrary to its CP/CPS, then corrected the profiles and CP/CPS

HARICA reported 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 arose because HARICA’s CP/CPS still reflected an outdated 2026-06-15 cutoff, while Chrome’s Root Store 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, and HARICA later posted a full incident report with the timeline and impact details. The bug remains assigned to HARICA, and HARICA said it is monitoring the bug for further questions while requesting that the next update be deferred until 2026-09-18.

1. 2025-03-14 HARICA updated CP/CPS v4.9 to incorporate the then-current deadline for removing `id-kp-clientAuth` from TLS certificates.
2. 2026-06-15 HARICA’s CP/CPS cutoff for allowing `id-kp-clientAuth` in TLS certificates took effect.
3. 2026-07-15 HARICA received a report about the inconsistency between its CP/CPS and actual TLS certificates.
4. 2026-07-15 HARICA stopped issuance and updated the TLS certificate profiles.
5. 2026-07-16 HARICA published CP/CPS v4.13 with corrected language for the `clientAuth` EKU.
6. 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, said it had 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 reported that the HARICA-GEANT-TLS-R1 CRL showed at least one affected certificate as revoked.
5. 2026-07-24 HARICA — HARICA said the draft incident report sections on 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.