2052541 - NETLOCK: Failure to Respond to a Certificate Problem Report Within 24 Hours

Status: UNCONFIRMED

(CA Program :: CA Certificate Compliance, task)

Description

[Roland]

Full Incident Report

Scope note: This report addresses only the failure to respond to a Certificate Problem Report (CPR) within 24 hours (issue #2 in Bug 2051459). The OCSP availability failure (issue #1) is addressed in a separate Full Incident Report, per the reporter's recommendation that each root cause be filed independently.

Summary

• CA Owner CCADB unique ID: A000039
• Incident description: NETLOCK failed to begin investigation of, and provide a preliminary report on, a Certificate Problem Report within 24 hours of its receipt, as required by CA/Browser Forum TLS Baseline Requirements Section 4.9.5. The CPR was received at NETLOCK's CCADB-disclosed problem-reporting address ([e-mail]) on 2026-06-10 at 23:48 UTC and referenced an OCSP error, linking the affected certificate issuance. Two independent mail-handling failures prevented the report from reaching the dedicated compliance team: (a) messages delivered to [e-mail] were classified as spam and never surfaced onto the internal compliance "warning list", and (b) messages that reached secondary channels — the revocation-only address [e-mail] and an individual employee address — were not recognized as CPRs and were not escalated. As a result, no acknowledgment or preliminary report was provided within the required 24 hours, and the first substantive (but inadequate) reply reached the reporter only 16 days later.
• Timeline summary:
  • Non-compliance start date: 2026-06-11 23:48 UTC (expiry of the 24-hour window under TLS BR 4.9.5, which began upon receipt of the CPR on 2026-06-10 23:48 UTC)
  • Non-compliance identified date: 2026-06-28 (NETLOCK's dedicated compliance team became aware of the compliance failure through the public filing of Bug 2051459 and began reviewing mail-system logs)
  • Non-compliance end date: 2026-06-28 (the dedicated compliance team assumed ownership of the report and began the incident-response process; systemic remediation is scheduled to complete by 2026-08-03)
• Relevant policies: CA/Browser Forum TLS Baseline Requirements, Section 4.9.5 — "Time within which CA must process a Certificate Problem Report" (a CA must begin investigation within 24 hours of receipt and provide a preliminary report to the reporter and the Subscriber). Mozilla Root Store Policy §2.4 (Incident Reporting) and the Mozilla Root Store Policy's incorporation of the TLS Baseline Requirements.
• Source of incident disclosure: Third Party Reported (Certificate Problem Report, and subsequently Bug 2051459, filed by a community member)

Impact

• Total number of certificates: 0. This incident concerns responsiveness to a Certificate Problem Report and does not involve any misissued or otherwise non-compliant certificate. The single certificate referenced in the originating CPR is addressed in the separate OCSP Full Incident Report and is not "affected" by the CPR-response failure.
• Total number of "remaining valid" certificates: 0 (not applicable; no certificates are affected by this incident)
• Affected certificate types: None. This incident does not involve certificate misissuance, so no CA/Browser Forum policy OIDs (DV / IV / OV / EV) are implicated by the CPR-response failure itself.
• Incident heuristic: Not applicable. No corpus of certificates is affected by this incident; therefore no heuristic is required and the Appendix contains no certificate listing.
• Was issuance stopped in response to this incident, and why or why not?: No. The incident relates solely to the handling of, and response to, a Certificate Problem Report — not to certificate issuance or to any defect in issued certificates. Halting issuance would not have reduced the impact of, or remediated, this incident.
• Analysis: Not applicable. The Whiteboard field does not contain 'revocation-delay'; no revocation was delayed as a consequence of this incident.
• Additional considerations: Bug 2051459 as filed describes two distinct compliance failures: (1) an OCSP availability failure and (2) this failure to respond to a CPR within 24 hours. Following the reporter's recommendation, NETLOCK addresses each root cause in a separate Full Incident Report. This report covers only failure (2).

Timeline

All times UTC. Dates provided by the reporter have been corroborated against NETLOCK's mail-system logs.

• 2026-06-10 23:48 — A Certificate Problem Report is received at NETLOCK's CCADB-disclosed problem-reporting address, [e-mail], referencing an OCSP error and linking the affected certificate issuance. NETLOCK's mail system classifies the message as spam; it is placed in the spam folder and is not added to the internal compliance "warning list", so it does not reach the dedicated compliance team. No acknowledgment is sent and no ticket is created. The 24-hour clock under TLS BR 4.9.5 begins.
• 2026-06-11 23:48 — The 24-hour window under TLS BR 4.9.5 elapses without an investigation or a preliminary report. Non-compliance begins.
• 2026-06-16 — The reporter sends a follow-up to [e-mail] (again classified as spam and not surfaced to the dedicated compliance team) and additionally CCs [e-mail]. The [e-mail] address is reserved exclusively for revocation requests; because the message was not a revocation request, it is forwarded to customer service, who contact the customer. The message is not recognized as a CPR and is not escalated to the dedicated compliance team.
• 2026-06-24 — A further message is received at [e-mail]. As it is again not a revocation request, it is forwarded to customer service. An automated acknowledgment is generated, assigning case ID 01206157. (Per the reporter, this automated acknowledgment was received approximately 14 days after the initial CPR.)
• 2026-06-26 ~08:57 — Customer service sends the first substantive response to the reporter, consisting solely of the question "Which certificate is affected?". Because the content of the original CPR had never reached customer service or the dedicated compliance team, the certificate reference was not available to the responder and no meaningful investigation had taken place. Separately on 2026-06-26, a report sent to an individual NETLOCK employee's personal address is classified as spam and does not reach the dedicated compliance team; a message received the same day at [e-mail] is again not forwarded to the dedicated compliance team, as it is not a revocation request.
• 2026-06-28 — The reporter files public Bug 2051459, describing the OCSP availability failure and the failure to respond to the CPR within 24 hours. NETLOCK's dedicated compliance team becomes aware of the compliance failure through this filing and begins reviewing mail-system logs. Non-compliance is identified, and the dedicated compliance team assumes ownership of the report.
• 2026-07-03 — NETLOCK completes its log review, confirms the root causes described below, and prepares this Full Incident Report.

Related Incidents

Bug	Date	Description
2005762 — Chunghwa Telecom: Failure to respond to CPR within 24 hours	2025-12-12	Directly on point and recent — same failure type (no response to a Certificate Problem Report within 24 hours). RESOLVED FIXED; a current precedent for the expected handling and remediation of this exact issue.
2004704 — Certigna: Failure to respond to CPR within 24 hours	2025-12-08	Same failure type; RESOLVED FIXED. Filed within days of the NAVER report below (adjacent bug numbers), reflecting a recent cluster of comparable CPR-response failures across multiple CAs.
2004698 — NAVER Cloud Trust Services: Failure to respond to CPR within 24 hours	2025-12-08	Same failure type (no response to a CPR within 24 hours); RESOLVED FIXED.
1994454 — Sectigo: Failure to reply to Certificate Problem Reports within 24 hours	2025-10-15	Same failure type (no reply to CPRs within 24 hours); RESOLVED FIXED.
1985466 — IZENPE: Failed to respond a Certificate Problem Report within 24 hours and create a preliminary report in 72 hours	2025-08-27	Closest title match to the requirement at issue: failure to respond to a CPR within 24 hours (and to file a preliminary report within 72 hours).

Root Cause Analysis

Contributing Factor 1: Legitimate Certificate Problem Reports classified as spam at [e-mail]

• Description: NETLOCK's CCADB-disclosed problem-reporting mailbox ([e-mail]) is subject to spam filtering. When a message is classified as spam it is moved to a spam folder and is not added to the internal compliance "warning list" that surfaces reports to the dedicated compliance team. Consequently, genuine CPRs delivered to this address on 2026-06-10, 2026-06-16, and 2026-06-26 were never seen by the team responsible for handling them, and no acknowledgment, preliminary report, or ticket was generated.
• Timeline: The spam-filtering configuration pre-dated the incident and applied to all mail delivered to the address. It first affected this incident on 2026-06-10 23:48 UTC, when the initial CPR was silently diverted to spam, and recurred on 2026-06-16 and 2026-06-26.
• Detection: The condition was not caught by any internal control at the time. There was no monitoring to verify that every message delivered to the problem-reporting address reached the dedicated team, and no alerting on spam-foldered items. It was ultimately detected only when the reporter escalated by filing public Bug 2051459, prompting NETLOCK to review its mail-system logs.
• Interaction with other factors: This factor removed the primary, correct intake path for the CPR and forced the reporter onto secondary channels (the revocation address and an individual employee address), where Contributing Factor 2 then prevented escalation — compounding the delay.
• Root Cause Analysis methodology used: 5-Whys

Contributing Factor 2: CPRs arriving on secondary channels not recognized and not escalated to the dedicated compliance team

• Description: The [e-mail] address is reserved exclusively for revocation requests; non-revocation messages arriving there are forwarded to customer service. Customer service handled the misdirected messages (2026-06-16, 2026-06-24, 2026-06-26) as ordinary customer inquiries rather than recognizing them as Certificate Problem Reports and escalating them to the dedicated compliance team. Likewise, a report sent to an individual employee's personal address on 2026-06-26 was spam-filtered and not escalated. Because the substance of the CPR never reached anyone equipped to act on it, the only substantive reply the reporter received was a request to identify the affected certificate.
• Timeline: The revocation-only routing rule and the absence of a CPR-recognition/escalation step in customer service pre-dated the incident. This factor first affected the incident on 2026-06-16 and recurred on 2026-06-24 and 2026-06-26.
• Detection: Not detected by internal controls. There was no procedure requiring customer service to identify compliance or problem reports and route them to the dedicated compliance team, and no alerting for misdirected compliance mail. Detected only upon the Bugzilla filing and subsequent log review.
• Interaction with other factors: This factor eliminated the fallback path that should have compensated for Contributing Factor 1. With the primary channel suppressed by spam filtering and the secondary channels not escalating, no path reached the dedicated compliance team, and the 24-hour requirement was missed on every submission.
• Root Cause Analysis methodology used: 5-Whys

Lessons Learned

• What went well: Once the Bugzilla bug surfaced the issue, NETLOCK's mail-system logs contained sufficient detail to reconstruct the full delivery path of each message and to pinpoint both routing failures quickly and precisely. The problem-reporting addresses were correctly disclosed in the CCADB and did receive the mail — the failure was in internal surfacing, not in intake configuration or in the availability of the addresses.
• What didn't go well: Spam filtering silently suppressed genuine CPRs on the primary problem-reporting address, with no monitoring or fallback to catch them. Customer service had no procedure to recognize and escalate CPRs that arrived via other channels. There was no end-to-end control verifying that every problem report reaching NETLOCK actually reached the dedicated compliance team. These gaps allowed the 24-hour requirement to be missed repeatedly across three separate submissions.
• Where we got lucky: The reporter was persistent, submitting the report multiple times across several channels over 16 days and ultimately filing a public Bugzilla bug. Had the reporter given up after the initial silence, the CPR — and the underlying OCSP issue it flagged — might never have reached the dedicated compliance team. NETLOCK cannot rely on reporter persistence and is addressing the intake gaps directly (see Action Items).
• Additional: The incident reflects an over-reliance on a single mailbox path and on the assumption that mail delivered to a disclosed address will reach the responsible team, without any invariant check that this actually occurs.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Reconfigure the mail system so that reports delivered to [e-mail] are added to the compliance warning list and reach the dedicated compliance team even when the message is classified as spam (e.g., quarantine notifications, allow-listing, and/or routing spam-foldered items to the warning list for manual review).	Prevent, Detect	Contributing Factor 1	Verifiable via configuration records and a post-implementation test in which a report is deliberately delivered such that it would be spam-classified and is confirmed to reach the dedicated team and the warning list; ongoing zero-loss confirmed by periodic delivery tests.	2026-08-03	Ongoing
Train customer-service staff to recognize Certificate Problem Reports and any compliance-related contact received on any channel (including [e-mail] and individual employee addresses) and to forward them immediately to the dedicated compliance team.	Prevent, Detect	Contributing Factor 2	Verifiable via training completion records and a documented escalation procedure; effectiveness measured by confirmation that subsequent misdirected compliance contacts are escalated to the dedicated team (tracked internally and spot-checked).	2026-08-03	Ongoing

Appendix

Not applicable. This incident concerns responsiveness to a Certificate Problem Report and does not involve any misissued, revoked, or otherwise affected certificates; accordingly, no certificate listing is included. The single certificate referenced in the originating CPR is addressed in the separate Full Incident Report concerning the OCSP availability issue.