2029013 - D-Trust: Missing Pre-Signing Linting for TLS Issuance

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Enrico Entschew]

Preliminary Incident Report

Summary

• Incident description: After conducting an in-depth internal analysis, supplemented by external expert review, D-Trust has concluded that its current RA-side configuration checks do not meet the definition of a 'linting tool' as intended by the industry. We now recognize that these internal checks do not fulfil the 'MAY' provision for internal linting tools in Section 4.3.1.2, Linting of to-be-signed Certificate content, as they lack the programmatic independence and technical rigor of a dedicated linting library. While the primary root cause of the validity error in Incident 2023458 remains a change management failure, we acknowledge that the absence of a technical, pre-sign 'fail-closed' linter was the critical preventive control failure that allowed this incident to reach the CT logs.
  D-Trust has stopped all issuance from the affected part of its PKI as of 2026-04-02 08:45 (UTC) to ensure no further non-compliant certificates are produced. Issuance was resumed on 2026-04-02 15:40 (UTC) after deploying a linting solution in the certificate issuance workflow that aligns with industry practices and enforces compliance with Section 4.3.1.2.
  D-Trust has concluded that all TLS certificates issued on or after March 15, 2025 are non-compliant with the TLS Baseline Requirements. D-Trust will revoke all affected certificates within the next five days and will report on the progress of the revocation.
• Relevant policies: CA/Browser Forum TLS Baseline Requirements, Section 4.3.1.2
• Source of incident disclosure: Internal review based on the discussion in Incident 2023458

Comment 1

[Enrico Entschew]

D-Trust confirms that all affected TLS certificates have been revoked.

Comment 2

[Christopher Kunz]

As an interested bystander, I was wondering if D-Trust has previously simulated such a mass revocation event, as mandated by Mozilla's Root Store Program, and if so, in what manner.

Comment 3

[Enrico Entschew]

(In reply to Christopher Kunz from comment #2)

As an interested bystander, I was wondering if D-Trust has previously simulated such a mass revocation event, as mandated by Mozilla's Root Store Program, and if so, in what manner.

Hi Christopher,

D-Trust has conducted mass revocation exercises on multiple occasions. The most recent exercises were performed on 2026-03-03 and again on 2026-03-24. The exercise on 2026-03-24 was conducted as part of an audit by an independent third party. These exercises were based on D-Trust’s existing mass revocation plan and were carried out with the internal process participants defined for such scenarios, taking into account the expectations set out in Mozilla’s Root Store Policy. Where external process participants would normally be involved, their roles were simulated by internal staff. The primary purpose of these exercises was to ensure that all involved parties understand their respective roles, responsibilities, and timing within the mass revocation process.

Best regards,
Enrico Entschew, D-Trust GmbH

Comment 4

[Enrico Entschew]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022

• Incident description:
  D-Trust has issued 57,565 certificates in violation of Section 4.3.1.2 of the TLS Baseline Requirements over a period of more than 12 months. The non-compliant issuance period ran from 15 March 2025 to 2 April 2026. Our mandatory preventive pre-sign technical controls that checked for conformance with the profiles and requirements defined in the TLS BRs and prescribed by Ballot SC-75 were insufficient. We acknowledge that these checks on the RA and CA sides were not sufficient compare to the industry-standard tools (ZLint and PKILint) regarding pre-sign-linting. This process violation directly resulted in the non-compliant precertificates signed with the CA-key as described in Incident 2023458.

• Timeline summary (all in UTC):

  • Non-compliance start date: 2025-03-15
  • Non-compliance identified date: 2026-04-02, 08:30
  • Non-compliance end date: 2026-04-02, 15:40

• Relevant policies: CA/Browser Forum TLS Baseline Requirements Section 4.3.1.2

• Source of incident disclosure: Internal review based on the discussion in Incident 2023458

Impact

• Total number of certificates: 57,565
• Total number of "remaining valid" certificates: 0
• Affected certificate types: DV, OV and EV TLS certificates
• Incident heuristic: 3
• Was issuance stopped in response to this incident, and why or why not?: Yes. D-Trust stopped issuance from the affected part of its PKI on 2026-04-02 08:45 (UTC) to prevent further issuance without a compliant pre-sign linting control. Issuance resumed after deployment of a compliant pre-sign linting solution in the certificate issuance workflow.
• Analysis: N/A
• Additional considerations: All affected certificates that were still valid have been revoked by 2026-04-07, 06:05 (UTC).

Timeline (UTC)

• 2024-05-20, 18:00 Discussion period of Ballot SC075 started.
• 2024-06-26, 10:00: Ballot SC075 voting concluded.
• 2024-08-06: Ballot SC075 came effective with first impact on 2026-03-15.
• 2024-08-15: D-Trust came to the conclusion that existing CA- and RA-side pre-sign technical controls that checked for conformance with the profiles and requirements defined in the TLS BR were sufficient to meet the “MAY” use of their own pre-sign certificate linting tools.
• 2024-09-15: “SHOULD” requirement for pre-sign-linting in TLS Baseline Requirements Section 4.3.1.2 enters into force.
• 2025-03-15: Mandatory "SHALL" requirement for pre-sign linting in TLS Baseline Requirements Section 4.3.1.2 enters into force. D-Trust continues to issue certificates using insufficient checks.
• 2026-03-15, 11:34: Incident 2023458 occurs. RA- and CA-side pre-sign technical controls fail to catch a 203-day validity error. D-Trust issued 19 non-compliant TLS Precertificates that were detected by the post-sign precertificate linter.
• 2026-03-15, 21:03: D-Trust filed the Incident 2023458 (D-Trust: TLS Precertificates Exceeding the Maximum Validity Period Allowed by the TLS Baseline Requirements.)
• 2026-03-16: Several comments are received on Incident 2023458 about when and how linting is performed.
• 2026-03-17: D-Trust discussed the comments around linting in context of section 4.3.1.2 of the TLS BRs and concluded that they should switch to widely adopted industry linting tools. We retained the incorrect conclusion that existing CA- and RA-side pre-sign technical controls were sufficient to meet the “MAY” use of their own pre-sign certificate linting tools.
• 2026-03-27, 12:48: D-Trust published the Full Incident Report on Incident 2023458.
• 2026-03-29, 15:23: Dimitris asked how our pre-sign linting process meets the expectations of Section 4.3.1.2 of the TLS BRs.
• 2026-03-30: The last comment of Dimitris was discussed and it was decided to bring in an external opinion.
• 2026-04-01: An external party evaluates the technical controls against 4.3.1.2 of the TLS BRs.
• 2026-04-02, 08:00: The conclusion of the external party were discussed.
• 2026-04-02, 08:30: D-Trust concluded that its existing RA- and CA-side pre-sign technical controls did not satisfy the expected linting requirement under Section 4.3.1.2 proven by Incident 2023458.
• 2026-04-02, 08:45: D-Trust stopped issuance from the affected part of its PKI.
• 2026-04-02, 15:37: D-Trust started the customer communication regarding the upcoming revocation of certificates
• 2026-04-02, 15:40: A compliant pre-sign linting solution (ZLint and PKILint) is deployed as a blocking hook; issuance resumes.
• 2026-04-07 06:05: All remaining affected TLS certificates that were still valid had been revoked.

Related Incidents

Bug	Date	Description
1534145	2019-03-10	P-384 curve / ecdsa-with-SHA256 certificates
1796803	2023-10-21	Issuance of ECC leaf certificates with non-DER encoded keyUsage
1974592	2025-06-18	Pre-Sign Linting Validation did not occur in ICA creation
2007116	2025-12-18	CRL URL Disclosure – CCADB disclosure entries did not exactly match the CRL URLs encoded in the corresponding certificates.
2009149	2026-01-06	Expired certificate provided on the CA TLS test website – Misinterpretation of Chrome Root Program Policy trigger conditions during rollover transition.
2023458	2026-03-16	Incident 2023458 exposed the absence of a compliant pre-sign linting control and triggered the broader internal review that resulted in Bug 2029013.

Root Cause Analysis

Contributing Factor #1: Incorrect Technical Assessment of Ballot Requirements

• Description: D-Trust monitored the adoption of Ballot SC-075 but reached a conclusion during the gap analysis. The organization erroneously assumed that the existing CA- and RA-side pre-sign technical controls that checked for conformance with the profiles and requirements defined in the TLS BR were sufficient to meet the “MAY” use of their own pre-sign certificate linting tools. We failed to recognize that the intent of the ballot was to mandate independent, programmatic validation using widely adopted industry linting tools prior to signing the precertificate with the CA key.
• Timeline: 2024-05-20 to 2026-04-02
• Detection: The issue was detected through internal investigation using the 5 Whys methodology.
• Interaction with other factors: The interpretation of the ballot requirements led D-Trust to place reliance on its existing CA- and RA-side pre-sign technical controls that checked for conformance with the profiles and requirements defined in the TLS BR were sufficient to meet the “MAY” use of their own pre-sign certificate linting tools. This highlights that although the introduced procedure in incident 2007116 prevents this type for incident from occurring in the future it does not address prior policy changes.
• Root Cause Analysis methodology used: 5 Whys Methodology

Lessons Learned

• What went well: Once the control deficiency was identified, D-Trust stopped issuance, implemented a dedicated pre-sign-linting solution based on ZLint and PKILint in the issuance workflow, and completed revocation of the affected certificates that were still valid within the set timelines by the TLS BRs.
• What didn’t go well: D-Trust relied for too long on RA-side and CA-side checks that did not meet the expected standard for a pre-sign linting process under Section 4.3.1.2, proven by Incident 2023458. Furthermore, the flawed interpretation of the ballot requirements was not identified at an earlier stage, which delayed recognition of the control deficiency.
• Where we got lucky: The broader compliance issue was surfaced through the investigation of Incident 2023458 before further separate incidents could occur.
• Additional: The incidents documented in Bug 2007116 and Bug 2009149, together with the present incident, reflect a recurring pattern in which external requirements – whether from ballots of the TLS Baseline Requirements, the EV Guidelines for TLS Server Certificates, or Browser Root Store Programs – were not interpreted or assessed with the necessary precision. In response, D-Trust has decided to reevaluate all requirements and implemented controls to fulfill the CA/Browser Forum and Root Program requirements. This process will be supplemented with external checks. D-Trust is committed to reporting on the findings.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Deploy a linting solution in the certificate issuance workflow aligned with TLS Baseline Requirements Section 4.3.1.2 for pre-sign-linting	Prevent	Root Cause #1	Pre-sign-linting solution is active in the certificate issuance workflow before issuance resumes	2026-04-02	Complete
Revoke all affected TLS certificates issued on or after 2025-03-15 that were still valid	Correct	Root Cause #1	All affected TLS certificates that were still valid are revoked	2026-04-07	Complete
Reevaluate all requirements and implemented controls to fulfill the CA/Browser Forum and Root Program requirements	Prevent	Root Cause #1	Documented review of all applicable requirements, supported by third-party sample audits to ensure objective verification	2026-09-30	Ongoing

Appendix

Please see the uploaded CSV file

Comment 5

[Enrico Entschew]

Attachment: List of Certificate serial numbers of the affected certificates.csv

List of Certificate serial numbers of the affected certificates

Comment 6

[Bernd Schmidt]

I have a question regarding this incident that is addressed to the browser vendors of the CA/Browser Forum rather than D-Trust.

Following the revocation of the certificates by D-Trust, some members of the public noted that although the certificates were listed as revoked in the CRL, certain browsers (specifically Google Chrome and Microsoft Edge) did not flag them as revoked when they were still in use on some websites. In contrast, Mozilla Firefox was noted for correctly identifying these certificates as revoked shortly after the revocation, suggesting that there is not a universal technical limitation.

Is there a specific reasoning that explains why CAs must adhere to strict revocation deadlines when browser vendors do not seem to respect CRLs? Furthermore, if this incident had been caused by an actual security threat rather than a formal error, would the reaction time on the browser side be different, and how would this be enforced?

Comment 7

[Ben Wilson]

Hi Bernd,

Thanks for your questions.

With regard to certificate revocation, there are two separate responsibilities that are intentionally decoupled: CAs are required to revoke certificates and publish revocation status within defined timelines. Browsers, in turn, determine how to consume that information and enforce it for users. These functions operate differently and are not designed to be tightly coupled in their performance.

The requirement for timely revocation exists so that accurate revocation information is available as quickly as possible from the authoritative source. That requirement does not depend on any specific browser’s revocation checking behavior. (In fact, this diversity in browser behavior can sometimes provide defense-in-depth.) Browser enforcement is complex in practice and involves trade-offs between security, performance, privacy, and reliability at scale. Factors include, but are not limited to:

• the use of CRLs vs. OCSP vs. aggregated mechanisms (e.g., CRLite, CRLsets, OneCRL);
• update frequency, distribution models, and caching;
• prioritization based on revocation type/reason (e.g., key compromise vs. administrative replacement);
• soft-fail vs. hard-fail behavior.

In answer to your second question: yes, in cases involving active security threats, browser vendors can and do respond more aggressively (e.g., pushing updates to block affected certificates). Those actions complement, but do not replace, the CA’s obligation to revoke promptly.

I'll end my response here because really a deeper discussion of revocation behavior and trade-offs across browsers would be better suited to the Mozilla dev-security-policy list, the CCADB public list, or the CA/Browser Forum Server Certificate Working Group.

Thanks again,

Ben

Comment 8

[Enrico Entschew]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.
We request that the deadline for the next update be set for August 29, 2026.