CA/Netlock Issues

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This near-final draft remains subject to verification and amendment, including checks of citations, quotations, cross-references, incident status, and the characterization of related or superseded reports. Technical findings and remediation claims attributed to others have not necessarily been independently verified. Mozilla has not yet determined the timing, scope, or manner of trust removal.

Netlock Issues

This page summarizes publicly documented issues involving NETLOCK Kft. (Netlock), including recurring deficiencies in incident response, certificate revocation, certificate issuance, disclosure, and revocation services. It is not necessarily comprehensive and may be updated by Mozilla as additional information becomes available. Please do not edit this page directly. Proposed corrections or additions should be sent to the Mozilla dev-security-policy discussion list or to certificates@mozilla.org.

The issues are grouped by subject rather than presented strictly chronologically. Closed incidents remain relevant to understanding Netlock's commitments and subsequent performance. Related reports concerning the same event are identified together.

Summary

The central concern is Netlock's ability to sustain effective controls across its publicly trusted CA operations. The public record includes repeated failures to provide timely incident updates, respond to certificate problem reports, revoke non-compliant certificates, and identify the full scope of technical defects. Several later reports expressly acknowledge recurrence after earlier corrective measures had been reported complete.

Individual fixes and improvements are acknowledged below. The cumulative assessment concerns whether those measures have produced reliable, continuing compliance and effective public accountability.

Issue A: Repeated failures to maintain incident updates and answer questions (2018–2026)

A.1. Prolonged silence in an early misissuance incident

In Bug 1462423, involving seven precertificates whose common names were not represented in their subject alternative names, Ryan Sleevi noted in Comment 2 that approximately eight months had passed without an update or response. Netlock later explained that it had acted on the direct report but missed Bugzilla notifications. The distinction matters: technical remediation did not discharge the separate obligation to report publicly and respond to questions.

Mozilla opened Bug 1572992 in 2019 because of repeated failures to respond and update that incident. Netlock attributed missed responses to mail filtering and misunderstanding comments. It reported whitelisting Bugzilla mail, changing its handling of unclear requests, and transferring contact duties to a dedicated team. The bug was subsequently resolved FIXED.

A.2. Renewed concerns and corrective commitments in 2023–2025

In Bug 1819105, Comment 1, Chrome asked why eleven days had passed without acknowledgment of a stale-CRL report. In Comment 5, Chrome described the delays across Netlock's open incident reports as unacceptable and requested specific, time-bound improvements. Netlock cited limited compliance resources and competing audits in Comment 6. Chrome responded in Comment 7 that those circumstances were not satisfactory explanations for the delays and insufficient prioritization of incident management.

In Bug 1904041, Comment 8, Chrome again criticized Netlock's incident handling and asked why it had regressed after similar concerns approximately thirteen months earlier.

Mozilla subsequently opened Bug 1957474 over missing weekly updates in four incidents: Bugs 1904041, 1905509, 1947691 and 1917046. Even the report about missing updates required reminders about preliminary and full reporting obligations. Netlock ultimately reported implementing ticketing reminders, compliance-calendar integration, a designated coordinator, automated alerts, and clearer accountability. The incident was closed in June 2025 after Netlock reported completion of its action items.

A.3. Further recurrence in 2026

In Bug 2052541, Comment 15, Netlock documented gaps between its own posts of 49 days in that bug, 45 days in Bug 2004699, and 39 days in each of Bugs 2051459 and 2063842. Four committed action dates passed without reporting. Netlock acknowledged that this repeated earlier failures and had not yet fully established why its 2025 controls failed.

Comment 16 disclosed failure of the first cycle of its new update control: reminders fired but went to people other than the responsible owner and deputy. Netlock reported correcting and testing the routing on 9 October 2026.

Further missed updates and report commitments were recorded in Bug 2004699, Comments 50–51, Bug 2063842, Comment 4, and Bug 2075720, Comment 1.

The corrected reminder routing did not prevent another missed commitment. In Bug 2052541, Comment 19, Netlock acknowledged that the updated Full Incident Report promised for 21 October 2026 in Bug 2004699, Comment 51 had not been posted. Netlock also acknowledged that it had not caught the missed commitment itself. The explanation of the AIA regression and reconciliation of the published AIA inventory against internal issuance records remained unfinished.

In the 5 November 2026 public response to this Issues List, additional reporting gaps were identified: action items due by 16 October in Bug 2075255, Comment 7, Bug 2075258, Comment 5, and Bug 2075720, Comment 2 had received no subsequent status update. He also noted that the Full Incident Report promised for 2 November in Bug 2083866, Comment 1 had not been posted. These observations concern the public reporting record as of that date; absence of a completion report does not, by itself, establish that the underlying remedial work was not performed.

The concern is therefore not merely the age of open bugs. The record documents repeated failures to meet reporting commitments, including after controls intended to prevent those failures had been reported implemented or corrected.

Issues: Incident response; public accountability; organizational continuity; ineffective corrective actions.

Issue B: Certificate problem reports were not handled within the required timeframe (2017, 2024 and 2026)

Bug 1391056 documents a certificate problem report sent to v**@netlock.hu on 8 August 2017 UTC that was not escalated promptly. In Comment 4, Netlock explained that the message had waited until a staff member returned from abroad. Netlock reported training customer service staff to escalate unusual messages received at that mailbox. In Comment 8, Ryan Sleevi questioned whether continued reliance on human escalation adequately addressed the failure and asked whether technical monitoring and alerting had been considered.

Bug 1905509 documents failure to respond within 24 hours to a 2024 certificate problem report sent to the contact published in Netlock's CP/CPS. Staff treated that address as a channel for policy questions rather than recognizing the certificate problem report. Published contact information also differed between the CP/CPS and CCADB. The related Bug 1906115 addresses the published reporting instructions.

Netlock reported creating a dedicated reporting address, updating its documentation, training staff, and establishing notifications to several departments.

Nevertheless, Bug 2052541 records another failure in June 2026. Messages sent to the dedicated compliance address were classified as spam and did not reach the responsible team. Follow-up reports sent to v**@netlock.hu—the same mailbox involved in the 2017 incident—were treated as matters for customer service because they were not revocation requests, rather than recognized as certificate problem reports and escalated to compliance. The first substantive reply arrived about sixteen days after the initial report and asked which certificate was affected, although the original report had included a reference to the affected certificate.

These incidents demonstrate recurring weaknesses in recognizing and escalating certificate problem reports, despite earlier commitments concerning staff training, reporting contacts, and notifications. Receipt by a functioning mailbox did not ensure that a report reached the responsible personnel or triggered the required investigation and response.

Issues: Problem-report intake; escalation; monitoring; recurrence after remediation.

Issue C: Repeated weaknesses in incident disclosure, report preparation, and learning from other CAs (2020–2026)

Bug 2007948 records failure to publish a full incident report within the required fourteen-day period in connection with the AIA encoding incident. Its discussion also questioned whether earlier multi-person review commitments provided effective technical verification.

Bug 2013400 records a separate failure to make the initial disclosure within 72 hours after receiving a report on 12 January 2026. Netlock acknowledged that its tracking used the Bugzilla filing date rather than first awareness, misaligning its reporting deadlines. It committed to awareness-based tracking and automated countdown alerts.

That control did not prevent the subsequent failure in Bug 2063842. Netlock became aware of the OCSP incident on 16 June 2026 but did not publish its report until 3 July. It later explained that the countdown control covered externally filed tickets but did not start for internally detected incidents. Technical correction on 17 June had been treated as an operational fix without triggering public incident disclosure.

Concerns about learning from other CAs' incidents had already been raised years earlier. In Bug 1676440, Comment 5, Ryan Sleevi explained that prior CA incidents had demonstrated comparable testing gaps and that awareness of those incidents could have prevented Netlock's failure. In Bug 1889570, Comment 4, Chrome noted that another CA had disclosed the same policy-qualifier defect in January 2024 and asked why Netlock's monitoring of Bugzilla had not led it to identify and correct its own misissuance. Netlock subsequently acknowledged that it had overlooked the other report and described changes to its requirements-tracking process.

Bug 2013395 records a further weakness in this area in 2026: Netlock interpreted the related-incidents requirement as covering its own incidents rather than relevant incidents across the ecosystem. This limited the analysis despite the earlier warnings about learning from comparable failures elsewhere.

The October 2026 reports in Bug 2075255, Bug 2075258, and Bug 2075720 again acknowledged late full reports. Revised dates did not make the original reporting deadlines cease to apply.

The same reporting sequence also required correction of the stated source of discovery. In Bug 2075255, Comment 4, Netlock corrected an earlier statement that the related CRL publication defect had been self-detected: the defect documented in Bug 2075720 had been reported by a third party. A corresponding correction appears in Bug 2075258, Comment 3. These corrections matter because initial discovery, subsequent investigation, and expansion of the affected scope are distinct activities when assessing the effectiveness of internal controls.

Issues: Late disclosure; report completeness and accuracy; deadline calculation; learning from other CAs.

Issue D: Repeated delayed revocation and subscriber-dependent compliance decisions (2019–2025)

Bug 1586795 concerns intermediate CA certificates that lacked the extended key usage required by Mozilla policy. The issue was publicly reported on 7 October 2019, but Netlock's subsequent account in Bug 1656882 records revocation of the TLS intermediates on 31 May 2020 and the digital-signature intermediate on 30 June 2020. Netlock acknowledged that the revocations had not been performed by 7 January 2020, the deadline it identified under Mozilla Root Store Policy version 2.7.

During the intervening discussion, Ryan Sleevi criticized the prolonged lack of action, and Mozilla moved to add MKB SubCA 5 to OneCRL. Netlock explained that it had deferred revocation while migrating end-entity certificates to replacement CAs to avoid disrupting their use. The related delayed-revocation report identified weaknesses in tracking requirements, assigning responsibility, and ensuring independent compliance oversight. This episode therefore involved both a missed policy requirement and a prolonged failure to revoke the affected CA certificates.

In Bug 1688844, related to the certificate-profile issue in Bug 1680378, Netlock identified the problem on 20 November 2020 but did not revoke the final affected certificate until 31 December. Netlock subsequently committed to clarifying internal revocation procedures and recognizing no exception to the applicable 24-hour or five-day deadlines.

In Bug 1822809, Netlock again delayed revocation of non-compliant certificates, this time those containing prohibited organizationalUnitName fields. Its initial account explicitly attributed the delay to a business decision to accommodate customer requests, despite the five-day requirement.

The same decision pattern appeared in the 2024 policy-qualifier incident. Bug 1891331, subsequently superseded by Bug 1947691, documented extending revocation for subscribers described as important to the national economy. The latter report states that delayed revocations were completed on 30 April 2024.

Mozilla rejected subscriber importance and operational inconvenience as exceptions. Netlock later acknowledged that its policies, subscriber contracts, escalation arrangements, and revocation preparedness had been insufficient. Its closure material reported revised contracts, readiness reviews, escalation procedures, and a mass-revocation simulation.

Those reported improvements are relevant, but the repeated decisions to defer revocation demonstrate that the problem extended beyond a single certificate-profile defect. The record includes delayed revocation of both intermediate CA certificates and subscriber certificates, together with recurring weaknesses in requirements tracking, escalation, and preparedness for timely replacement.

Issues: Delayed revocation; compliance governance; subscriber readiness; emergency response.

Issue E: Certificate-profile changes and issuance checks did not reliably prevent misissuance (2017–2026)

The record includes multiple failures to implement changing requirements and apply checks consistently across issuance paths:

• Bug 1391056: certificates contained internationalized domain names in Unicode form rather than the required ASCII-compatible form in dNSName entries. Netlock explained that the low volume of IDN certificates had kept them outside its spot checks. It reported adding validation and training staff, while Ryan Sleevi questioned whether the remediation adequately addressed the systemic weaknesses in detection and prevention.
• Bug 1401211: a certificate contained a wildcard outside the leftmost label after a manual modification of the request removed a separator. Mozilla asked whether Netlock had considered pre-issuance linting. The incident illustrates the need to validate the final certificate contents after manual changes.
• Bug 1462423: seven precertificates issued in May 2018 had common names absent from their DNS SANs. A production configuration placeholder and differences between precertificates and final certificates were discussed in the report.
• Bug 1586795: intermediate CA certificates lacked the extended key usage required by Mozilla Root Store Policy version 2.6.1, despite Netlock's earlier CA Communication response confirming that it would comply. The discussion questioned the gap between that commitment and its implementation. The related delayed revocations are addressed in Issue D.
• Bug 1676367: precertificates exceeding 398 days were issued after the September 2020 limit took effect. Netlock explained that testing covered new orders but omitted orders already in progress. It subsequently applied the same checks to precertificates and ordinary certificates.
• Bug 1676440: a certificate with a 4092-bit RSA key was issued because the check requiring a modulus size divisible by eight did not run on renewals. The discussion identified an assumption that existing data had already been verified, leaving the renewal path insufficiently checked. This is another example of validation and testing failing to cover all issuance paths.
• Bug 1820174: TLS certificates continued to include organizationalUnitName after its prohibition. Netlock reported changing its software, request forms and policies. A later update described weekly manual linting while automated checking remained under investigation.
• Bug 1889570: prohibited user-notice policy qualifiers remained in TLS certificate profiles after the September 2023 requirements change. Netlock reported that its profile review had missed the change.

These failures occurred despite earlier commitments to strengthen requirements tracking. In Bug 1656882, Comment 1, Netlock reported assigning compliance personnel responsibility for tracking and applying changes, analyzing new requirements, and checking deadlines. Later incidents demonstrate that assigning those responsibilities did not consistently ensure timely implementation or complete verification.

The more recent Bug 2084949, discussed in Issue J, reports use of a Precertificate Signing CA after the 15 March 2026 prohibition. The preliminary report states that Netlock confirmed the finding, while the full affected population remained under investigation. It adds a further example of a requirements transition not being reflected in an issuance path.

These incidents show gaps in requirements tracking, coverage of production paths, and verification before issuance. Completing a profile correction does not by itself establish that every path using the same configuration or workflow has been checked. Effective remediation requires verifying that the applicable checks cover new orders, renewals, pending orders, manual modifications, and precertificate issuance, as relevant.

Issues: Requirements implementation; testing coverage; linting; precertificate controls.

Issue F: CCADB disclosures were incomplete, incorrect, or insufficiently verified (2024–2026)

F.1. Four intermediate certificates were not disclosed on time

Bug 1904041 documents four intermediate CA certificates not disclosed within the required period. Netlock initially asserted that disclosure had been completed, but had entered different certificates with the same subject names and public keys under a root not yet trusted by participating programs.

Rob Stradling repeatedly explained the distinction. Netlock's later timeline places confirmation of the problem on 19 June 2024 and correct disclosure on 18 July. Netlock acknowledged insufficient experience and process controls. It reported a disclosure checklist, checker tool and additional training.

The incident illustrates why disclosure must identify the specific certificate, rather than merely another certificate containing the same subject name and public key.

The earlier allegation concerning an additional fifth certificate was withdrawn in Comment 6 because that certificate did not chain to a trusted root. It is not included here as a separate violation.

F.2. CRL URL disclosure failures recurred

Bug 2001327 concerns missing CRL distribution-point disclosures. Netlock expanded the affected set to four unused CA certificates, reported revoking them in December 2025, and introduced recurring weekly disclosure checks.

In Bug 2075258, Comment 5, Netlock expressly acknowledged recurrence. CCADB contained a CRL URL variant on one host while certificates used different URLs across three hosts. The earlier weekly check had not caught the discrepancy. Its October report also acknowledged missing its own 29 September correction date; a disclosed RQSCD CRL URL returned HTTP 404 during its checks.

This discrepancy affected oversight as well as metadata accuracy: monitors using CCADB could retrieve a different CRL from the one used by relying parties following certificate distribution points. The related publication of different CRL contents under the same cRLNumber is addressed in Issue G.3.

The subsequent gaps in reporting the status of corrective actions are addressed in Issue A.3. The disclosure concern here is that a recurring check previously reported as implemented did not detect another mismatch between CCADB disclosures and the URLs actually used in certificates.

Issues: Disclosure accuracy; verification; certificate identity; ineffective monitoring.

Issue G: Revocation information was stale, incorrectly encoded, inconsistent, or incomplete (2023–2026)

G.1. Earlier CRL and revocation-reason failures

In Bug 1819105, the disclosed CRL for NETLOCK Trust EV CA 3 had a nextUpdate in 2020 when reported in 2023. Netlock explained that the CA was used for test certificates and monitored at the infrastructure level rather than with sufficient checks of the published CRL.

Bug 1830823 records use of certificateHold for precertificates. The issue was identified during a different discussion, and a community member opened the separate incident after Netlock had not done so.

Bug 1843173 records a further stale-CRL incident in July 2023, affecting NETLOCK DVCA. Netlock explained that a manually copied CRL file had incorrect permissions, preventing the automatic publication task from replacing it. Monitoring detected the problem, but a misspelling in the alert rule prevented notification. This followed the infrastructure-monitoring improvements reported in Bug 1819105.

In Comments 4 and 6, Netlock reported using external monitoring of crlwatch and ocspwatch, with push notifications to staff devices. The later OCSP alerting gap discussed in Issue H.2 raises a further question about whether those earlier monitoring improvements continued to provide effective notification.

Bug 1938167 records CRLs served in PEM rather than DER encoding. Netlock reported correcting the files, changing publication validation, and integrating linting. The closure account explicitly identified a lack of encoding enforcement in CRL and AIA publication processes.

G.2. Reason-code remediation did not cover all affected paths and entries

Bug 2011314 concerned an explicit unspecified (0) reasonCode in a CRL. Netlock reported remediation and verification before closure in June 2026.

Nevertheless, Bug 2075255, Comment 6 acknowledged recurrence across several CAs. Automatic revocation after a suspension period still wrote explicit reasonCode 0. Netlock's 14 October update stated that the fix had passed tests but was not yet deployed. The incident illustrates incomplete coverage of a shared workflow rather than merely retention of historical entries.

The preliminary report in Bug 2088080, filed in November 2026, describes a separate reason-code omission. According to the report, the Gold root CRL contained an entry for the revoked CA certificate NetLock OnlineSSL (Class Online) Tanúsítványkiadó without a reasonCode extension. The report states that the entry carried explicit reasonCode 0 on 6 October 2026, but that the extension was subsequently removed rather than replaced with a permitted reason.

This differs from the explicit reasonCode 0 defect: the report identifies the revoked certificate as a CA certificate for which a reasonCode was required, so omitting the extension would not resolve the issue. It also states that this entry, with a revocation date in 2021, fell outside the population described in Bug 2075255's Full Incident Report, which counted entries revoked on or after 15 July 2023. The preliminary report therefore raises an additional question about the completeness of the reason-code investigation and remediation; its full scope and explanation remained to be established.

G.3. Different CRL contents were published under the same number

The full report in Bug 2075720, Comment 2 states that 13 of 16 CRLs in the Gold hierarchy had different contents under the same cRLNumber across two URL variants in its 9 October 2026 measurement. The variants did not contain an Issuing Distribution Point distinguishing their scopes. Another CRL lacked cRLNumber entirely.

The root CRL was also reported to change at a single URL without an increased number or updated issuance time. Netlock acknowledged that its monitoring did not compare the variants. Its report said the observed differences concerned expired certificates in the cases examined, while verification of that conclusion across the entire population remained an action item.

Issues: Revocation-data integrity; scope assessment; monitoring; incomplete remediation.

Issue H: Publication and status-service checks did not verify the required behavior (2025–2026)

H.1. AIA encoding failures survived earlier publication improvements

Bug 2004699 records issuer certificates served in PEM rather than DER from AIA HTTP endpoints. Later investigation broadened the affected endpoint population and identified a regression.

In Comment 49, Netlock reported successful external verification of the encoding fix on 2 October 2026. It subsequently reported that the fix continued to hold. However, Comments 50–51 recorded missed commitments to provide the updated full report, explain the regression, and reconcile the published AIA inventory against internal issuance records.

In Bug 2052541, Comment 19, Netlock acknowledged that the updated Full Incident Report promised for 21 October had not been posted. The regression analysis and inventory reconciliation remained unfinished. The operational correction and the unfinished investigation should be assessed separately; the related reporting failures are addressed in Issue A.3.

H.2. OCSP did not recognize an issued certificate

Bug 2051459 records an issued certificate not propagated to the OCSP responder. The responder returned unknown for approximately eleven days in June 2026. Netlock identified missing synchronization verification and dedicated monitoring, later acknowledged the detection delay, and reported a subsequent reconciliation of its valid TLS certificate inventory against responder status.

In Comment 26, Netlock explained that OCSP Watch published problems on its website and through CSV feeds rather than sending notifications, and that the June signal had therefore reached nobody. This raises a question about the continuing effectiveness of the external monitoring and push notifications reported in 2023, discussed in Issue G.1. Availability of an external status page or feed did not, by itself, ensure that a problem would reach responsible personnel.

Netlock reported implementing five-minute polling of its OCSP Watch feed, with critical alerts paging the on-call engineer. It also described separate alerts for prolonged feed retrieval or validation failures and for failure of the polling process itself. Netlock reported exercising that notification path in a drill on 9 October 2026, one day after its committed completion date.

That reported improvement addressed the external notification path. The same update stated that the separate internal check for newly issued certificates missing from the OCSP responder, including its synthetic-gap test, was not yet live. The two controls address different gaps and should not be treated as interchangeable.

H.3. Test sites did not present the required certificate states

Bug 1962426 records a designated valid test site serving an expired certificate in April 2025. Bug 1979287 records a July 2025 finding that the revoked test site instead served an expired certificate; Netlock described a manual maintenance process that omitted the revocation step. These are further examples of checks failing to verify the intended externally visible state.

H.4. Policy-document repository availability

Bug 2021559 records a March 2026 document-repository outage. Netlock attributed it to excessive requests, database-connection exhaustion, and corruption of supporting tables. General website monitoring did not specifically check document downloadability. Its closure material reported restoration, targeted monitoring, and architectural improvements. This incident was internally detected and should not be characterized as exclusively dependent on external reporting.

Issues: End-to-end verification; inventory reconciliation; service monitoring; operational resilience.

Issue I: Audit findings and audit-document identification weaknesses (2021–2024)

Bug 1716874 concerns an intermediate CA apparently missing from audit reports. Netlock explained that the report contained an incorrect SHA-256 fingerprint, requiring clarification of the certificate's identification. This should not be described as a proven unaudited period without examining the corrected evidence.

Bug 1917046 records four groups of findings in Netlock's 2024 audit: incomplete asset inventories; missing information in backup-restoration test records; crisis-management documentation and testing deficiencies; and supply-chain evaluation that omitted cybersecurity requirements. Netlock later reported completing the corrective actions, and the bug was resolved FIXED.

Issues: Assurance; inventory completeness; documented testing; organizational controls.

Issue J: Recent reports requiring continued investigation (October–November 2026)

Bug 2083866 records a third-party report that CCADB policy-document disclosures lagged versions published in Netlock's repository. The report also raised the availability of an English policy version and continuity of policy versions. The preliminary report does not establish every allegation as a completed Mozilla finding. Its observation that a CRL has a twelve-month validity interval is not, by itself, treated here as proof of a violation.

In Comment 1, Netlock stated that it had updated the CCADB record to the currently effective policy documents, including their English versions, and marked earlier versions as superseded. It also stated that the case was pending root program review and promised a Full Incident Report by 2 November 2026. The 5 November public comment noted that the promised report had not been posted. The claimed disclosure correction should be distinguished from completion of the incident investigation and reporting obligations; the reporting gap is also addressed in Issue A.3.

Bug 2084949 reports use of a Precertificate Signing CA after the 15 March 2026 prohibition. The preliminary report identifies a precertificate signed on 20 October 2026 and states that Netlock confirmed the finding; a subsequent comment confirms receipt and the CA's constrained role while verification was underway. The full affected population and explanation of the missed transition were still being determined in the retrieved record.

Bug 2088080, filed in November 2026 and discussed in Issue G.2, adds a report of a missing reasonCode for a revoked CA certificate. Its preliminary account raises a further question about the scope of earlier reason-code remediation, while the full investigation remained outstanding.

These reports add unresolved questions about requirements implementation, disclosure, and the completeness of remediation. The cumulative concerns above do not depend on assuming the broadest possible interpretation of these recent reports.

Action by another root program

On 30 May 2025, Google Chrome announced withdrawal of default trust for newly issued TLS certificates chaining to the NetLock Arany (Class Gold) Főtanúsítvány root. Chrome cited recurring compliance failures, unfulfilled improvement commitments, and insufficient demonstrated progress. Its constraint applies in Chrome 139 and later when a certificate's earliest SCT is after 31 July 2025 at 23:59:59 UTC.

Source: Chrome Root Program announcement.

This is relevant external context. Mozilla's assessment rests on the underlying public record and its own expectations for continued inclusion.

Cumulative assessment

The record supports concern about Netlock's sustained operational and compliance capability across multiple functions. Earlier incidents produced commitments concerning reporting, training, ownership, disclosure checks and technical validation. Later incidents documented recurrence and identified limitations in the controls previously presented as corrective measures.

The record also raises concerns about the effectiveness of internal detection and escalation. Multiple defects were identified through third-party reports, while earlier commitments to monitoring, problem-report handling, and review of other CAs’ incidents did not consistently prevent recurrence. Initial discovery, subsequent expansion of an incident’s scope, and public disclosure are distinct activities; improvements in one do not establish the effectiveness of the others.

The concern is therefore broader than the number of individual bugs or the immediate severity of any one profile error. Effective CA operation requires detecting defects, establishing their complete scope, correcting all affected paths, meeting revocation and reporting deadlines, and demonstrating that the corrections continue to work. The recurring combination of incomplete coverage, externally prompted investigation, missed public commitments, and repeated reporting failures undermines confidence that those functions operate reliably.

Netlock has acknowledged failures, completed individual corrective actions, and provided some concrete verification results. Those improvements should be credited. They must also be evaluated against subsequent performance and the repeated failure of prior measures to prevent recurrence. A newly implemented control provides a basis for further verification; implementation alone does not establish sustained effectiveness.

Related records and scope qualifications

• Bug 2032939 and Bug 2033033 concern Netlock's dual-purpose-root transition. In Bug 2033033, Mozilla stated that allowing the root to expire on 6 December 2028 satisfied the substantive separation requirement. These records are context, not proof that Netlock has already violated the end-of-2028 deadline.
• Bug 1978904 concerns Netlock's request to include new TLS and S/MIME roots. Netlock stated that it would update the ticket shortly; Mozilla subsequently noted that the associated CCADB case was stale and had no roots attached. This is context concerning progress on the proposed replacement hierarchy, not a separate incident-reporting violation.
• Bug 1824435 was resolved INVALID regarding SCTs from an untrusted log. That allegation is not counted as a compliance failure; the separately identified certificateHold issue is addressed in Bug 1830823.
• Bugs 1891331 and 1947691 represent the same delayed-revocation episode. Bugs 1905509 and 1906115 contain related material about the same 2024 reporting-contact problem. References to an event in multiple sections describe its different implications and do not represent additional independent incidents.
• Initial discovery, subsequent expansion of the affected scope, and public disclosure are distinct activities. A CA's filing of a report does not by itself establish internal detection, while a third-party report does not exclude subsequent useful investigation by the CA. No numerical proportion of externally detected incidents is asserted here without a defined and verified incident inventory.
• Root inclusion requests and routine root transitions are not themselves evidence of non-compliance. No assertion of current audit delinquency is made here without the relevant audit records, submission history, applicable deadlines, and any auditor explanatory letter being verified.

Bug reference index

Subject	Bug references
Early misissuance and incident communication	1391056; 1401211; 1462423; 1572992
2019–2020 intermediate EKU and delayed revocation	1586795; 1656882
2020 profile, validation and revocation incidents	1676367; 1676440; 1680378; 1688844
Audit identification and findings	1716874; 1917046
2023 CRL, profile and revocation issues	1819105; 1820174; 1822809; 1830823; 1843173
2024 policy qualifiers and delayed revocation	1889570; 1891331 (superseded); 1947691
Intermediate disclosure and CPR handling	1904041; 1905509; 1906115
Publication encoding	1938167; 2004699
Updates and reporting requirements	1957474; 2007948; 2013395; 2013400; 2063842
Test-site states	1962426; 1979287
CRL URL disclosure	2001327; 2075258
CRL reasons and numbering	2011314; 2075255; 2075720; 2088080
Document-repository availability	2021559
OCSP and 2026 CPR handling	2051459; 2052541
Recent policy disclosure and precertificate reports	2083866; 2084949
Context or exclusions	1824435; 1978904; 2032939; 2033033