2051459 - NETLOCK: OCSP Service Returning Error for Issued Certificate; Failure to Respond to Certificate Problem Report Within 24 Hours

Status: UNCONFIRMED

(CA Program :: CA Certificate Compliance, task)

Description

[Ophelia P.]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

Preliminary Incident Report

Summary

• Incident description: Two compliance failures have been identified
  involving NETLOCK (NetLock Kft.):

  1. OCSP Availability Failure

  NETLOCK's OCSP service returned "OCSP responder does not know this
  certificate" for a certificate it issued: crt.sh ID
  15228019987 (Cert Spotter issuance
  15228019987,
  issuer ID 215347). This was detected via
  OCSP Watch and had been ongoing
  for over 10 days as of 2026-06-16T00:13:25+00:00. The error appears to
  have since been silently resolved; NETLOCK has provided no communication
  explaining the cause, scope, or remediation of the failure.

  2. Failure to Acknowledge or Investigate a Certificate Problem Report
  Within 24 Hours

  A Certificate Problem Report (CPR) was submitted to NETLOCK's
  CCADB-disclosed problem reporting address ([e-mail])
  on 2026-06-10 at 23:48 UTC, referencing the above OCSP error and
  linking directly to the affected certificate issuance. A follow-up was
  sent on 2026-06-16 to the same address, additionally CC'ing
  [e-mail], also disclosed to the CCADB.

  NETLOCK did not acknowledge either CPR within the required 24 hours. An
  automated acknowledgment was received on 2026-06-24 (14 days after
  initial submission), assigning case ID 01206157. The
  first substantive - but entirely inadequate - response arrived on
  2026-06-26 at approximately 08:57 UTC (16 days after the initial
  CPR), consisting solely of the question "Which certificate is
  affected?", indicating no meaningful investigation had occurred and seemingly no (i.) awareness of or (ii.) effort to consider the earlier reports.

  As of submitting this ticket, no resolution or further communication has been
  received.

• Relevant policies:

  • TBR, Section 4.9.5
  • TBR, Section 4.9.9
  • MSRP, Section 5.4 (presumed)

• Source of incident disclosure: Third Party Reported

Note: This report covers two distinct compliance failures. NETLOCK should wish to file separate Full Incident Reports addressing each root cause independently.

Comment 1

[Roland]

Full Incident Report

Scope note (please read first). Bugzilla bug #2051459, as filed by the third‑party reporter, describes two distinct compliance failures: (1) NETLOCK's OCSP responder returning an "unknown" status for a certificate NETLOCK had validly issued, and (2) NETLOCK's failure to acknowledge/respond to the related Certificate Problem Report (CPR) within 24 hours. Because these have distinct root causes and distinct remediations, and consistent with the CCADB guidance that a separate report is warranted when "another incident with a distinct root cause and/or remediation is discovered," this Full Incident Report addresses ONLY compliance failure (1) — the OCSP responder issue. The CPR response‑time failure (2) is addressed in a separate Full Incident Report (2052541).

Summary

• CA Owner CCADB unique ID: A000039
• Incident description: On 2026‑06‑05, NETLOCK (NetLock Kft.) issued a publicly‑trusted TLS server certificate for nsi.netlock.hu (crt.sh ID 15228019987; issuing CA ID 215347). The newly issued certificate was not propagated to NETLOCK's OCSP responder infrastructure. As a result the responder had no record of the serial number and returned an "unknown" status — per RFC 6960 §2.2, "the responder doesn't know about the certificate being requested" — for a certificate that NETLOCK had in fact validly issued and whose Authority Information Access (AIA) extension referenced that same responder. Relying parties querying the certificate's revocation status therefore received a non‑definitive "unknown" response instead of the required "good" status. The condition persisted from issuance until the responder was resynchronised. This report covers only this OCSP availability/correctness failure (see scope note above).
• Timeline summary:
  • Non‑compliance start date: 2026‑06‑05 14:06:52 UTC
  • Non‑compliance identified date: 2026‑06‑16 20:12:31 UTC (identified by NETLOCK through its monitoring‑analysis activities)
  • Non‑compliance end date: 2026‑06‑17 02:41:10 UTC
• Relevant policies:
  • CA/Browser Forum TLS Baseline Requirements (Baseline Requirements for the Issuance and Management of Publicly‑Trusted TLS Server Certificates), §4.9.9 "On‑line revocation/status checking availability" and §4.9.10 "On‑line revocation checking requirements" — version in force on 2026‑06‑05 (NETLOCK to confirm the exact version number, e.g., v2.x). While the operation of an OCSP responder is optional under the current TLS BR, where a CA operates a responder and references it in the AIA of its issued certificates, the responder MUST return accurate, RFC 6960‑conformant status for those certificates.
  • RFC 6960 §2.2 (definition and correct use of the "good"/"revoked"/"unknown" certificate status values).
  • NETLOCK CP/CPS — the OCSP/certificate‑status‑service commitments in NETLOCK's applicable Certification Practice Statement (NETLOCK to insert the exact document and section reference, e.g., SPS‑QC §4.9.9/§4.9.10).
• Source of incident disclosure: Third Party Reported

Impact

• Total number of certificates: N/A. This is an OCSP response availability/correctness incident, not a certificate mis‑issuance. No certificate was mis‑issued and no certificate requires revocation as a consequence of this incident. The single certificate whose OCSP status was served incorrectly was itself validly issued.
• Total number of "remaining valid" certificates: N/A. There is no corpus of mis‑issued or revocable certificates arising from this incident.
• Affected certificate types: N/A. The incident concerns the OCSP response served for a single, already‑validly‑issued certificate rather than a class of certificates defined by CA/Browser Forum policy OIDs (DV/IV/OV/EV).
• Incident heuristic: N/A. The incident affected the OCSP responses served for one specific, identified certificate (crt.sh ID 15228019987); it is not a corpus that a third party would need to assemble via a heuristic.
• Was issuance stopped in response to this incident, and why or why not?: No. The root cause was a failure to propagate an issued certificate to the OCSP responder, not a defect in the certificate issuance process or certificate profile. Halting issuance would not have remediated the OCSP synchronisation gap and was not warranted. The condition was remediated directly by resynchronising the responder (see Timeline).
• Analysis: For the duration of the incident (2026‑06‑05 14:06:52 UTC to 2026‑06‑17 02:41:10 UTC, i.e., approximately 11 days) a relying party performing an OCSP lookup for nsi.netlock.hu would have received an "unknown" status rather than a definitive "good" status. Under RFC 6960, an "unknown" status is not equivalent to "revoked": it signals only that the responder could not determine the status, allowing the client to fall back to another status source (e.g., a CRL). Because most current browsers soft‑fail on inconclusive OCSP responses, the practical impact on end users is expected to have been limited; NETLOCK does not rely on this soft‑fail behaviour to characterise the incident as harmless, and treats it as a genuine compliance failure. A one‑time reconciliation sweep of currently‑valid certificates against the OCSP responder is included as an Action Item to confirm that no other certificate was similarly affected.
• Additional considerations: The affected certificate (nsi.netlock.hu) is a certificate used for NETLOCK's own service infrastructure. This does not reduce NETLOCK's obligation to serve correct revocation status for every certificate whose AIA references its responder.

Timeline

All times are in UTC.

Date/Time (UTC)	Event
2026‑06‑05 14:06:52	Certificate for nsi.netlock.hu issued (crt.sh ID 15228019987). The automated pipeline expected to propagate the newly issued certificate/serial to the OCSP responder did not trigger for this certificate; the responder holds no record of the serial. Non‑compliance begins — the responder returns "unknown" for the certificate's serial from this point.
2026‑06‑10 23:48	A Certificate Problem Report referencing this OCSP error is received at NETLOCK's CCADB‑disclosed problem‑reporting address. (The acknowledgement/response‑timeliness handling of this CPR is a distinct compliance failure addressed in the separate Full Incident Report — see Related Incidents.)
2026‑06‑16 ~00:13	SSLMate OCSP Watch flags NETLOCK's responder as not serving a valid/expected OCSP response for the certificate.
2026‑06‑16 20:12:31	NETLOCK identifies the OCSP responder non‑compliance through its monitoring‑analysis activities.
2026‑06‑17 02:41:10	OCSP responder resynchronised for the affected certificate; the responder returns the correct status. Non‑compliance ends.

Related Incidents

The following incidents disclosed to the CA Certificate Compliance Bugzilla component (spanning the last two years, and including a directly on‑point older example) concern OCSP responders that failed to serve correct/available status for certificates whose AIA referenced them — the same class of issue as this incident.

Bug	Date	Description
Bug #2051459	2026‑06‑28	The same Bugzilla bug as this report. In addition to the OCSP failure that is the subject of this report, the bug also documents NETLOCK's failure to acknowledge/respond to the related Certificate Problem Report within 24 hours — a distinct compliance failure with a distinct root cause and remediation, addressed in a separate NETLOCK Full Incident Report (link/bug ID to be inserted once filed).
Bug #2046230	2026‑06‑09	certSIGN — inconsistent revocation status between CRL ("revoked") and OCSP ("good") for an intermediate CA. Directly parallel to this incident: the responder was out of sync with the CA's authoritative status, certSIGN's monitoring did not correlate CRL/OCSP consistency, the issue was surfaced by an external reporter rather than internal controls, and it was remediated within the 24‑hour window.
Bug #1991196	2025‑09‑25	Sectigo — OCSP, caIssuers and CRL endpoints became unavailable for a single subordinate CA (an expired/lost domain). Like this incident, Sectigo was alerted by SSLMate's OCSP Watch rather than by internal monitoring.
Bug #1882904	2024‑03‑01	Google Trust Services — OCSP responders returned "unauthorized" for some requests because status information for recently issued intermediate CAs was not correctly propagated to the responder. Same class of issuance‑to‑responder propagation/synchronisation gap.
Bug #1793443	2022‑10‑03	Microsoft PKI Services — issued certificates were not published to the OCSP responder, so the responder returned "unknown" for validly issued certificates. This is the closest substantive precedent to the present incident: an issuance‑to‑OCSP propagation gap producing a non‑definitive status for validly issued certificates, detected only after the fact.

Root Cause Analysis

Contributing Factor 1: Certificate issuance not integrated with the automated OCSP responder update process

• Description: The certificate for nsi.netlock.hu, issued on 2026‑06‑05 at 14:06:52 UTC, was not automatically propagated to the OCSP responder infrastructure. The automated pipeline expected to update the responder's configuration/data upon certificate issuance did not trigger for this certificate, leaving the OCSP responder unaware of the newly issued serial. Consequently the responder returned "unknown" instead of "good" for the certificate.
• Timeline: The gap existed from issuance (2026‑06‑05 14:06:52 UTC) and persisted until resynchronisation of the responder on 2026‑06‑17 02:41:10 UTC.
• Detection: The condition was surfaced on 2026‑06‑16 and identified by NETLOCK through its monitoring‑analysis activities at 20:12:31 UTC the same day. It was not caught by a dedicated automated internal control at or shortly after issuance; the same day, an external OCSP Watch (SSLMate) signal also flagged the responder.
• Interaction with other factors: This is the primary/root contributing factor. The extended time to detect (Contributing Factor 2) stems directly from the absence of internal automated verification of this propagation step.
• Root Cause Analysis methodology used: 5 Whys (why "unknown"? → responder had no record of the serial → serial not propagated to the responder → the issuance‑to‑responder propagation step did not run for this certificate → issuance and responder update are not integrated into a single, verified transaction).

Contributing Factor 2: No dedicated internal monitoring for OCSP responder synchronisation gaps

• Description: No dedicated automated alerting mechanism existed to detect a mismatch between a newly issued certificate and the corresponding OCSP responder update. As a result, the gap between issuance (2026‑06‑05) and remediation (2026‑06‑17) — approximately 11 days — was not caught promptly by a purpose‑built internal control; it was ultimately surfaced through NETLOCK's monitoring‑analysis activities (which review available signals, including the external OCSP Watch service) rather than by a dedicated OCSP‑synchronisation alert.
• Timeline: The monitoring gap pre‑existed the incident and allowed the Contributing Factor 1 condition to persist undetected for approximately 11 days.
• Detection: Surfaced on 2026‑06‑16 via NETLOCK's monitoring‑analysis review (external OCSP Watch signal on the same day); no dedicated automated internal OCSP‑synchronisation alert was in place.
• Interaction with other factors: Directly compounds Contributing Factor 1. Without a dedicated internal OCSP‑synchronisation alert, the exposure window was extended until the condition was surfaced through monitoring analysis.
• Root Cause Analysis methodology used: Fishbone / cause‑and‑effect (categorising the absence of a "Detect" control that should have compared expected vs. served OCSP status for issued certificates).

Lessons Learned

• What went well:
  • Once the condition was surfaced (2026‑06‑16), NETLOCK identified it via monitoring analysis on the same day and completed remediation within approximately 6.5 hours of identification (by 2026‑06‑17 02:41:10 UTC).
  • The condition was correctly characterised as an OCSP synchronisation gap affecting a single certificate, allowing a targeted fix.
• What didn't go well:
  • Certificate issuance was not integrated with the automated OCSP responder update, allowing a newly issued certificate to be absent from the responder (Contributing Factor 1). (→ Action Items 1, 2, 6)
  • No dedicated internal monitoring existed to detect OCSP responder synchronisation gaps, so the condition persisted for approximately 11 days (Contributing Factor 2). (→ Action Items 3, 4)
  • The condition was surfaced through monitoring analysis of an external signal (OCSP Watch) rather than by a purpose‑built internal control. (→ Action Items 3, 4)
• Where we got lucky:
  • An external monitoring service (OCSP Watch) independently flagged the condition on the same day; NETLOCK cannot rely on external parties for future detection. (→ Action Items 3, 4)
  • Only a single certificate was affected, limiting the scope. This cannot be relied upon; a reconciliation sweep is included to confirm no other certificate was affected. (→ Action Item 6)
• Additional: Prevailing browser soft‑fail behaviour on inconclusive OCSP responses likely limited real‑world relying‑party impact, but this is outside NETLOCK's control and is not treated as mitigation of the compliance failure.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
1. Implement a dedicated, continuous internal OCSP monitoring/alerting control that periodically samples issued certificates and compares expected vs. served status, so synchronisation gaps are detected internally rather than by third parties.	Detect	Contributing Factor 2	Mean time to detect an OCSP synchronisation gap reduced to < N hours; alerting demonstrated by injecting a synthetic gap in a test environment.	2026‑09‑30 (proposed)	Ongoing
2. Integrate external OCSP Watch (SSLMate) alerts into NETLOCK's operational on‑call alerting as a defense‑in‑depth backstop, with a documented runbook.	Detect / Mitigate	Contributing Factor 2	OCSP Watch alerts routed to on‑call within minutes; runbook published internally and exercised.	2026‑08‑15 (proposed)	Ongoing
3. Immediate remediation: resynchronise the OCSP responder for the affected certificate.	Mitigate	Contributing Factor 1	Responder returns "good" for the affected certificate, verifiable via crt.sh / independent external OCSP query.	2026‑06‑17	Complete
4. One‑time reconciliation sweep of all currently‑valid issued certificates against the OCSP responder to confirm no other certificate is missing from the responder.	Detect	Contributing Factor 1, Contributing Factor 2	100% of currently‑valid certificates return "good" via OCSP; the number of any discrepancies found and remediated is reported in an update to this incident.	2026‑07‑31 (proposed)	Ongoing

Appendix

N/A. This incident did not result in any mis‑issued or revocable certificate; there is no certificate corpus to disclose. The single certificate whose OCSP status was served incorrectly is identified in the incident narrative above (crt.sh ID 15228019987).

Comment 2

[Ophelia P.]

NETLOCK's incident report for this bug was provided approximately 88 hours after this bug was opened, missing the 72-hour window required by the CCADB Incident Reporting Guidelines. Of course, they were made aware of their shortcomings long before this report was opened. A failure to provide a timely initial disclosure is itself a compliance violation. NETLOCK should file a separate incident report, what would be its 42nd all-time (!), detailing the timeline of this reporting failure, its root cause, and specific, verifiable remediation items to ensure future disclosures are timely.

Noteworthy, this is not an isolated lapse. Bug #2013400 documents the same failure within the past few months. A CA that has now missed the initial disclosure window in back-to-back incidents has not internalized the obligation, it has demonstrated that its process does not reliably produce compliant behavior under any circumstances. Or, perhaps it just doesn't want to.

This is also the third instance in roughly two years in which NETLOCK has failed to respond to a Certificate Problem Report within the required 24 hours, following the failures documented in Bug #1905509 and Bug #1906115. The CPR mechanism is a fundamental pillar of ecosystem security. Repeated failure to staff and operate it is not an administrative inconvenience - it is a failure of one of the most basic obligations of a publicly trusted CA.

NETLOCK's compliance record in this component now spans 41 bugs over roughly nine years. What makes this particularly striking is that NETLOCK appears to operate at very, very small issuance scale, primarily issuing certificates within its own organizational footprint. This volume of compliance failures is not the result of a CA struggling to manage global operational complexity. It is a CA failing to execute basic operational and communicative obligations within a tightly contained scope. Scale cannot be offered as a mitigating factor here - and the absence of scale makes the failures harder to explain, not easier.

In Bug #1586795 (2019), SIX years ago, Ryan Sleevi recommended that Mozilla consider adding NETLOCK to OneCRL due to sustained non-responsiveness. In Bug #1716874 (2021), he stated that NETLOCK "has failed to meet the BRs and failed to meet the requirements of multiple root programs" and that it "appears to have intentionally chosen not to follow them." In Bug #1680378 (2020), he expressed deep reservations about NETLOCK's ability and skills for compliance. The patterns these bugs describe are present today - and worse - are not improving.