Closed Bug 1996857 Opened 2 months ago Closed 1 month ago

IZENPE: not allowed Key Usage in ocsp responder certificate

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: d-fernandez, Assigned: d-fernandez)

Details

(Whiteboard: [close on 2025-12-08] [ca-compliance] [ocsp-failure])

Attachments

(4 files)

1.74 KB, application/x-x509-ca-cert
Details
1.70 KB, application/x-x509-ca-cert
Details
1.45 KB, application/x-x509-ca-cert
Details
1.47 KB, application/x-x509-ca-cert
Details

Full Incident Report

Summary

  • CA Owner CCADB unique ID:
    Izenpe S.A. : A000037

  • Incident description:
    One of the task of bug 1976256 was an exhaustive review of all the profiles defined in the BRs that applied to our PKI.
    During this review we have found that the ocsp responder certificates for our DV/OV and EV certificates, do not comply with the profile defined in the BRs.
    As it is set on the section 7.1.2.8.7 OCSP Responder Key Usage the only available Key Usage is "digitalSignature"
    but our ocsp signing certificates do also include the "nonRepudiation" key usage.

  • Timeline summary:

    • Non-compliance start date:

    2023-09-15 BR revision·2.0.0

    • Non-compliance identified date:

    2025-10-28

    • Non-compliance end date:

    2025-10-21 the new ocsp responders were issued and start signing ocsp responses.

  • Relevant policies:

    CabForum BRs 7.1.2.8.7 OCSP Responder Key Usage

  • Source of incident disclosure:

    Self Reported.

Impact

  • Total number of certificates:
    N/A

  • Total number of "remaining valid" certificates:
    N/A

  • Affected certificate types:

    OCSP responder certificates for DV/OV and EV certificates.

  • Incident heuristic:
    N/A

  • Was issuance stopped in response to this incident, and why or why not?:

    The issuance was not stopped as final certificates were not affected.

  • Analysis:
    N/A

  • Additional considerations:

Timeline

2023-03-15 BR 2.0.0 passed
2023-08-08 1 year ocsp signing certificate for EV certificates and with serial number 1852942833eb07a664d211fdc0e521a5 was issued.
2023-08-08 1 year ocsp signing certificate for DV/EV certificates and with serial number 76c8e5262851754864d1ff07448aa4bf was issued	.
2023-09-15 BR 2.0.0 in effect. The ocsp responder profile was set and the only key usage allowd was "digitalSignature".
2024-06-17 1 year ocsp signing certificate for EV certificates and with serial number 45db8e9b945df78066979e3a9e6f9137 was issued.
2024-06-17 1 year ocsp signing certificate for DV/EV certificates and with serial number DV/OV 3cd3a5b6a1e92ef166975aa032d34c62 issued.
2025-06-24 1 year ocsp signing certificate for EV certificates and with serial number EV 591be7bd8c6160685acd111f0d454d was issued.
2025-06-26 1 year ocsp signing certificate for DV/EV certificates and with serial number DV/OV 41073297370187cb685cde7fb33cd7dd was issued.
2025-10-28 problem with ocsp certificates responder detected.
2025-10-30 new certificate for ocsp responders will be issued.

Related Incidents

Bug Date Description
1976256 2025-08-07 One of the action items was to analyze other BR profiles used by Izenpe PKI.

Root Cause Analysis

Contributing Factor #1: BR change unnoticed

  • Description:
    Izenpe's ocsp responder profile for all the subCAs has kept the "nonRepudiation" key usage since the begining. When the change was introduced in the BRs we did not realize about this change.
  • Timeline:
    2023-09-15 Change in the ocsp responder profile come into force.
    2025-10-28 problem with ocsp certificates responder detected.
    2025-10-30 New ocsp responder certificate will be issued.
  • Detection:
    Pkimetal has been introduce in our infraestructure in the preissuance phase, but it still has not been applied to other elements such as ocsp responders. Running it on these certificates has raised the error.
  • Interaction with other factors:
  • Root Cause Analysis methodology used:

Lessons Learned

  • What went well:
    The development of the lintings tools has helped a lot detecting on time issues related to certificate compliance and thus we have detected this issue.
    In this occasion, no final TLS certificate has been affected and thus, no revocation is needed. The fixing requires only a new issuance of the ocsp responder certificate with the key usage changed.
  • What didn’t go well:
    Since the BR with the ocsp responder profile was changed, this problem has gone unnoticed for 2 years. Two certificates for each ocsp responder have been issued with the same problem since the BR applied.
  • Where we got lucky:
    Fixing the problem is easy and can be done in a short time.
  • Additional:

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Issue a new ocsp responder for each subCA Prevent #1: BR change unnoticed Once issued, it will be attached 2025-10-30 Ongoing
Placing ocsp responders on Izenpe web page and monitor them Mitigate #1: BR change unnoticed Once uploaded, the link will be provided and the monitoring test will be included 2025-11-14 Ongoing
Attached file ocsp_dv_ov.pem.cer
Attached file ocsp_ev.pem.cer
Assignee: nobody → d-fernandez
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [ocsp-failure]

Thanks for the incident report, David.
I am interested in why you think the BR change went unnoticed. What is Izenpe's process for triaging new ballots and why do you think the new requirements were missed to begin with? The action items don't seem to address the general case.

Hi James,
First of all, thanks for your comments.
This incident cames as a result of bug 1976256 where another "unnoticed" change arised. One of the action item was to review all the profiles set on the BR that could affect to our PKI and in this review we have seen the problem.
When BR2.0.0 applied we failed to detect the profiles changes (and no evidence of any triage was recorded) and we had to revoke a lot of certificates ( bug 1876565). Since then, we started registering all the Ballots and monitoring the final certificates, but we missed to do the same with crls, ocsp responders certificates and ocsp responses until now.
Regards

Hi,
the 2 new and corrected ocsp responder certificates have been issued and will start signing ocsp requests the next week.
Regards,

On 2025-11-24 at 16:00 the new ocsp responder certificates have started signing ocsp responses.

Report Closure Summary

  • Incident description:

    Izenpe ocsp signing certificates included the "nonRepudiation" key usage extension when the only one allowed is "digitalSignature" since BR 2.0.0.

  • Incident Root Cause(s):

    When BR2.0.0 came into effect Izenpe did not perform an exhaustive profiles review. When Bug 1976256 arised, one of the action items was to review all the profiles that Izenpe used. In this review, when ocsp signing certificates were analyzed we detected the incorrect key usage extension and opened this BUG.

  • Remediation description:

    A new ocsp signing certificate was issued according to the BR profiles and it was configured to start signing ocsp responses.

  • Commitment summary:

    Similarly to Bug 1976256, all the profiles defined in the BRs and used by Izenpe are now continously monitorized by Izenpe and to prevent unnoticed changes in the BR's, everytime a new ballot is passed, it will be recorded in our ticketing tool and therefore checked that it has or not any impact on us.

All Action Items disclosed in this report have been completed as described, and we request its closure.

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-12-08.

Flags: needinfo?(incident-reporting)
Whiteboard: [ca-compliance] [ocsp-failure] → [close on 2025-12-08] [ca-compliance] [ocsp-failure]
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Flags: needinfo?(incident-reporting)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: