2009149 - D-Trust: Expired certificate provided on the CA TLS test website for demonstration of valid certificates

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Laura Martorano]

Preliminary Incident Report

Summary

• Incident description: We received a certificate incident report via web form informing us that a publicly disclosed TLS test website to demonstrate a valid-certificate is serving an expired end-entity TLS certificate
• Relevant policies: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.2.1, Effective 16-December-2025, 2.2
• Source of incident disclosure: Third party reported

Comment 1

[Ana Laura Martorano]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description: We received a certificate incident report via web form informing us that a publicly disclosed TLS Test Website – Valid endpoint was serving an expired end-entity TLS certificate.
• Timeline summary:
  • Non-compliance start date: 2025-11-04 19:05 UTC
  • Non-compliance identified date: 2026-01-06
  • Non-compliance end date: 2026-01-15 15:52 UTC
• Relevant policies: CA/Browser Forum TLS Baseline Requirements v2.2.2 (effective 2026-01-12), Section 2.2 in combination with Chrome Root Program Policy, Section 4.1.2
• Source of incident disclosure: Third party reported

Impact

• Total number of certificates: 1
• Total number of "remaining valid" certificates: 0 (during the non-compliance window)
• Affected certificate types: TLS test certificate used for Test Website – Valid demonstration (OV)
• Incident heuristic: 3
• Was issuance stopped in response to this incident, and why or why not?: No. The condition resulted from an intentional issuance stop as part of a rollover transition plan, based on an incorrect interpretation of policy trigger conditions (see Root Cause Analysis).
• Analysis: N/A (no revocation-delay aspect).
• Additional considerations:

Timeline

2025-07-14: Cross-signing of the Applicant CA / rollover hierarchy performed as part of the rollover transition plan (Cross signing of D-TRUST BR Root CA 1 2020 and D-TRUST BR Root CA 2 2023 by D-TRUST Root Class 3 CA 2 2009).
2025-09-15 19:05: Last valid test certificate issued for the test web pages prior to the issuance stop.
2025-10-11: Issuance from the current cross-signing hierarchy (planned for retirement post-rollover) was stopped, including issuance of test certificates for the CCADB-disclosed test web pages.
2025-11-04 19:05: Deployed Test Website – Valid certificate reached NotAfter and became expired (non-compliance start).
2026-01-06 14:38: Third-party report received.
2026-01-06: Internal validation confirmed the endpoint served an expired certificate and traced this to the earlier issuance stop decision.
2026-01-15 15:52: Valid certificates restored on the test web pages (non-compliance end).

Related Incidents

Bug	Date	Description
1947207	2025-02-10	Test Website – Valid publication issue
2008847	2026-01-06	Test website certificates expired

Root Cause Analysis

Contributing Factor #: Misinterpretation of Chrome Root Program Policy trigger conditions during rollover transition

• Description: D-Trust misinterpreted Chrome Root Program Policy Section 4.1.2 by assuming cross-signing an Applicant CA implies it is already “first distributed” by the Chrome Root Store, and therefore treated the 90-day succession expectations as starting from that point.
  Following the cross-signing performed on 2025-07-14, D-Trust applied this assumption operationally and ceased issuance from the current cross-signing hierarchy (planned for retirement post-rollover), including test-certificate renewal for Test Website – Valid. This ultimately led to the deployed certificate expiring on 2025-11-04 19:05 UTC, creating non-compliance with TLS BR Section 2.2

• Timeline: 2025-10-11 – 2026-01-15

• Detection: Third party reported

• Interaction with other factors: None.

• Root Cause Analysis methodology used: 5 Why Method

Lessons Learned

• What went well:
• The issue was validated quickly after notification, and the causal chain was confirmed promptly.
• Monitoring/alerting and automated renewal mechanisms existed; the observed state resulted from an intentional issuance decision rather than an undetected technical malfunction.
• What didn’t go well: Policy requirement analysis and interpretation handling did not include an explicit, independent validation step focused on validating the interpretation itself and the downstream operational implications for rollover decisions.
• Ecosystem observation (policy-change feedback visibility): In our experience, identifying a potential misinterpretation early is difficult when there is no external signal that an interpretation is disputed. We suggest exploring a public discussion venue (or publication of anonymized/aggregated feedback themes) for planned Chrome Root Program Policy changes—similar to Mozilla’s dev-security-policy forum—to provide an exchange mechanism focused on clarifying intent and interpretation of changes. This is not intended to be a voting, ranking, or value-judgement mechanism for proposed changes; rather, it would help participants develop a shared understanding of triggers, scope, and operational implications, thereby reducing the likelihood of latent misinterpretations beyond one's own point of view. This would be complementary to our internal preventive controls, not a substitute for them.
• Where we got lucky: There was no misissuance; the issue was limited to an expired certificate on a disclosed test web page.
• Additional: - Terminology: this report uses “current cross-signing hierarchy (planned for retirement post-rollover)” to avoid the misleading connotation of “legacy” while still distinguishing the hierarchy that is planned to be retired after successful rollover.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Restore valid certificates on test web page	-	Root Cause # 1	test web page with valid certificate is online	2025-01-15	Completed
Implement advanced control validation for policy updates (internal, objective third-party validation of policy interpretation)	Prevent	Root Cause # 1	Documented process	2025-02-01	Ongoing please see Bugzilla 2007116

Appendix

Affected root CA Certificate
D-TRUST Root Class 3 CA 2 2009: https://crt.sh/?sha256=49E7A442ACF0EA6287050054B52564B650E4F49E42E348D6AA38E039E957B1C1
Last valid certificate for test web page
https://crt.sh/?sha256=0EA229ABA03508BB693FDF5B1C4D06486AD5EFC473A90E24606F9AE322D13506
Restored valid certificate for test web page
https://crt.sh/?sha256=7979DCA71783CF589E8C5EB092C8AC3244E48661A599C25B08107EC2B6C1D97D

Comment 2

[Ana Laura Martorano]

There are currently no updates to this issue. We continue to monitor this ticket.

Comment 3

[chrome-root-program]

Thank you for this report. As a general comment, it seems that D-TRUST Root Class 3 CA 2 2009 is hosting an expired certificate for the Test Website - Revoked URL (i.e., https://certdemo-ov-revoked.ssl.d-trust.net/).

(Q1): While D-Trust hinted at some illustrative direction in 2007116, how will this "internal third-party" be selected and qualified?

(Q2): How can the community have confidence that D-Trust’s proposed "internal, objective third-party validation" will be effective? The “Evaluation Criteria” listed does not offer any detail.

Comment 4

[Enrico Entschew]

Thank you for the info and the questions. We renewed the revoked test certificate.

Answer to (Q1): The objective third-party participants are selected from employees with experience in the relevant fields. A quality management and compliance background is a prerequisite. The participant composition must vary to ensure maximum objectivity.

Answer to (Q2): This will be validated by the dedicated conformity assessment. Any deviations would then be treated as findings within the audit.

Comment 5

[Dean F. Reed]

I read the initial report in Comment 1 and the response from D-TRUST to the questions in Comment 3, and I am finding they are lacking of specific and actionable details. How is D-TRUST believing that this minimal effort is demonstrating their seriousness regarding the compliance incidents? Is D-TRUST viewing the incident reporting process only as bureaucracy to be dismissed, rather than a critical mechanism for transparency and improvement? The response is offering zero utility to understand how this issue will be reliably prevented in the future.

The latest response is stating that the community should rely on audits to verify the commitments of D-TRUST. Given the patterns which are observed with the incident history of D-TRUST, this argument is logically unsound.

Many of D-TRUST’s bugzilla reports describe clear violations of the BR or RFC 5280 that the auditor did not recognize. If the audit framework was failing to detect such violations for multiple years, as it was the case of failing to detect the ongoing CRL violation in Bug 2010600, why should the community accept that same auditor and framework to guarantee the accurate evaluation of future compliance? This is especially troublesome since the new controls in this report are lacking any level of detail an auditor can check for.

Instead of the reference to the mechanism that has already proven to be blind to this issue, D-TRUST should present the technical evidence of the controls and improvement. Ultimately, the reliance on the "periodic audits" or the "human promises" is being wholly insufficient - and is proven so by history.

Ultimately, I cannot envisage how the new personnel, with presumably less experience than the existing team, will be meaningfully improving this situation. If the new personnel has greater competence and will detect lurking issues, why are they not already involved?

Comment 6

[Enrico Entschew]

Thank you for the follow-up and for articulating your concerns. We understand the expectation that commitments in incident reports must be supported by concrete and verifiable mechanisms, rather than by general assurances.

1. Policy interpretation and translation into enforceable controls
   We have identified the interpretation of normative policy changes and their translation into technical and operational requirements as a critical risk area. Every normative policy change is therefore processed through a structured internal workflow: policy requirements are analyzed, translated into explicit implementation measures, and—where technically feasible—supplemented by automated or procedural checks intended to assess implementation quality.
   These results are not accepted at face value. They must be reviewed and defended against scrutiny by an internal review function from outside the responsible department. This challenge principle is mandatory for every normative policy change and is intended to surface blind spots and implicit assumptions before changes are finalized.

2. Evidence beyond periodic audits
   We agree that periodic audits alone are not sufficient to demonstrate the effectiveness of ongoing compliance controls. Audits are an important ex-post verification mechanism, but they do not replace continuous internal controls. The mandatory challenge process described above creates documented artifacts (e.g., interpretations, implementation decisions, and review outcomes) that form a traceable basis for assessing how policy requirements are addressed in practice.

3. Role of expertise and independence
   The involvement of additional personnel does not reflect a lack of trust in the existing teams. It introduces a deliberately separated review perspective. Qualified experts with substantial experience in quality management and compliance are assigned to critically challenge the work results of the responsible departments. Their role is not operational execution, but structured and adversarial review, intended to counteract operational bias.

4. Ongoing reflection
   We are prepared to share a reflective update based on our experience regarding the application of this process approximately six months from now, focusing on lessons learned and areas for further improvement.

We recognize that trust must be demonstrated through practice over time. The measures outlined above are intended to establish durable internal mechanisms that emphasize structured challenge, traceability, and continuous improvement.

Comment 7

[Enrico Entschew]

Status Update:

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Restore valid certificates on test web page	-	Root Cause # 1	test web page with valid certificate is online	2026-01-15	Completed
Implement advanced control validation for policy updates (internal, objective third-party validation of policy interpretation)	Prevent	Root Cause # 1	Documented process	2026-02-01	Completed - please see Bugzilla 2007116

All Action Items have been marked as completed. There are currently no updates to this issue. We will continue to monitor this ticket.

Comment 8

[Enrico Entschew]

There are currently no updates to this issue. We will continue to monitor this ticket.

Comment 9

[Enrico Entschew]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Comment 10

[Ana Laura Martorano]

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.