1924385 - D-Trust: Missed Revocation of TLS certificates affected by Bugzilla 1884714

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Enrico Entschew]

Preliminary Incident Report

Summary

This is a preliminary report.

After the September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in Subscriber Certificate Authority Information Access field.

After we were made aware of this fact, D-Trust adjusted its certificate profiles. TLS certificates issued after March 4th, 2024, 2:40PM MET no longer contain the LDAP URL. 2.601 affected certificates were revoked within the revocation period. See Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1884714

On 11.10.2024 we were made aware that still some valid TLS certificates with a non-compliant AIA entry issued by D-Trust exist. The affected certificates will be revoked.

Impact

After the September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in the Subscriber Certificate Authority Information Access field. 2.601 affected TLS certificates were revoked within 5 days. Unfortunately, at least 2, from the issue affected TLS certificates went undetected.

Timeline

2023-09-15: Entry into force of the provisions from Ballot SC62

2024-10-11:

• 14:38 E-mail via [e-mail] about a potential violation of the BRs in respect to the Subscriber Certificate Authority Information Access field

• 15:20 Start investigating the issue, decision to revoke the affected TLS certificates within 5 days

• 15:41 Informing all affected customers by e-mail

• 16:30 Informing Conformity Assessment Body

2024-10-12:

• 06:13 Reply to sender of certificate problem report with the decision to revoke the affected TLS certificates

Root Cause Analysis

Will be provided with a next update

Lessons Learned

What went well

Will be provided with a next update

What didn't go well

Will be provided with a next update

Where we got lucky

Will be provided with a next update

Action Items

Action Item	Kind	Due Date
will be provided with a next update

|

Appendix

Details of affected certificates

Will be provided with a next update

Comment 1

[Enrico Entschew]

Summary

This is the final report.

After September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in Subscriber Certificate Authority Information Access field.

After we were made aware of this fact, D-Trust adjusted its certificate profiles. TLS certificates issued after March 4th, 2024, 2:40PM CET no longer contain the LDAP URL. 2.601 affected certificates were revoked within the revocation period. See Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1884714

On October 10, 2024, it was brought to our attention that there are still some valid TLS certificates with a non-compliant AIA entry issued by D-Trust. 4 certificates were affected. They have been revoked.

Impact

After September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in the Subscriber Certificate Authority Information Access field. 2.601 affected TLS certificates were revoked within 5 days. Unfortunately, 4 TLS certificates affected by the incident went undetected.

Timeline

2023-09-15: Entry into force of the provisions from Ballot SC62

2024-01-10:
19:40 Regular update of the CA system Nexus

2024-03-11:
08:00 Decision to revoke all affected TLS certificates with a LDAP entry in the AIA field based on a Certificate Problem Report that was filed previously

2024-03-14:
20:10 Update of Nexus CM to prevent the error of losing communication with the certificate management system (bug fix)

2024-03-15:
15:30 All affected TLS certificates that we detected were revoked.

2024-10-11:

• 13:38 E-mail via [e-mail] about a potential violation of the BRs regarding the Subscriber Certificate Authority Information Access field
• 14:20 Start investigating the issue, decision to revoke the affected TLS certificates within 5 days
• 14:41 Informing all affected customers by e-mail
• 15:30 Informing Conformity Assessment Body

2024-10-12:

• 05:13 Reply to sender of certificate problem report with the decision to revoke the affected TLS certificates

2024-10-14:

• 05:20 2 affected certificates were revoked

2024-10-15:

• 08:44 2 affected certificate was revoked

2024-10-24:

• 11:30 Investigation was finished
• 14:30 New internal process was introduced
• 14:45 Final Incident Report was published

Root Cause Analysis

D-Trust’s CA core infrastructure consists of two main software components, the Nexus CM and the CSM. The Nexus CM signs the certificate requests. The CSM is the corresponding certificate management system.

After a planned update of the Nexus CM on January 10th, 2024, connection problems within the CA core infrastructure occurred irregularly. These connection problems were not discovered during intensive tests of the update in the test environment (QA system).

The connection problems were reported to the manufacturer Nexus to receive a bug fix. Until the bug fix was delivered to us, the workaround was to monitor the connection pools to the database closely and to take further actions if needed. The connection problem of the Nexus CM was fixed with a software update on March 14th, 2024.

On March 15th, 2024 we revoked all remaining TLS certificates with an LDAP entry in the AIA field (2.601 affected certificates).

Unfortunately, four certificates produced on January 26th and March 1st, 2024 were not processed within this mass revocation. We have a defined process for the mass revocation, but due to additional measures caused by the workaround mentioned above these four certificates were not transferred to the data source for the mass revocation.

The monitoring system also had to be checked to detect the four affected certificates, which we did not do by accident. This was the root cause.

Lessons Learned

What went well

The communication with the customer was straight forward as expected. The customer reacted in time.

We identified potential improvements to our mass revocation process.

What didn't go well

The four certificates remained undiscovered.

Where we got lucky

Only one customer was affected.

Action Items

Action Item	Kind	Due Date
We established a process to ensure that whenever a workaround in the CA core infrastructure is introduced a potential the impact on exceptional processes also has to be checked. For example, if D-Trust has to revoke certificates due to incidents, this is an exceptional process.	prevent	10/24/2024

Appendix

Details of affected certificates

https://crt.sh/?sha256=4C05FCB339E55298F737C4774A73574422CA30B83FEEA6E613E5B211FA4B18E2
https://crt.sh/?Sha256=0E25534E64D9BF31C7ED7E3814E19FD05F578E000C0CC71B72D9CBE029C8C8C4
https://crt.sh/?SHA256=C726D7646393C0D045911247E947FF1C7443FF1CB56740F91C9E0CF2C8C6C480
https://crt.sh/?Sha256=1A8068655AF3AC388A1DACEDCBD7F75C369410E44152C35F2122A29E6441107D

Comment 2

[Ryan Dickson]

Hi Enrico,

Thanks for publishing this final report.

General comments:

For completeness, I think the timeline could be improved to include when D-Trust received the initial problem report detailing the detection of the mis-issued certificates (i.e., those issued after September 15, 2023 that included the LDAP AIA URI) in March 2024.

Questions:

1. Can you more clearly present data related to the scope of the original misissuance described in 1884714 and that carried over into this report?
   a. How many total certificates were issued after September 15, 2023 and included an LDAP AIA URI?
   b. How many of those were revoked by March 15, 2024 (i.e., the stated revocation deadline described in 1884714)?
   c. How many of those were not revoked because they expired before March 15, 2024?
   d. How many of those remaining were revoked by October 15, 2024 (i.e., the stated completion of revocation described in this report)?
   e. How many of those remaining were not revoked because they expired before October 14, 2024 (i.e., the stated start of revocation described in this report)?
2. Can you confirm my understanding of the acronyms “CM” and “CSM”?
   • “CM” = “Smart ID Certificate Manager”
   • “CSM” = “D-TRUST Certificate Service Manager”
3. Was the March 14, 2024 Nexus CM software update a dependency for the March 15, 2024 certificate revocation event, or is this just coincidence?
4. In the Root Cause Analysis section it’s stated: “After a planned update of the Nexus CM on January 10th, 2024, connection problems within the CA core infrastructure occurred irregularly. These connection problems were not discovered during intensive tests of the update in the test environment (QA system).” Can you help us better understand why the problem was not identified during intensive tests with the QA system?
5. The Root Cause Analysis does not clearly express why the 4 problematic certificates disclosed in the Appendix were not considered for revocation during the March 15, 2024 event. Should we interpret the provided analysis to indicate that even though the CA/CM signed certificates, connection issues between the CM and the CSM meant these certificates could not be managed because the CSM never knew they existed?
6. Can you describe how D-Trust can be sure that other certificates don’t suffer from the same failure mode (i.e., CM -> CSM communication challenges) resulting in the CSM similarly not being aware they exist? How was this evaluated?
7. Can you describe the specific changes put into place that will prevent this issue from occurring again? The single Action Item provided states a process was established, but it's not clear what that process entails.
8. Can you explain how D-Trust intends to detect possible future recurrence of this issue, should preventative measures not be sufficient? (e.g., are there additional intensive tests with the QA system that can be performed? etc.)
9. Can you please add commentary related to how this issue avoided detection until the CPR was filed?
10. Can you please share more detail related to the Lesson Learned (“We identified potential improvements to our mass revocation process.”) Specifically, what was the improvement and how does that translate into an additional Action Item? (or why should it not be considered an Action Item?)

Thanks,
Ryan

Comment 3

[Enrico Entschew]

Hi Ryan,
Thanks for your questions. As of today, we cannot provide final answers to all of your questions as we are still in the process of finalizing our possible improvements. We will provide updates continuously.

General comments:
For completeness, I think the timeline could be improved to include when D-Trust received the initial problem report detailing the detection of the mis-issued certificates (i.e., those issued after September 15, 2023 that included the LDAP AIA URI) in March 2024.

--> We will add this information to the report.

Questions:

1. Can you more clearly present data related to the scope of the original misissuance described in 1884714 and that carried over into this report?
   a. How many total certificates were issued after September 15, 2023 and included an LDAP AIA URI?
   --> 3815 certificates were affected.
   b. How many of those were revoked by March 15, 2024 (i.e., the stated revocation deadline described in 1884714)?
   --> 2528 certificates were revoked by March 15, 2024.
   c. How many of those were not revoked because they expired before March 15, 2024?
   --> 1 certificate was not revoked as it expired before March 15, 2024.
   d. How many of those remaining were revoked by October 15, 2024 (i.e., the stated completion of revocation described in this report)?
   --> 4 certificates were revoked by October 15, 2024.
   e. How many of those remaining were not revoked because they expired before October 14, 2024 (i.e., the stated start of revocation described in this report)?
   --> 0 certificates.

2. Can you confirm my understanding of the acronyms “CM” and “CSM”?
   o “CM” = “Smart ID Certificate Manager”
   o “CSM” = “D-TRUST Certificate Service Manager”
   --> Yes, the information above is correct.

3. Was the March 14, 2024 Nexus CM software update a dependency for the March 15, 2024 certificate revocation event, or is this just coincidence?
   --> This is just a coincidence. It was unrelated to the certificate revocation event.

4. In the Root Cause Analysis section it’s stated: “After a planned update of the Nexus CM on January 10th, 2024, connection problems within the CA core infrastructure occurred irregularly. These connection problems were not discovered during intensive tests of the update in the test environment (QA system).” Can you help us better understand why the problem was not identified during intensive tests with the QA system?
   --> Before IT systems are installed and used in the production environment, intensive tests are carried out in the test environment / QA system. The error could not be detected during these tests, as it only occurred in very specific constellations in connection with CT. We had switched off the connection to the CT system during the tests.

5. The Root Cause Analysis does not clearly express why the 4 problematic certificates disclosed in the Appendix were not considered for revocation during the March 15, 2024 event. Should we interpret the provided analysis to indicate that even though the CA/CM signed certificates, connection issues between the CM and the CSM meant these certificates could not be managed because the CSM never knew they existed?
   --> All certificates could be managed at any time, including revocation. The CM is able to manage the whole certificate life cycle. We didn’t discover the four certificates as the person responsible for generating the data for the mass revocation didn’t consider double checking with the CM. This was because they stuck to the defined process for mass revocation and didn’t consider the workaround mentioned above.

6. Can you describe how D-Trust can be sure that other certificates don’t suffer from the same failure mode (i.e., CM -> CSM communication challenges) resulting in the CSM similarly not being aware they exist? How was this evaluated?
   --> The CM always knows the status of the certificates. We checked whether other TLS certificates were affected and could not find any.

7. Can you describe the specific changes put into place that will prevent this issue from occurring again? The single Action Item provided states a process was established, but it's not clear what that process entails.
   --> The original problem occurred because the defined procedure for an extraordinary mass revocation was followed without taking into account the communication problem and aforementioned workaround. We have determined internally that workarounds must be checked for possible side effects on standard and extraordinary processes. This must be documented so that it can be taken into account if necessary.

8. Can you explain how D-Trust intends to detect possible future recurrence of this issue, should preventative measures not be sufficient? (e.g., are there additional intensive tests with the QA system that can be performed? etc.)
   --> We are currently investigating how similar issues can be reliably detected in the QA system in future. Moving forward, one of the solutions will be to log test certificates in CT test logs during the test process.

9. Can you please add commentary related to how this issue avoided detection until the CPR was filed?
   --> After the data for the extraordinary mass revocation was collected, the revocation was done on its basis. The successful execution of the revocation was checked, however, no additional search was carried out after revocation.

10. Can you please share more detail related to the Lesson Learned (“We identified potential improvements to our mass revocation process.”) Specifically, what was the improvement and how does that translate into an additional Action Item? (or why should it not be considered an Action Item?)
    --> We established plausibility checks for data used in processes, like the extraordinary mass revocations, which could be impacted by former or active workarounds.

Thanks,
Enrico

Comment 4

[Ben Wilson]

We continue work on incident-reporting and compliance requirements aimed at reducing delayed revocation, so this bug will remain open until at least February 1, 2025. Meanwhile, CAs should review https://github.com/mozilla/www.ccadb.org/pull/186.

Comment 5

[Enrico Entschew]

As previously written, we have continued to work on improvements to prevent this error in the future.

1. Improvement: CT-logging in CT test logs during tests in the QA system
   In the future, during tests of new software releases of Nexus CM, all test TLS certificates will be logged to CT test logs. This is to make sure that no problems occur in the CT process. We will request the recognition by CT test logs for our test root CAs.

Completion of the measure planned for 31.01.2025

2. Improvement: Establishing of an error-tolerant data synchronization system
   We will introduce an additional system with synchronized data from the CA core infrastructure systems which will be in parallel to the regular production systems. This system allows cross and plausibility checks and will be error-tolerant in order to help recognize possible errors that have not yet occurred.

Completion of the measure planned for 30.06.2025

Thanks,
Enrico

Comment 6

[Dean F. Reed]

Comment #3. shares a revised timeline would be posted. Can D-TRUST share this information and help reconcile the delay?

Comment 7

[Enrico Entschew]

##Incident Report

Summary

This is an update of the final report. The timeline of the incident 1884714 was added.

After September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in Subscriber Certificate Authority Information Access field.
After we were made aware of this fact, D-Trust adjusted its certificate profiles. TLS certificates issued after March 4th, 2024, 2:40PM CET no longer contain the LDAP URL. 2.601 affected certificates were revoked within the revocation period. See Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1884714

On October 10, 2024, it was brought to our attention that there are still some valid TLS certificates with a non-compliant AIA entry issued by D-Trust. 4 certificates were affected. They have been revoked.

Impact

After September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in the Subscriber Certificate Authority Information Access field. 2.601 affected TLS certificates were revoked within 5 days. Unfortunately, 4 TLS certificates affected by the incident went undetected.

Timeline

2023-02-06 (please see https://bugzilla.mozilla.org/show_bug.cgi?id=1884714):
07:30 Check of existing certificate profiles against Ballot SC62

2023-09-15: Entry into force of the provisions from Ballot SC62

2024-01-10:
19:40 Regular update of the CA system Nexus

2024-03-04 (please see https://bugzilla.mozilla.org/show_bug.cgi?id=1884714):
13:00 Email via [e-mail] about a potential violation of the BRs in respect to the Subscriber Certificate Authority Information Access field
13:10 Start of investigation, review of existing TLS certificates issued after September 15th, 2023
13:20 Preliminary decision to remove the LDAP address from all TLS certificate profiles because future products are already specified without any LDAP entry and to avoid possible misunderstandings in this specific case in the future
13:40 All affected TLS certificate profiles were adjusted.
21:21 Reply to email sender

2024-03-11 (please see https://bugzilla.mozilla.org/show_bug.cgi?id=1884714):
08:00 Decision to revoke the affected TLS certificates within 5 days as a precautionary measure
14:00 Email to all affected customers
16:29 Preliminary incident report at Bugzilla was opened.

2024-03-13 (please see https://bugzilla.mozilla.org/show_bug.cgi?id=1884714):
14:13 Conformity Assessment Body was informed about the issue.

2024-03-14:
20:10 Update of Nexus CM to prevent the error of losing communication with the certificate management system (bug fix)

2024-03-15 (please see https://bugzilla.mozilla.org/show_bug.cgi?id=1884714):
15:30 All affected TLS certificates were revoked.

2024-10-11:
13:38 E-mail via [e-mail] about a potential violation of the BRs regarding the Subscriber Certificate Authority Information Access field
14:20 Start investigating the issue, decision to revoke the affected TLS certificates within 5 days
14:41 Informing all affected customers by e-mail
15:30 Informing Conformity Assessment Body

2024-10-12:
05:13 Reply to sender of certificate problem report with the decision to revoke the affected TLS certificates

2024-10-14:
05:20 2 affected certificates were revoked

2024-10-15:
08:44 2 affected certificates were revoked

2024-10-24:
11:30 Investigation was finished
14:30 New internal process was introduced
14:45 Final Incident Report was published

Root Cause Analysis

D-Trust’s CA core infrastructure consists of two main software components, the Nexus CM and the CSM. The Nexus CM signs the certificate requests. The CSM is the corresponding certificate management system.

After a planned update of the Nexus CM on January 10th, 2024, connection problems within the CA core infrastructure occurred irregularly. These connection problems were not discovered during intensive tests of the update in the test environment (QA system).

The connection problems were reported to the manufacturer Nexus to receive a bug fix. Until the bug fix was delivered to us, the workaround was to monitor the connection pools to the database closely and to take further actions if needed. The connection problem of the Nexus CM was fixed with a software update on March 14th, 2024.

On March 15th, 2024 we revoked all remaining TLS certificates with an LDAP entry in the AIA field (2.601 affected certificates).
Unfortunately, four certificates produced on January 26th and March 1st, 2024 were not processed within this mass revocation. We have a defined process for the mass revocation, but due to additional measures caused by the workaround mentioned above these four certificates were not transferred to the data source for the mass revocation.

The monitoring system also had to be checked to detect the four affected certificates, which we did not do by accident. This was the root cause.

Lessons Learned

What went well

The communication with the customer was straight forward as expected. The customer reacted in time.

We identified potential improvements to our mass revocation process.

What didn't go well

The four certificates remained undiscovered.

Where we got lucky

Only one customer was affected.

Action Items

Action Item	Kind	Due Date
We established a process to ensure that whenever a workaround in the CA core infrastructure is introduced, a potential impact on exceptional processes also has to be checked. For example, if D-Trust has to revoke certificates due to incidents, this is an exceptional process.	prevent	2024-10-24
CT-logging in CT test logs during tests in the QA system: In the future, during tests of new software releases of Nexus CM, all test TLS certificates will be logged to CT test logs. This is to make sure that no problems occur in the CT process. We will request the recognition by CT test logs for our test root CAs.	prevent	2025-01-31
Establishing of an error-tolerant data synchronization system: We will introduce an additional system with synchronized data from the CA core infrastructure systems which will be in parallel to the regular production systems. This system allows cross and plausibility checks and will be error-tolerant in order to help recognize possible errors that have not yet occurred.	prevent	2025-06-30

Appendix

Details of affected certificates

https://crt.sh/?sha256=4C05FCB339E55298F737C4774A73574422CA30B83FEEA6E613E5B211FA4B18E2
https://crt.sh/?Sha256=0E25534E64D9BF31C7ED7E3814E19FD05F578E000C0CC71B72D9CBE029C8C8C4
https://crt.sh/?SHA256=C726D7646393C0D045911247E947FF1C7443FF1CB56740F91C9E0CF2C8C6C480
https://crt.sh/?Sha256=1A8068655AF3AC388A1DACEDCBD7F75C369410E44152C35F2122A29E6441107D

Comment 8

[Enrico Entschew]

Update:
We successfully requested the recognition by Google CT test logs for our test root CAs. Since the beginning of February 2025 we have been able to log test TLS certificates. During tests of new software releases of Nexus CM, all test TLS certificates will be logged to the Google CT test logs.

Comment 9

[Ben Wilson]

Please provide a status update.

Comment 10

[Leyla Sahin]

Status update: There is nothing new to report.
We are still working on establishing of an error-tolerant data synchronization system.

Comment 11

[Jeremy]

It sounds like D-Trust couldn't or didn't search its database of issued certificates for the issue? Or CT logs? Is that correct? Do you not use those tools in your data analytics for incident investigation? I'd be interested in what the overall process looks like for discovery of the complete corpus of impacted certificates. Do you run scans post revocation to determine whether everything was revoked?

Comment 12

[Jeremy]

Note that the last status update was 12 days ago, which exceeds the Mozilla requirement to provide updates every 7 days.

Comment 13

[Enrico Entschew]

Hi Jeremy,
Thanks for your questions and thanks for the reminder. Apologies for the delay.

As already written, the four certificates went undetected as a defined procedure for an extraordinary mass revocation was followed without taking into account the preceding communication problem and aforementioned workaround. That led to a list off affected certificates without these four certificates.

We adjusted our extraordinary mass revocation plan. The potential impact on exceptional processes also has to be checked, whenever a workaround in the CA core infrastructure is going to be introduced.

At the moment we are working on an error-tolerant data synchronization system which will constantly allow us to add also additional information from outside as crt.sh-IDs and other none-certificate related information. The system will run alongside regular production systems. This system allows for cross-checks and plausibility checks, and will be fault-tolerant to help identify potential errors that have not yet occurred. This would have helped to identify the error when creating the incomplete list of affected certificates that we later used for the mass revocation process.

To your last question: We check the certificate status of all certificates who are to be revoked as part of the mass revocation process in several stages, internally and externally.

Thanks,
Enrico

Comment 14

[Enrico Entschew]

The work on the error-tolerant data synchronization system is progressing successfully. I would like to kindly ask if we can give the next update on 2025.06.01. We will continue to monitor the ticket for any questions that arise in the meantime.

Comment 15

[Enrico Entschew]

We installed the error-tolerant data synchronization system in the test system successfully. Next step is the installation in the production system.

Comment 16

[Enrico Entschew]

We successfully installed the error-tolerant data synchronization system in the production system on 06/26/2025 . Next step is to publish the Report Closure Summary.

Comment 17

[Enrico Entschew]

Report Closure Summary

• Incident description:
  After September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in Subscriber Certificate Authority Information Access field.
  After we were made aware of this fact, D-Trust adjusted its certificate profiles. TLS certificates issued after March 4th, 2024, 2:40PM CET no longer contain the LDAP URL. 2.601 affected certificates were revoked within the revocation period. See Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1884714
  On October 10th, 2024, it was brought to our attention that there are still some valid TLS certificates with a non-compliant AIA entry issued by D-Trust. 4 certificates were affected. They were revoked by October 15th, 2024.
• Incident Root Cause(s):
  D-Trust’s CA core infrastructure consists of two main software components, the Nexus CM and the CSM. The Nexus CM signs the certificates. The CSM is the corresponding certificate management system.
  After a planned update of the Nexus CM on January 10th, 2024, connection problems within the CA core infrastructure occurred irregularly. These connection problems were not discovered during intensive tests of the update in the test environment (QA system).
  The connection problems were reported to the manufacturer Nexus to receive a bug fix. Until the bug fix was delivered to us, the workaround was to monitor the connection pools to the database closely and to take further actions if needed. The connection problem of the Nexus CM was fixed with a software update on March 14th, 2024.
  On March 15th, 2024 we revoked all unrevoked TLS certificates with an LDAP entry in the AIA field (2.601 affected certificates).
  Unfortunately, four certificates produced on January 26th and March 1st, 2024 were not processed within this mass revocation. We have a defined process for the mass revocation, but due to additional measures caused by the workaround mentioned above these four certificates were not transferred to the data source for the mass revocation. That led to a list of affected certificates without these four certificates.
  The monitoring system also would have had to be checked to detect the four affected certificates, which we did not do. This was the root cause.
• Remediation description:
  Various query options were used to check whether there were any other certificates affected by the incident. All affected certificates have been revoked as specified.
• Commitment summary:
  The proposed action items, which have all been completed, cover all commitments.
  • We established a process to ensure that whenever a workaround in the CA core infrastructure is introduced, a potential impact on exceptional processes also has to be checked. For example, if D-Trust has to revoke certificates due to incidents, this is an exceptional process.
  • We established a process that during tests of new software releases of Nexus CM, all test TLS certificates will be logged to CT test logs. This is to make sure that no problems occur in the CT process. Our test root CAs are recognized by CT test logs.
  • We successfully established an error-tolerant data synchronization system. This additional system with synchronized data from the CA core infrastructure systems operates in parallel to the regular production systems. It allows cross and plausibility checks and is error-tolerant in order to help recognize possible errors that have not yet occurred.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 18

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-07-14.