2051459 - NETLOCK: OCSP Service Returning Error for Issued Certificate

Status: ASSIGNED

(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.

Comment 3

[Janos | Netlock]

Thank you for the detailed feedback. We'd like to clarify a few factual points regarding the reporting timelines and the notification channel question raised above.

On the alleged 72-hour non-response
The matter concerning our failure to respond within the required window is already being tracked separately in Bug #2052541, and we will provide the full timeline, root cause, and remediation there rather than duplicating it here.

We want to flag one additional fact relevant to that ticket: we became aware that a bug related to NETLOCK existed at all only through our own routine periodic review process — not through any direct notification, assignment, or routing to our team. As of the time of writing this comment, that ticket is still not assigned to us. However, once we identified it through our own regular review, we responded within 24 hours. We raise the assignment point not to dispute that a response was owed, but because it is directly relevant to any timeline analysis of when NETLOCK could reasonably be expected to have known about and acted on the matter. We will lay this out in full, with exact timestamps, in Bug #2052541 itself.

On the CPR 24-hour response (present incident)
Separately, and relevant to the broader pattern concern raised above: during our routine weekly ticket review (conducted Thursdays), we identified that a different ticket had been created that was not assigned to our team queue. Once identified through this review, we responded to it within 24 hours as well. This demonstrates that where our process is correctly triggered — even via a routine periodic check rather than a real-time alert — it does operate as intended. The gap in that instance was in initial routing/assignment, not in our response capability once the item was on our radar.

On the notification channel
As noted previously, the underlying report does not appear to have reached us through the designated Certificate Problem Report contact channels published in our CP/CPS and CCADB record. We are separately investigating whether a related email was misdirected or filtered (e.g., as spam) rather than reaching the monitored CPR inbox; that specific investigation is being handled in the bug already opened for the spam-related email issue, and we will report findings there rather than here, to keep the two matters distinct.

Commitment
What we want the record to reflect is that in both cases referenced above, once NETLOCK actually became aware of the matter — through our own regular review process, in the absence of any assignment or direct notification — we responded within the required 24-hour window. We raise this because an accurate timeline of actual awareness is the correct basis for evaluating our response, and because the recurring nature of these routing/assignment gaps is itself something we intend to fix structurally, not explain away case by case. We will file full, timestamped timelines in Bug #2052541 and in the spam-email bug, with root cause analysis and concrete, verifiable action items — including whether Bugzilla ticket assignment/notification for our component needs a dedicated internal safeguard so we no longer depend on periodic manual review to discover that a ticket concerning us exists at all.

Comment 4

[erakura]

We want to flag one additional fact relevant to that ticket: we became aware that a bug related to NETLOCK existed at all only through our own routine periodic review process — not through any direct notification, assignment, or routing to our team. As of the time of writing this comment, that ticket is still not assigned to us. However, once we identified it through our own regular review, we responded within 24 hours. We raise the assignment point not to dispute that a response was owed, but because it is directly relevant to any timeline analysis of when NETLOCK could reasonably be expected to have known about and acted on the matter.

NETLOCK’s clarification about Bugzilla assignment might be relevant as a factual timeline detail, but it should not be framed as mitigation of the compliance failure. A publicly trusted CA is responsible for ensuring that reports concerning its operations are detected, triaged, and acted upon within the required timeframes, whether signals arrive through a disclosed CPR address, Bugzilla, external monitoring, or another public channel. In this case, as disclosed in bug 2052541, the missed response window appears to have resulted from NETLOCK-controlled processes: spam filtering of the disclosed CPR address, failure to escalate reports received through secondary channels, and reliance on periodic manual review to discover relevant Bugzilla activity. Those are internal control failures, not community or Bugzilla maintainer failures.

Comment 5

[Dustin Hollenback (Apple)]

NETLOCK's Full Incident Report in bug 2052541 is, in most respects, the kind of report the CCADB Incident Reporting Guidelines ask for. It measures the 24-hour clock from receipt of the Certificate Problem Report, accepts the failure, identifies concrete root causes, and commits to fixes.

However, in Comment 3 of this bug, NETLOCK argues that "an accurate timeline of actual awareness is the correct basis for evaluating our response," on the grounds that the report did not reach its compliance team because of spam filtering and mis-routing. Receipt, not internal awareness, is the correct basis. TLS BR 4.9.5 measures the 24-hour obligation from "receiving" a Certificate Problem Report, and 4.9.3 requires a continuous 24x7 ability to accept and respond to one. NETLOCK's own bug 2052541 report applies that receipt-based standard, which makes the awareness argument here hard to follow.

This distinction matters. NETLOCK's report states the real problem in its own words: "Spam filtering silently suppressed genuine CPRs on the primary problem-reporting address, with no monitoring or fallback to catch them." If "actual awareness" were the basis for judging a response, any CA whose intake silently drops reports could avoid the 24-hour obligation by never becoming aware. That is the outcome the receipt-based rule exists to prevent, and it should not be treated as acceptable.

As correctly raised in Comment 2, NETLOCK also did not provide a preliminary report within 72 hours. Its first report on this bug came about 86 hours after the bug was opened, and was still late even measured from the date NETLOCK says it became aware (2026-06-28, per bug 2052541). Comment 3 treats this as covered by the separate bug 2052541, but that report addresses only the 24-hour response failure, so the late disclosure has not actually been accounted for.

Additionally, for this bug, NETLOCK has already communicated that they were aware of the non-compliance on 2026-06-16 ("NETLOCK identifies the OCSP responder non‑compliance through its monitoring‑analysis activities."). There is no clarity on why NETLOCK did not open an issue within 72 hours as required by the IRGs.

Awareness-based framing has appeared before. NETLOCK made "time of first awareness" its authoritative reference time for deadlines in bug 2013400 Comment 8, and narrowed the Related Incidents requirement to its own operations in bug 2004699 Comment 9, which was corrected in Comment 10. Each may be small on their own. Together they suggest requirements being shaped around how NETLOCK prefers to operate, rather than what the Guidelines require.

A response consistent with the CCADB Incident Reporting Guidelines would:

• confirm that the 24-hour obligation runs from receipt of a report, not only from internal awareness, as bug 2052541 already does;
• address the missed 72-hour preliminary report as its own matter, not as part of the 24-hour report; and
• adequately explain in that new 72-hour bug why this bug's Timeline states that NETLOCK was aware of non-compliance on 2026-06-16, yet this bug was not opened until 2026-06-29.

Comment 6

[Ophelia P.]

A few responses to Comment 3.

1 - NETLOCK states it "became aware that a bug related to NETLOCK existed at all only through our own routine periodic review process - not through any direct notification, assignment, or routing to our team."

On June 26, 2026, I sent the following to [e-mail], one of NETLOCK's CCADB-disclosed problem reporting addresses: "This is my final attempt at reporting this issue. Next stop is a bugzilla ticket." This bug was opened on June 29. NETLOCK was explicitly told, three days before this bug existed, that it was coming. It was my sincere hope NETLOCK would disclose these issues independently. They did not.

The question of whether a Bugzilla ticket has been formally assigned to a CA cannot be the standard by which a CA's awareness is evaluated. A CA that has received multiple emails about an active compliance issue, been warned directly that a Bugzilla report is imminent, and then claims it only became aware of the resulting report through a periodic internal review, is describing a deeply concerning compliance problem, not offering a defense. There is no version of CA/Browser Forum or CCADB requirements that I am aware of that conditions a CA's obligation to respond on whether a Bugzilla moderator has clicked "assign." It seems some comments above agree with this point.

2 - NETLOCK states that "the underlying report does not appear to have reached us through the designated Certificate Problem Report contact channels published in our CP/CPS and CCADB record."

This claim is so wrong that it's shocking an actual human person employed by NETLOCK would make it.

The initial CPR was sent to [e-mail] on June 10, 2026. The follow-up was sent to both [e-mail] and [e-mail] on June 16, 2026. The CCADB AllProblemReportingMechanismsReport lists both of these addresses as NETLOCK's disclosed problem reporting mechanisms at the time of submission, and continues to do so at the time of this comment. NETLOCK's own disclosed addresses are, by definition, its designated CPR contact channels.

Further, [e-mail] also appears in NETLOCK's own policy documents, hosted here, here, here, and here.

The confidence with which NETLOCK makes a claim this straightforwardly contradicted by its own published documents raises a genuine concern: compliance functions at a publicly trusted CA must be staffed by people who know those documents, and know the facts of the incidents they are responding to. When a CA's compliance responses contain claims that are directly refuted by its own published record, the community is right to ask whether the humans responsible for those responses have the expertise the role requires. I suppose it might be possible that humans are not involved in this process.

3 - I should have caught this earlier, but Action Item 1 of the incident report includes the following evaluation criterion: "Mean time to detect an OCSP synchronisation gap reduced to < N hours." The letter N is not defined anywhere in the report. A compliance commitment where the target metric is literally a placeholder variable is not a commitment - it is a template that was not completed before filing. This is a small thing, but it is consistent with a broader pattern in NETLOCK's reporting: action items that sound structured but contain no measurable, verifiable, or time-bound specifics that would allow anyone outside NETLOCK to evaluate whether they have been met. It's also not clear hours is the appropriate scale.

Comment 7

[Janos | Netlock]

Response to Comments 4, 5, and 6
Thank you all for the continued scrutiny. We want to address these points directly, correct what needs correcting, and be precise about what we are and are not arguing.

1. On splitting this into two separate reports
We want to reaffirm why compliance failure (1) — the OCSP responder issue — and compliance failure (2) — the CPR response-time failure — are being tracked as two separate Full Incident Reports (this bug, and Bug #2052541, respectively). These have distinct root causes and distinct remediations. Consistent with CCADB guidance that a separate report is warranted when "another incident with a distinct root cause and/or remediation is discovered," we believe keeping these separate produces clearer, more verifiable root cause analysis and action items than merging them would. We are not splitting these to obscure the pattern between them — the cross-references between the two bugs are intentional and we will keep them tightly linked.

2. On [e-mail] and [e-mail]
Compliance.info@ is our designated general CPR intake address. The CPRs referenced in this bug were sent there and, as Bug #2052541 discloses, were silently suppressed by spam filtering on that mailbox rather than reaching the compliance team's inbox. We are not disputing that this address was the correct, designated channel, or that the reports were sent to it. Our earlier comment implying otherwise was incorrect, and we withdraw it.

Visszavonas@ is a functionally narrower mailbox, used operationally for revocation requests specifically; it is not staffed or triaged as a general compliance/CPR inbox. Messages sent there outside that specific function — including the June 26 message warning that a Bugzilla ticket was forthcoming — are not routed to compliance staff the way a compliance.info@ message would be. This does not excuse the outcome; it explains, factually, why a message to that address did not reach the people who needed to see it, in addition to the spam-filtering failure on compliance.info@.

Troubleshooting on both issues is already underway from multiple sides: mail filtering configuration and quarantine review on the infrastructure side, and mailbox scope/triage rules on the compliance-process side. We will report concrete findings, fixes, and verification steps — with real dates, not placeholders — in Bug #2052541.

3. On Bugzilla ticket assignment and awareness
We want to separate two distinct things that our earlier comments did not distinguish clearly enough, and which we believe is the actual source of the "double standard" concern raised above.

First: the 24-hour CPR response obligation under TLS BR §4.9.5 runs from receipt of the report, not from internal awareness. We are not disputing this, and Bug #2052541 applies exactly this standard — the non-compliance window there is measured from 2026-06-10 23:48 UTC, the moment the CPR was received at compliance.info@, not from any later date on which our compliance team subjectively became aware of it. On this point there is no departure from a receipt-based standard, and no ambiguity we intend to introduce.

Second, and separately: the question of when NETLOCK became aware that this Bugzilla ticket (Bug #2051459) existed at all is an administrative/operational fact about our own ticket-monitoring process — not our proposed standard for measuring any BR compliance obligation. This ticket was never assigned to our team, and no direct notification routed it to us; we located it through our own periodic review of Bugzilla activity referencing NETLOCK. That fact is relevant only to explaining the timeline of our public disclosure and response on this specific ticket — not as a basis for recalculating when any underlying compliance clock started or stopped. We recognize that using the word "awareness" in both contexts, without drawing this line explicitly, made our position read as more sweeping than intended, and we should have separated these from the outset.

On the comparison drawn in Comment 5 to Bug #2013400: we raised a distinction there — that the ticket in that case had been assigned to NETLOCK — based on our recollection, but we have not yet independently re-verified this against that bug's history before making the claim here, and we should not have stated it as settled fact. We will confirm the actual record and follow up with a corrected, verified comparison (or a withdrawal of the comparison) rather than let an unverified claim stand.

4. On the concern that "awareness" framing could be used to stall
If NETLOCK were using an awareness-based standard strategically, to minimize the apparent delay in our response, the incentive would be to claim the latest defensible awareness date — the later the claimed awareness, the shorter the apparent gap between "knowing" and "acting." Instead, in this very bug's own Timeline, NETLOCK disclosed 2026-06-16 20:12:31 UTC as our awareness date for the OCSP issue — a date that is now being used, correctly, in Comment 5 to show an even larger 72-hour disclosure gap than would exist if we had claimed a later date, or none at all. A party attempting to game the "awareness" framing for advantage would not voluntarily supply a self-incriminating, early awareness timestamp that extends its own exposure. We disclosed it because it is accurate, not because it is convenient, and we accept that it currently counts against us.

We raise this because it speaks directly to the mechanism of the concern: a strategy of hiding behind "we weren't aware" only works if the claimed date is chosen to minimize liability. Ours was not. We think this is a meaningful, checkable distinction between what a deliberate stalling pattern would look like and what has actually happened here, though we recognize it does not undo the underlying control failures, which we are addressing through the action items and the forthcoming 72-hour report.

Update on Action Item 1 ("N" placeholder) and Timeline verification
We are still finalizing our response to the undefined "N" evaluation criterion raised in Comment 6. In the course of doing so, we are also re-verifying the detection timeline described in this report's Root Cause Analysis against our internal monitoring logs, to ensure it is fully accurate before we finalize the evaluation criterion.

We would rather take the time to confirm these details properly than provide a partial or provisional answer now. We will follow up with a complete, verified update — including corrections to the Timeline or Root Cause Analysis, if our review identifies any — as soon as that verification is complete.

Comment 8

[Ophelia P.]

Replying to Comment 7.

1 - On June 16, 2026 at 12:33 AM, I received the following automated response originating from [e-mail]:

"Thank you for contacting us. We have received your message, to which our system assigned the following identification number: 01204167. In case you wish to share any further information, please send it in an answer to this e-mail."

This response demonstrates that one of my emails was received, ingested by NETLOCK's ticketing system, and processed sufficiently to generate a case ID and send a confirmation to the reporter. NETLOCK should explain what happened to that ticket, when it was reviewed, and why it did not result in a substantive response within 24 hours - or even the 5 days that any other revocation request would need to be actioned by. I followed up on June 24, 2026 at 12:42 am - and had this been an actual revocation request, you would have been late.

By the way, the Incident timeline is lacking, given the above is not presented...

2 - NETLOCK's comment offers two distinct explanations for two distinct failures: compliance.info@ failed due to spam filtering, and visszavonas@ failed because it is "not staffed or triaged as a general compliance/CPR inbox." These are separate defenses for separate addresses. Together they describe a CPR infrastructure where every disclosed channel failed simultaneously through independent mechanisms. That is a more serious finding than either explanation alone suggests, and it raises the question of what redundancy or monitoring actually exists between these two channels.

3 - Both [e-mail] and [e-mail] are disclosed to CCADB as problem reporting mechanisms, without any ranking, prioritization, or note that one is preferred over the other. A reporter consulting the CCADB AllProblemReportingMechanismsReport has no basis to treat one address as primary and one as fallback. NETLOCK's operational distinction between these two inboxes is not reflected in its CCADB disclosure, and cannot reasonably be expected to be known by external reporters. If visszavonas@ is not intended to receive general CPR submissions, it should not be disclosed as a CPR mechanism without qualification.

4 - NETLOCK's comment states that the CPR emails were handled by different teams across these two inboxes, which is offered as an explanation for why neither team escalated. Can NETLOCK confirm there is no overlap between the personnel responsible for compliance.info@ and visszavonas@? And can NETLOCK describe what, if any, monitoring exists to detect when a ticket generated by either inbox has not received a substantive response within 24 hours? The existence of case ID 01204167 suggests the system knew a ticket existed. The question is why that knowledge did not produce a response.

5 - NETLOCK describes [e-mail] as a mailbox "used operationally for revocation requests specifically." Revocation requests carry some of the most time-sensitive obligations in the TLS Baseline Requirements — BR §4.9.5 requires a CA to begin investigation of a CPR within 24 hours of receipt, and revocation itself must follow within defined windows. A mailbox designated for revocation requests should therefore be among the most closely monitored inboxes NETLOCK operates. NETLOCK's characterization of this address as a narrower, less-generally-triaged channel does not explain a 16-day response time. If this is the revocation inbox, and messages sent to it take 16 days to receive a substantive response, the community should understand whether revocation requests sent to this address are also subject to the same delays.

Comment 9

[Andrew]

(In reply to Ophelia P. from comment #6)

3 - I should have caught this earlier, but Action Item 1 of the incident report includes the following evaluation criterion: "Mean time to detect an OCSP synchronisation gap reduced to < N hours." The letter N is not defined anywhere in the report.

(In reply to Janos | Netlock from comment #7)

We would rather take the time to confirm these details properly than provide a partial or provisional answer now. We will follow up with a complete, verified update — including corrections to the Timeline or Root Cause Analysis, if our review identifies any — as soon as that verification is complete.

There are two other apparent placeholders in the "Relevant policies" section of the full incident report:

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)
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)

Regarding the Root Cause Analysis: The timeline in the full incident report acknowledges the original CPR was received 5 days after the non-compliance began (6 days before NETLOCK end up detecting and correcting the non-compliance), however the implied lack of action on receipt of this CPR is not acknowledged as a contributing factor at all. I think NETLOCK could acknowledge this missed opportunity in the "where we got unlucky" and/or "Contributing factors" section while still avoiding repetition by referring to the action items tracked in bug 205241.

Comment 10

[Andrew]

(In reply to Andrew from comment #9)

... bug 205241.

Apologies, that should have referenced bug 2052541

Comment 11

[incident-reporting]

For clarity and consistent tracking, we are renaming this bug as tracking the OCSP responder incident only. The Certificate Problem Report (CPR) response-time incident is now being tracked separately in Bug 2052541.

Comment 12

[Janos | Netlock]

Dear all,

Thank you for your patience and for the detailed questions raised in Comments #8 and #9.

Regarding the bug split (Comment #11): As this bug now tracks the OCSP responder incident specifically, the questions concerning the Certificate Problem Report handling, the [e-mail] mailbox, and the response timeline for case ID 01204167 (raised by Ophelia in Comment #8) will be addressed in Bug 2052541, where that incident is now being tracked. We will post our response there separately.

Regarding Andrew's outstanding items in Comment #9 (OCSP responder incident):

We do not yet have the finalized figures needed to answer these fully and accurate, and we would rather take the additional time to confirm them properly than provide a partial or incorrect answer:

• The specific value for "N" in Action Item 1.
• The exact CA/Browser Forum Baseline Requirements version number in force on 2026-06-05, referenced in the "Relevant policies" section.
• The exact NETLOCK CP/CPS document and section reference for our OCSP/certificate-status-service commitments.
• Whether the 5+6 day gap between the start of the non-compliance and our own detection/correction of it (independent of the CPR) will be added to the Root Cause Analysis as a contributing factor.

We are actively working through these internally and will post a complete, verified update as soon as possible.

We appreciate your continued engagement and will follow up shortly.

Best regards,
Janos

Comment 13

[Dustin Hollenback (Apple)]

Following up on the three points from my Comment 5 made 8 days ago. Comment 7 and today's Comment 12 leave two of them open; each is quoted below with its status. This is a reminder that CCADB Incident Reporting Guidelines expect a response to each question within a week, with a date if the answer is not yet ready.

1.

confirm that the 24-hour obligation runs from receipt of a report, not only from internal awareness, as bug 2052541 already does

Met. Comment 7 confirms it and withdraws the earlier claim that the report missed a designated channel.

2.

address the missed 72-hour preliminary report as its own matter, not as part of the 24-hour report

Open. No separate report exists; only this bug and Bug 2052541 (the 24-hour CPR failure) are tracked (Comment 11). This repeats Bug 2013400 (resolved FIXED 2026-04-17), whose remediation included "automated 72-hour countdown alerts with escalation" (Comment 8); the new report should explain why that control did not prevent recurrence. Does NETLOCK agree or disagree that this requirement is met? If met, cite where; if not, confirm the report will be opened and give a filing date.

3.

adequately explain in that new 72-hour bug why this bug's Timeline states that NETLOCK was aware of non-compliance on 2026-06-16, yet this bug was not opened until 2026-06-29

Open. This is the awareness-to-filing gap, measured from 2026-06-16, distinct from the detection-latency gap in Comment 12. Comment 7 accepts the 2026-06-16 date but does not explain the gap, and says it is being re-verified; if it changes, give the corrected date and its basis. Does NETLOCK agree or disagree that this requirement is met? If met, cite where; if not, confirm the explanation will appear in that report.

Comment 14

[Janos | Netlock]

Dear Dustin,

We are looking into both outstanding points — whether a 72-hour preliminary report was filed, and the awareness-to-filing gap between 2026-06-16 and 2026-06-29 — and will respond to both in full in our next weekly update, in line with our standing update cadence on this bug.

Thank you very much for your patience and understanding.

Best regards,
NETLOCK

Comment 15

[incident-reporting]

Regardless of the update for this bug which appears incorrectly provided here, this report had already gone stale. As a reminder, CA Owners may request the “Next update” Whiteboard field be set by a Root Store Operator to align with a specific date related to an open Action Item.

Comment 16

[[:Levente@Netlock]]

Dear all,

This is the update owed on this bug, now provided in the correct place. We acknowledge, without excuse, two process failures on our side: this report was allowed to go stale (Comment #15), and we first posted this update to the wrong bug (2004699 Comment #44) before correcting it. Both were ours.

We used the additional time to produce the verified reconciliation in §6 from our internal records rather than post a provisional figure — but that does not excuse the gap: we should have posted an interim status on the committed weekly cadence and did not. Per the reminder in Comment #15, we request that a "Next update" Whiteboard date be set, aligned with Action Item 2 (2026-08-22), and we will keep to the weekly cadence in the interim.

This update closes the items left open in Comments #9, #12, #13 and #14, removes the placeholders that were rightly criticised, and does not rely on any explanation already rejected in this bug.

1. Corrected placeholders in the Full Incident Report

These should not have been filed as placeholders; holding the report until the values were confirmed would have been the correct call.

• Action Item 1 detection target ("N"). Detect an OCSP synchronisation gap in under 2 hours, verified by injecting a synthetic missing serial in our test environment and confirming the internal alert fires within that window. Two hours sits safely above our normal responder propagation time, so it alerts on genuine gaps without false positives.
• Baseline Requirements version in force on 2026-06-05. TLS BR v2.2.7 (adopted 2026-04-18 by Ballot SC099; superseded by v2.2.8 on 2026-06-16), sections 4.9.9 and 4.9.10.
• CP/CPS reference. The affected certificate asserts CA/Browser Forum policy OID 2.23.140.1.2.1 (Domain Validated) with the CPS pointer http://www.netlock.hu/docs/. The governing document is our Service Practice Statement for Non-Qualified Certificate Services (SPS-NQC-EN), version 260525, valid from 2026-05-25 (OID 1.3.6.1.4.1.3555.1.1.15.0.260525) — the version in force on the 2026-06-05 issuance date — sections 4.9.9 "On-line status checking availability" and 4.9.10 "On-line status checking requirements".

2. Root cause — detection latency added as a contributing factor

Andrew was correct in Comment #9: the report understated our own failure. The responder served "unknown" for approximately 11 days, and a Certificate Problem Report reached us on 2026-06-10 — five days after the non-compliance began (2026-06-05) and six days before our own monitoring surfaced the condition on 2026-06-16. We have added a contributing factor stating exactly this: for 11 days we had no internal control that would have detected the gap, and the external signal that could have prompted action did not reach anyone who acted. We are recording this here rather than deferring it to Bug 2052541, because it is a root cause of this (OCSP) incident.

3. The missed 72-hour preliminary report

It was owed, it was not filed, and that is a compliance failure in its own right. We will file it as a separate Full Incident Report by 2026-08-13 and link it here.

On why this recurred after Bug 2013400 (resolved FIXED 2026-04-17): the remediation there added an automated 72-hour countdown alert, but that alert only arms for externally-filed Bugzilla tickets routed to our component. This incident was self-detected through our own monitoring on 2026-06-16, not via an assigned ticket — so no countdown was ever started. That is a real blind spot in the control we built: it covers incidents others report to us, but not incidents we detect ourselves. We would rather name that specific defect than present the repeat as a one-off.

4. The gap between awareness (2026-06-16) and filing (2026-06-29)

We are not going to lean on "the ticket was not assigned to us." We detected the condition on 2026-06-16, remediated it on 2026-06-17, and closed it as an operational fix. We had no process step that converts a self-detected, compliance-relevant condition into a reportable incident and starts the 72-hour clock. In practice, disclosure was only triggered when the external report arrived. That is a process failure on our side.

5. Shared preventive control for items 3 and 4

Both gaps share one root cause: our disclosure process is driven by inbound reports, not by our own detections. We are adding a single control — every internally-detected, compliance-relevant incident is routed into the same reportability assessment and 72-hour countdown as an externally-filed ticket. Owner: NETLOCK Compliance team, with PKI Operations; target: 2026-09-30.

6. Action Item 4 — reconciliation sweep (result)

We reconciled our currently-valid, publicly-trusted TLS subscriber certificates against their OCSP responders, driving the reconciliation from our internal issuance records (the authoritative, complete source) and independently corroborating it against the Certificate Transparency record. Certificate types that a subscriber responder does not serve — precertificates, CA/intermediate certificates, and delegated OCSP-responder certificates — were excluded.

Result: every currently-valid TLS subscriber certificate returned "good"; every revoked one returned "revoked"; zero "unknown". Our internal inventory and the CT record are fully consistent — every internally-recorded subscriber certificate is present in CT with matching status, and no certificate was found missing from, or incorrectly served by, the responders.

NETLOCK OCSP reconciliation — currently-valid publicly-trusted TLS subscriber certs
Internal issuance records, cross-checked against Certificate Transparency
(precertificates, CA/intermediate certs, and OCSP-responder certs excluded)

Issuing CA / responder                 good  revoked  unknown
-------------------------------------  ----  -------  -------
NETLOCK DVSSL CA          (DVCA)          2        1        0
NETLOCK Domain Validated CA (pdvca)       0        1        0
NETLOCK Trust EV CA 3     (trustev3)      3        1        0
NETLOCK TLS ECC CA        (tlseccca)      0        0        0
-------------------------------------  ----  -------  -------
TOTAL                                     5        3        0

Internal records and CT agree on every entry; no discrepancy found.

Scope note: this covers the publicly-trusted TLS certificates served by the DVCA / pdvca / trustev3 / tlseccca responders (the responders in this incident's scope). NETLOCK's delegated OCSP-responder certificates and CA certificates for these hierarchies are all currently valid.

The full per-certificate evidence (issuer, serial, certificate type, and OCSP status for every certificate assessed) is available on request or as an attachment to this bug.

Status of open Action Items

Action Item	Kind	Evaluation Criteria	Target	Status
1. Dedicated internal OCSP synchronisation monitoring/alerting	Detect	Synthetic gap detected in < 2h in test	2026-09-19	In Progress
2. Route external OCSP Watch (SSLMate) alerts to on-call	Detect	Alerts reach on-call within minutes; runbook exercised	2026-08-22	In Progress
3. Immediate remediation — resynchronise responder	Mitigate	Responder returns "good" for the affected cert	2026-06-17	Complete
4. Reconciliation sweep of all currently-valid certs	Detect	100% return a definitive status; discrepancies reported	2026-07-31	Complete 2026-08-10 (see §6)
5. Route self-detected incidents into 72-hour disclosure process	Prevent	Self-detected incident starts the countdown in test	2026-09-30	New (see §5)

Next update

We will confirm the separate 72-hour report's bug number once filed, and report completion of Action Items 1, 2 and 5, in our next weekly update, or sooner if a milestone lands earlier.

Best regards,
Levente FRÜHWALD - NETLOCK

Comment 17

[[:Levente@Netlock]]

Hi Everyone,

Two things in this update — the separate report we committed to, and a correction to our own Comment #16.

First, the report. We have filed the separate Full Incident Report for the missed 72-hour preliminary-disclosure deadline as Bug 2063842, as committed in §3 of Comment #16. It is two days later than the 2026-08-13 date I gave. That is on me — I should have either met the date or flagged the slip before it passed, and I did neither.

Second, a correction I would rather put on the record myself than have someone point out. While preparing that report I went back and checked our §3 explanation against Bug 2013400, and we got it wrong. I wrote that the 2013400 countdown control "only arms for externally-filed Bugzilla tickets." That is not accurate, and it contradicts what Bug 2013400 actually documents: the control computes the 72-hour countdown from the time of first awareness, once an incident is logged in our tracking system, and it went into production on 2026-03-23.

The real reason it did not fire here is the one already in §4. We detected this on 2026-06-16, fixed it on 2026-06-17, and handled it as an operational fix — so it was never logged as a reportable incident in the first place. An awareness-based countdown that starts from a logged incident cannot start when nothing is logged.
The gap is that missing step between "we found and fixed something" and "this is a reportable incident," which is exactly what the control in §5 — and Action Item #1 in the new report — is meant to close. The new report uses this corrected description throughout.

Best regards,
Levente FRÜHWALD, NETLOCK

Comment 22

[Malcolm D]

This report appears to have gone stale, as no extended update deadlines were applied for.