2037000 - D-Trust: Missing Pre-Sign Linting for S/MIME Issuing CAs

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Laura Martorano]

Preliminary Incident Report

Summary

• Incident description: As part of a broader internal compliance review initiated following Bugzilla incident 2029013, D-Trust identified that pre-sign linting, as required under Section 4.3.1.2 of the S/MIME Baseline Requirements, was not implemented for specific S/MIME issuing CAs, resulting in non-compliance with this requirement for certificates issued by those CAs after the effective date of the requirement.

  The affected CAs were part of a lifecycle transition and subsequently remained in use beyond the effective date of the requirement, and this gap was not identified.

  Upon identification on 2026-05-04 at 08:30 UTC, D-Trust ceased issuance from the affected CAs at 09:17 UTC to prevent further non-compliant issuance, and has since migrated issuance to compliant infrastructure.

  D-Trust will revoke all affected certificates in accordance with the requirements and will provide an update to confirm completion.

• Relevant policies: CA/Browser Forum S/MIME Baseline Requirements, Section 4.3.1.2

• Source of incident disclosure: Self Reported (Internal review based on the action items in Incident 2029013)

Comment 1

[Ana Laura Martorano]

D-Trust confirms that all revocations were completed in accordance with the timelines defined in the CA/Browser Forum S/MIME Baseline Requirements (Section 4.9.1.1).

Root cause analysis and follow-up action items will be provided in the forthcoming Full Incident Report.

Comment 2

[Ana Laura Martorano]

Attachment: id-2037000_List-of-Certificate-serial-numbers-of-the-affected-certificates.zip.002

Bug 2037000 Certificate List zip

Comment 3

[Ana Laura Martorano]

Attachment: id-2037000_List-of-Certificate-serial-numbers-of-the-affected-certificates.zip.001

Bug 2037000 Certificate List part1

Comment 4

[Frank Meißen]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description: D-Trust has issued S/MIME certificates in violation of section 4.3.1.2 of the S/MIME Baseline Requirements. The non-compliant issuance period ran from 15 September 2025 to 4 May 2026.
• Timeline summary:
  • Non-compliance start date: 2025-09-15
  • Non-compliance identified date: 2026-05-04 08:30 (UTC)
  • Non-compliance end date: 2026-05-04 09:17 (UTC) issuance stopped
• Relevant policies: CA/Browser Forum S/MIME Baseline Requirements Section 4.3.1.2
• Source of incident disclosure: Self-Reported (Internal review based on the action items in Bugzilla Incident 2029013)

Impact

• Total number of certificates: 165,972
• Total number of "remaining valid" certificates: 0
• Affected issuing CAs: E.ON CA 2 2013 XXI, E.ON CA 2 2013 XXIII, D-Trust Application Certificates CA 3-1 2013
• Affected certificate types: S/MIME
• 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-05-04 09:17 (UTC) to prevent further issuance without a compliant pre-sign linting control. D-Trust has since migrated issuance to compliant infrastructure.
• Analysis: N/A
• Additional considerations: All certificates that were still valid have been revoked by 2026-05-08 22:02 (UTC)

Timeline (UTC)

• 2024-11-22 Revision SMC09 Ballot
• 2025-03-15 Ballot SMC09 “SHOULD implement pre-issuance linting of S/MIME Certificates, and SHOULD implement use of Linting in Self-Audits” has been implemented in the non-affected CAs
• 2025-09-15 Ballot SMC09: “SHALL implement pre-issuance linting of S/MIME Certificates” has been implemented in the non-affected CAs
• 2026-03-15 https://bugzilla.mozilla.org/show_bug.cgi?id=2023458 , “D-Trust: TLS Precertificates Exceeding the Maximum Validity Period Allowed by the TLS Baseline Requirements”
• 2026-04-02 https://bugzilla.mozilla.org/show_bug.cgi?id=2029013 , “D-Trust: Missing Pre-Signing Linting for TLS Issuance”
• 2026-04-16 action item of https://bugzilla.mozilla.org/show_bug.cgi?id=2029013 initiated (“Documented review of all applicable requirements, supported by third-party sample audits to ensure objective verification”)
• 2026-05-04 07:00 (UTC) Start Review of S/MIME CAs
• 2026-05-04 08:30 (UTC) D-Trust identified that pre-sign linting, as required under Section 4.3.1.2 of the S/MIME Baseline Requirements, was not implemented for specific S/MIME issuing CAs and opened an internal incident ticket
• 2026-05-04 09:17 (UTC) D-Trust stopped issuance from the affected part of its PKI
• 2026-05-04 09:25 (UTC) Internal preparation for external communication
• 2026-05-04 12:40 (UTC) Start External communication
• 2026-05-06 7:56 (UTC) Bugzilla ticket with Preliminary Incident Report created https://bugzilla.mozilla.org/show_bug.cgi?id=2037000
• 2026-05-08 15:00 (UTC) Start of mass revocation of certificates.
• 2026-05-08 22:02 (UTC) Mass revocation successfully completed

Related Incidents

| Bug | Date | Description |
| 2033000 | 2026-04-17 | SwissSign: Certificate Profile error for S/MIME MV |
| 2029013 | 2026-04-02 | Missing Pre-Signing Linting for TLS Issuance |
| 2023458 | 2026-03-15 | TLS Pre-certificates Exceeding the Maximum Validity Period Allowed by the TLS Baseline Requirements |
| 1974592 | 2025-06-28 | Similarities in pre-issuance compliance control failures, specifically around inadequate enforcement of mandatory linting/validation requirements |
| 1936906 | 2024-12-12 | DigiCert: Invalid Characters in S/MIME Subject Fields |
| 1885132 | 2024-03-13 | Related due to deficiencies in automated pre-issuance compliance validation |
| 1690807 | 2021-02-04 | GlobalSign: RSA-1024 leaf certificate issued after 2013-12-31 |

Root Cause Analysis

Contributing Factor 1: Lifecycle-transition CAs were excluded from mandatory requirement implementation based on operational assumptions

• Description: D-Trust decided not to implement S/MIME BR §4.3.1.2 pre-sign linting controls on three S/MIME issuing CAs because those CAs were expected to cease issuance before the requirement effective date of 2025-09-15. The decision was based on an operational retirement assumption rather than on the actual technical issuance capability of the CAs. As a result, the affected CAs remained capable of issuing certificates without the required pre-sign linting controls after the requirement became effective.
• Timeline: 2025-09-15 to 2026-05-04
• Detection: Internal compliance review initiated following Bugzilla Bug 2029013.
• Interaction with other factors: This factor created the initial compliance gap by excluding the affected CAs from implementation of mandatory controls. Contributing Factor #2 allowed this exclusion to persist after the operational retirement assumptions changed and the CAs continued issuing certificates. Contributing Factor #3 prevented the gap from being independently identified through inventory-based compliance verification activities.
• Root Cause Analysis methodology used: Five Whys

Contributing Factor 2: No formal reassessment process existed for lifecycle-transition CAs when operational assumptions changed

• Description: The affected CAs remained in active use beyond their originally planned retirement timeline. However, D-Trust did not have a formal control requiring reassessment of compliance obligations when lifecycle-transition assumptions changed or when issuance continued beyond planned decommissioning dates. As a result, the original decision to exclude these CAs from implementation of S/MIME BR §4.3.1.2 was not revisited despite continued issuance activity.

• Timeline: 2025-09-15 to 2026-05-04

• Detection: Review of CA lifecycle management records, issuance activity, and change management documentation.

• Interaction with other factors: This factor allowed the initial exclusion decision described in Contributing Factor #1 to remain in effect after the underlying assumptions were no longer valid. Because no reassessment was triggered when issuance continued, the affected CAs remained non-compliant for an extended period. Contributing Factor #3 further amplified the issue because no independent inventory-based verification process existed to identify that the original assumptions had become invalid.

• Root Cause Analysis methodology used: Five Whys

Contributing Factor 3: Requirement implementation verification was not inventory-driven across all technically capable issuing CAs

• Description: D-Trust did not maintain a compliance verification process that mapped newly effective CA/B Forum requirements against the complete inventory of technically capable issuing CAs. Verification activities relied on operational ownership assumptions and expected CA retirement status rather than independently validating that all active or technically capable issuing CAs had either implemented the required controls or been technically prevented from issuing certificates. Consequently, the compliance gap affecting the three lifecycle-transition CAs was not identified until the broader internal review initiated after Bugzilla Bug 2029013.

• Timeline: 2025-09-15 to 2026-05-04

• Detection: Internal compliance review initiated following Bugzilla Bug 2029013.

• Interaction with other factors: This factor prevented independent detection of the issues created by Contributing Factor #1 and perpetuated by Contributing Factor #2. Because compliance verification activities were not systematically tied to the complete inventory of technically capable issuing CAs, the affected lifecycle-transition CAs were not identified as lacking mandatory controls despite continuing to issue certificates after the requirement effective date.

• Root Cause Analysis methodology used: Five Whys

Lessons Learned

• What went well: Once the compliance deficit was identified, D-Trust stopped certificate issuance, and issuance has since been migrated to compliant infrastructure. Revocation of all affected certificates that were still valid was completed within the timelines prescribed by the S/MIME Baseline Requirements §4.9.1.1.
  Notably, the response to this incident benefited directly from the learnings of Bug 2029013 (“D-Trust: Missing Pre-Sign Linting for TLS Issuance”). The process improvements implemented following that earlier incident, in particular with regard to internal and external communication and revocation workflows, demonstrably increased the efficiency and speed of D-Trust's response here.
• What didn’t go well: D-Trust lacked a formal control ensuring that CAs in lifecycle transition remained subject to newly effective baseline requirements and associated compliance validation activities.
• Where we got lucky: The non-compliance was discovered through a broader internal compliance review that D-Trust initiated as a follow-up to Bug 2029013 (“D-Trust: Missing Pre-Sign Linting for TLS Issuance”).
• Additional: D-Trust recognized that compliance, security, and operational controls for publicly trusted CAs must be applied consistently regardless of lifecycle or transitional status. Operational assumptions regarding future retirement or reduced usage must not result in exclusion from applicable compliance requirements while a CA remains technically capable of issuing certificates.

Action Items

The action items from Bug 2029013 are directly relevant to this incident and contribute to its remediation. In addition,

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
#1 Improve an inventory-driven compliance mapping process that requires every newly effective CA/B Forum requirement to be explicitly evaluated against all technically capable issuing CAs, regardless of lifecycle-transition or operational status	Prevent	Contributing Factor #1 and #3	A documented compliance inventory exists that maps each applicable requirement to every technically capable issuing CA, including implementation status, verification status, and operational state	2026-09-30	Ongoing
#2 Update the change management process to require reassessment of compliance obligations whenever lifecycle-transition assumptions, retirement timelines, customer usage, or issuance activity change for a publicly trusted CA	Prevent	Contributing Factor #2	The change management process includes mandatory reassessment triggers and approval checkpoints tied to operational or lifecycle changes affecting publicly trusted CAs	2026-08-30	Ongoing
#3 Update the change management and compliance governance processes to require that compliance, security, monitoring, validation, and operational controls continue to be applied consistently across all technically capable issuing CAs regardless of lifecycle-transition or operational status	Prevent	Contributing Factor #1 and #2	Change management procedures, implementation checklists, and compliance governance documentation explicitly require consistent control application and verification across all technically capable issuing CAs	2026-08-30	Ongoing
#4 Introduce independent inventory-based verification activities to confirm that all technically capable issuing CAs have implemented newly effective requirements or have undergone formally approved and verified decommissioning procedures	Detect	Contributing Factor #3	Internal compliance reviews and independent audits verify implementation status against the complete CA inventory and include evidence-based validation of issuance capability and control applicability	2026-09-30	Ongoing
#5 Expand post-incident review procedures to require cross-product and cross-hierarchy assessment of comparable compliance obligations following any CA/B Forum requirement implementation failure	Prevent	Contributing Factor #3	Post-incident procedures require documented evaluation of comparable controls across all applicable product lines, issuing hierarchies, and technically capable issuing CAs	2026-09-30	Ongoing

Appendix