D-Trust: Issuance of 15 certificates with incorrect subject attribute order
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: l.sahin, Assigned: l.sahin)
Details
(Whiteboard: [ca-compliance] [ev-misissuance] Next update 2024-08-01)
Attachments
(1 file)
|
1.35 KB,
text/plain
|
Details |
Preliminary Incident Report
Summary
This is a preliminary report.
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according to the TLS Baseline Requirements.
Before the Ballot SC62 came into force, D-Trust changed the order of the subject attributes (RDN) for all publicly trusted TLS Subordinate CAs. Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. Currently we’re investigating the subject.
After we were made aware, D-Trust stopped production. D-Trust implemented quickly the change in question for the affected Subordinate CA. After successful testing, D-Trust restarted production.
All affected customers were informed. We supported customers to replace and revoke the affected TLS certificates.
Impact
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according the TLS Baseline Requirements.
15 TLS certificates were revoked.
Timeline
2023-02-06:
- 07:30 Check of existing certificate profiles against Ballot SC62
2023-09-15: Entry into force of the provisions from Ballot SC62
2024-04-09:
- 08:15 Email via ssl-issue@bdr.de about a potential violation of the BRs regarding the order of the subject attributes (RDN)
2024-04-10:
- 07:00 Start of investigation
- 08:00 Stop of production
- 11:00 Analyzing of existing affected TLS certificates issued after September 15th, 2023
- 12:30 Correction of the configuration followed by a test in the reference system
- 15:30 Correction of the configuration in the productive system
2024-04-11:
- 07:00 Calling all affected customers
- 08:40 Emailing all affected customers
- 08:30 Conformity Assessment Body was informed about the issue.
- 16:05 Restart of the production after correction
- 16:11 Test of the production system by issuing a certificate from the affected product type
2024-04-12:
- 12:05 All affected certificates were revoked.
Root Cause Analysis
D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined attributes order according to the TLS Baseline Requirements.
As part of Ballot SC62, the changes were made regarding the order of the subject attributes (RDN). Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. This means a deviation to the TLS BRs. Therefore, D-Trust supported customers to replace and revoke the affected TLS certificates.
Lessons Learned
- 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
|
Assignee | |
Comment 1•1 year ago
|
||
|
||
Updated•1 year ago
|
|
|
Assignee | |
Comment 2•1 year ago
|
||
During our root cause investigation of this incident, we discovered that there was also a non-conformity of TLS BR 4.9.5. As a result, we have opened the following incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1893610
Further developments regarding this incident will be documented there.
When will the full incident report be posted for this issue?
|
|
Assignee | |
Comment 4•1 year ago
|
||
Thanks for asking. The next update will be published on Monday.
|
|
Assignee | |
Comment 5•1 year ago
|
||
Final Incident Report
Summary
This is the final report.
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according to the TLS Baseline Requirements.
Before the Ballot SC62 came into force, D-Trust changed the order of the subject attributes (RDN) for all publicly trusted TLS Subordinate CAs. Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. Currently we’re investigating the subject.
After we were made aware, D-Trust stopped production. D-Trust implemented quickly the change in question for the affected Subordinate CA. After successful testing, D-Trust restarted production.
All affected customers were informed. We supported customers to replace and revoke the affected TLS certificates.
Impact
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according the TLS Baseline Requirements.
15 TLS certificates were revoked.
Timeline
2023-02-06:
- 07:30 Check of existing certificate profiles against Ballot SC62
2023-09-15: Entry into force of the provisions from Ballot SC62
2024-04-09:
- 08:15 Email via ssl-issue@bdr.de about a potential violation of the BRs
regarding the order of the subject attributes (RDN)
2024-04-10: - 07:00 Start of investigation
- 08:00 Stop of production
- 11:00 Analyzing of existing affected TLS certificates issued after
September 15th, 2023 - 12:30 Correction of the configuration followed by a test in the reference
system - 15:30 Correction of the configuration in the productive system
2024-04-11:
- 07:00 Calling all affected customers
- 08:40 Emailing all affected customers
- 08:30 Conformity Assessment Body was informed about the issue.
- 16:05 Restart of the production after correction
- 16:11 Test of the production system by issuing a certificate from the
affected product type
2024-04-12:
- 12:05 All affected certificates were revoked.
2024-04-26:
- 10:22 Opening a follow-up incident report because the notification was not sent within 24 hours to the defined recipients in the TLS BRs section 4.9.5. See https://bugzilla.mozilla.org/show_bug.cgi?id=1893610
Root Cause Analysis
D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined attributes order according to the TLS Baseline Requirements.
As part of Ballot SC62, the necessary changes were made regarding the order of the subject attributes (RDN). Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. This means a deviation to the TLS BRs.
How did this error occur? D-Trust uses configuration sets for the standardized creation of products. The error occurred because a configuration set was named incorrectly. Due to the incorrect naming, the configuration set was not selected and was not adapted to the requirements of SC62.
In our opinion, the best way to avoid this is to ensure that the dedicated linter(s) is/are updated to comply with new standards before they become effective. If this is not possible, additional checks must be carried out. Hence, such errors can be avoided from the outset.
Lessons Learned
What went well
- Customers needed to be contacted before the weekend in order to replace the affected certificates in a timely manner. Despite the short time before the weekend, we were able to reach all customers. The revocation of the affected certificates was carried out on time. We were lucky that only a small number of customers were affected.
What didn't go well
- It took more than 24 hours to notify the affected Subscriber and the person who filed the Certificate Problem Report.
- Our linter did not detect the error.
Where we got lucky
- Only a small number of customers were affected by the incident.
Action Items
The implementation of the lints must be checked and implemented prior to the effective date of a specification change comes into effect. If this is not done by the effective date, we will perform additional checks. To do this, the following two actions must be implemented.
| Action Item | Kind | Due Date |
|---|---|---|
| Require improvement of the linters: | ||
| If a linter does not have lints that comply with the last specification change, internal checks must be established to implement the necessary lints. | Prevent | 2024-05-02 |
| Integrate at least one additional linter. | Prevent | 2024-08-01 |
Appendix
Details of affected certificates
What happened between 2024-04-26 and today? If the incident report took until today to come out, I would like to see that reflected in the timeline as well.
Integrate at least one additional linter.
What's preventing this from happening earlier than ~3 months?
Especially considering the opinion here:
In our opinion, the best way to avoid this is to ensure that the dedicated linter(s) is/are updated to comply with new standards before they become effective. If this is not possible, additional checks must be carried out.
So, now this linter isn't going to be in place for about ~1 year after SC62 came into effect, and about 1.5 years after it was adopted?
If a linter does not have lints that comply with the last specification change, internal checks must be established to implement the necessary lints.
What does this mean? What are the internal checks?
It has been over a week and no reply to the above questions have been provided.
|
|
Assignee | |
Comment 8•1 year ago
|
||
(In reply to amir from comment #6)
What happened between 2024-04-26 and today? If the incident report took until today to come out, I would like to see that reflected in the timeline as well.
We will adjust the incident report as you requested.
Integrate at least one additional linter.
What's preventing this from happening earlier than ~3 months?
This is an estimate of when we will have completed the process. We are currently reviewing the linters available on the market, including commercially available versions. Tests are required before such a tool can be put into operation at our company. This also includes testing in the reference system. This is the standard procedure in our company.
Especially considering the opinion here:
In our opinion, the best way to avoid this is to ensure that the dedicated linter(s) is/are updated to comply with new standards before they become effective. If this is not possible, additional checks must be carried out.
So, now this linter isn't going to be in place for about ~1 year after SC62 came into effect, and about 1.5 years after it was adopted?
We use the current version of ZLint. We are aware that not all SC62 changes have yet been implemented in ZLint. That’s why we have additional measures outside of ZLint in place to address the changes of SC62 right now.
If a linter does not have lints that comply with the last specification change, internal checks must be established to implement the necessary lints.
What does this mean? What are the internal checks?
If we determine that a linter used by us does not support changes to the specifications, we will implement other measures to check the changes. For example, these can be internal extensions to the linter developed in-house or other checks that we can implement ourselves in our Certificates Management System.
We can’t predict if the linters will address future changes to the specifications. If they do not, then we will choose an appropriate way to check the compliance of our products, based on the nature of the change.
|
|
Assignee | |
Comment 9•1 year ago
|
||
(In reply to Wayne from comment #7)
It has been over a week and no reply to the above questions have been provided.
Please accept our apologies for the delay.
|
|
Assignee | |
Comment 10•1 year ago
|
||
Final Incident Report
Summary
This is an update to the final report.
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according to the TLS Baseline Requirements.
Before the Ballot SC62 came into force, D-Trust changed the order of the subject attributes (RDN) for all publicly trusted TLS Subordinate CAs. Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. Currently we’re investigating the subject.
After we were made aware, D-Trust stopped production. D-Trust implemented quickly the change in question for the affected Subordinate CA. After successful testing, D-Trust restarted production.
All affected customers were informed. We supported customers to replace and revoke the affected TLS certificates.
Impact
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according the TLS Baseline Requirements.
15 TLS certificates were revoked.
Timeline
2023-02-06:
- 07:30 Check of existing certificate profiles against Ballot SC62
2023-09-15: Entry into force of the provisions from Ballot SC62
2024-04-09:
- 08:15 Email via ssl-issue@bdr.de about a potential violation of the BRs
regarding the order of the subject attributes (RDN)
2024-04-10: - 07:00 Start of investigation
- 08:00 Stop of production
- 11:00 Analyzing of existing affected TLS certificates issued after
September 15th, 2023 - 12:30 Correction of the configuration followed by a test in the reference
system - 15:30 Correction of the configuration in the productive system
2024-04-11:
- 07:00 Calling all affected customers
- 08:40 Emailing all affected customers
- 08:30 Conformity Assessment Body was informed about the issue.
- 16:05 Restart of the production after correction
- 16:11 Test of the production system by issuing a certificate from the
affected product type
2024-04-12:
- 12:05 All affected certificates were revoked.
2024-04-26:
- 10:22 Opening a follow-up incident report because the notification was not sent within 24 hours to the defined recipients in the TLS BRs section 4.9.5. See https://bugzilla.mozilla.org/show_bug.cgi?id=1893610
2024-05-06:
- 21:29 Publication of the final report.
2024-05-17:
- 14:47 Publication of an update to the final report.
Root Cause Analysis
D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined attributes order according to the TLS Baseline Requirements.
As part of Ballot SC62, the necessary changes were made regarding the order of the subject attributes (RDN). Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. This means a deviation to the TLS BRs.
How did this error occur? D-Trust uses configuration sets for the standardized creation of products. The error occurred because a configuration set was named incorrectly. Due to the incorrect naming, the configuration set was not selected and was not adapted to the requirements of SC62.
In our opinion, the best way to avoid this is to ensure that the dedicated linter(s) is/are updated to comply with new standards before they become effective. If this is not possible, additional checks must be carried out. Hence, such errors can be avoided from the outset.
Lessons Learned
What went well
- Customers needed to be contacted before the weekend in order to replace the affected certificates in a timely manner. Despite the short time before the weekend, we were able to reach all customers. The revocation of the affected certificates was carried out on time. We were lucky that only a small number of customers were affected.
What didn't go well
- It took more than 24 hours to notify the affected Subscriber and the person who filed the Certificate Problem Report.
- Our linter did not detect the error.
Where we got lucky
- Only a small number of customers were affected by the incident.
Action Items
The implementation of the lints must be checked and implemented prior to the effective date of a specification change comes into effect. If this is not done by the effective date, we will perform additional checks. To do this, the following two actions must be implemented.
| Action Item | Kind | Due Date |
|---|---|---|
| Require improvement of the linters: | ||
| If a linter does not have lints that comply with the last specification change, internal checks must be established to implement the necessary lints. | Prevent | 2024-05-02 |
| Integrate at least one additional linter. | Prevent | 2024-08-01 |
Appendix
Details of affected certificates
|
||
Comment 11•1 year ago
|
||
A full incident report must be produced within 2 weeks. What will be done to make sure this happens in the future?
An initial report should be filed within 72 hours of the CA Owner being made aware of the incident. If a full incident report is not yet ready, CA Owners should provide a preliminary report containing an executive summary of the incident and a date by which the full report will be posted. The full incident report must be posted within two weeks of the incident.
|
|
Assignee | |
Comment 12•1 year ago
|
||
Hi Wayne,
Firstly, I would like to apologise for the fact that we failed to comply with the CCADB policy and were unable to provide a final incident report within the timeframe.
I would like to briefly explain the background as to why it took us so long in this specific case. As part of the investigation into this incident, we unfortunately discovered that there was a further non-compliance of the BR requirements. We have already opened another bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1893610) for this. Because of this incident, we have chosen to examine the entire internal reporting and response process once again. In doing so, we identified potential for improvements, the implementation of which has already begun.
However, we did not meet the deadline for the complete incident report.
How will we ensure that this does not happen again in the future?
We have expanded our internal process guidelines on this point and trained all responsible employees once again. We are currently preparing a separate checklist to be considered in the event of an incident being processed at Bugzilla. The clear timelines are also set out there once again.
Regards, Leyla
|
||
Comment 13•1 year ago
|
||
(In reply to Leyla Sahin from comment #8)
We use the current version of ZLint. We are aware that not all SC62 changes have yet been implemented in ZLint. That’s why we have additional measures outside of ZLint in place to address the changes of SC62 right now.
Are you saying that you have already implemented your own pre-issuance lint to check for subject attribute order? When was that done? Shouldn't that be listed in your actions items?
Have you checked that your existing lints actually cover all the other changes of SC62?
|
|
||
Comment 14•1 year ago
|
||
It has been over a week and no reply to the above questions have been provided.
|
|
Assignee | |
Comment 15•1 year ago
|
||
(In reply to Wayne from comment #14)
It has been over a week and no reply to the above questions have been provided.
I appreciate the reminder and apologize for the delay.
|
|
Assignee | |
Comment 16•1 year ago
|
||
(In reply to Mathew Hodson from comment #13)
(In reply to Leyla Sahin from comment #8)
We use the current version of ZLint. We are aware that not all SC62 changes have yet been implemented in ZLint. That’s why we have additional measures outside of ZLint in place to address the changes of SC62 right now.
Are you saying that you have already implemented your own pre-issuance lint to check for subject attribute order? When was that done? Shouldn't that be listed in your actions items?
Have you checked that your existing lints actually cover all the other changes of SC62?
Hi Mathew,
The tests are carried out in different ways. We have not implemented any new lints in our currently used linter ZLint.
For example, we have implemented organizational measures outside of ZLint to check the order of subject attributes and to cover the other changes from SC62.
I will add this to the action items.
Regards,
Leyla
|
|
Assignee | |
Comment 17•1 year ago
|
||
Final Incident Report
Summary
This is the latest update of the final report.
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according to the TLS Baseline Requirements.
Before the Ballot SC62 came into force, D-Trust changed the order of the subject attributes (RDN) for all publicly trusted TLS Subordinate CAs. Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. Currently we’re investigating the subject.
After we were made aware, D-Trust stopped production. D-Trust implemented quickly the change in question for the affected Subordinate CA. After successful testing, D-Trust restarted production.
All affected customers were informed. We supported customers to replace and revoke the affected TLS certificates.
Impact
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according the TLS Baseline Requirements.
15 TLS certificates were revoked.
Timeline
2023-02-06:
- 07:30 Check of existing certificate profiles against Ballot SC62
2023-09-15: Entry into force of the provisions from Ballot SC62
2024-04-09:
- 08:15 Email via ssl-issue@bdr.de about a potential violation of the BRs
regarding the order of the subject attributes (RDN)
2024-04-10: - 07:00 Start of investigation
- 08:00 Stop of production
- 11:00 Analyzing of existing affected TLS certificates issued after
September 15th, 2023 - 12:30 Correction of the configuration followed by a test in the reference
system - 15:30 Correction of the configuration in the productive system
2024-04-11:
- 07:00 Calling all affected customers
- 08:40 Emailing all affected customers
- 08:30 Conformity Assessment Body was informed about the issue.
- 16:05 Restart of the production after correction
- 16:11 Test of the production system by issuing a certificate from the
affected product type
2024-04-12:
- 12:05 All affected certificates were revoked.
2024-04-26:
- 10:22 Opening a follow-up incident report because the notification was not sent within 24 hours to the defined recipients in the TLS BRs section 4.9.5. See https://bugzilla.mozilla.org/show_bug.cgi?id=1893610
2024-05-06:
- 21:29 Publication of the final report.
2024-05-10:
- Implementation of additional checks to cover the changes of the BRs by SC62.
2024-05-30:
- Publication of an update to the final report.
Root Cause Analysis
D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined attributes order according to the TLS Baseline Requirements.
As part of Ballot SC62, the necessary changes were made regarding the order of the subject attributes (RDN). Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. This means a deviation to the TLS BRs.
How did this error occur? D-Trust uses configuration sets for the standardized creation of products. The error occurred because a configuration set was named incorrectly. Due to the incorrect naming, the configuration set was not selected and was not adapted to the requirements of SC62.
In our opinion, the best way to avoid this is to ensure that the dedicated linter(s) is/are updated to comply with new standards before they become effective. If this is not possible, additional checks must be carried out. Hence, such errors can be avoided from the outset.
Lessons Learned
What went well
- Customers needed to be contacted before the weekend in order to replace the affected certificates in a timely manner. Despite the short time before the weekend, we were able to reach all customers. The revocation of the affected certificates was carried out on time. We were lucky that only a small number of customers were affected.
What didn't go well
- It took more than 24 hours to notify the affected Subscriber and the person who filed the Certificate Problem Report.
- Our linter did not detect the error.
Where we got lucky
- Only a small number of customers were affected by the incident.
Action Items
The implementation of the lints must be checked and implemented prior to the effective date of a specification change comes into effect. If this is not done by the effective date, we will perform additional checks. To do this, the following two actions must be implemented.
| Action Item | Kind | Due Date |
|---|---|---|
| Require improvement of the linters: | ||
| If a linter does not have lints that comply with the last specification change, internal checks must be established to implement the necessary lints. | Prevent | 2024-05-02 |
| Integrate at least one additional linter. | Prevent | 2024-08-01 |
Appendix
Details of affected certificates
|
||
Comment 18•1 year ago
|
||
Quick update: We are making progress with reviewing the linters available on the market. I kindly request to give the next update on 07/01/2024.
|
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
|
||
Comment 19•1 year ago
|
||
(In reply to Leyla Sahin from comment #16)
For example, we have implemented organizational measures outside of ZLint to check the order of subject attributes and to cover the other changes from SC62.
I will add this to the action items.
What specifically have you implemented to ensure issued certificates are compliant with the changes in SC62? "Organizational measures" could mean many different things.
What specifically has been done since this incident was created? You have an action item with a date of 2025-05-02 that says, "If a linter does not have lints that comply with the last specification change, internal checks must be established to implement the necessary lints." That doesn't provide any detail at all.
You said that you will add something to the list of action items, but the list in comment #17 is the same as the one in comment #10.
|
|
Assignee | |
Comment 20•1 year ago
|
||
Final Incident Report
This incident report contains a correction of the action items.
Summary
This is the latest update of the final report.
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according to the TLS Baseline Requirements.
Before the Ballot SC62 came into force, D-Trust changed the order of the subject attributes (RDN) for all publicly trusted TLS Subordinate CAs. Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. Currently we’re investigating the subject.
After we were made aware, D-Trust stopped production. D-Trust implemented quickly the change in question for the affected Subordinate CA. After successful testing, D-Trust restarted production.
All affected customers were informed. We supported customers to replace and revoke the affected TLS certificates.
Impact
After September 15th, 2023 D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined subject attributes (RDN) order according the TLS Baseline Requirements.
15 TLS certificates were revoked.
Timeline
2023-02-06:
- 07:30 Check of existing certificate profiles against Ballot SC62
2023-09-15: Entry into force of the provisions from Ballot SC62
2024-04-09:
- 08:15 Email via ssl-issue@bdr.de about a potential violation of the BRs
regarding the order of the subject attributes (RDN)
2024-04-10: - 07:00 Start of investigation
- 08:00 Stop of production
- 11:00 Analyzing of existing affected TLS certificates issued after
September 15th, 2023 - 12:30 Correction of the configuration followed by a test in the reference
system - 15:30 Correction of the configuration in the productive system
2024-04-11:
- 07:00 Calling all affected customers
- 08:40 Emailing all affected customers
- 08:30 Conformity Assessment Body was informed about the issue.
- 16:05 Restart of the production after correction
- 16:11 Test of the production system by issuing a certificate from the
affected product type
2024-04-12:
- 12:05 All affected certificates were revoked.
2024-04-26:
- 10:22 Opening a follow-up incident report because the notification was not sent within 24 hours to the defined recipients in the TLS BRs section 4.9.5. See https://bugzilla.mozilla.org/show_bug.cgi?id=1893610
2024-05-06:
- 21:29 Publication of the final report.
2024-05-10:
- Implementation of additional checks to cover the changes of the BRs by SC62.
2024-05-30:
- Publication of an update to the final report.
2024-06-12:
- Publication of a new update to the final report that includes a correction of the action items.
Root Cause Analysis
D-Trust issued TLS certificates from the Subordinate CA “D-TRUST CA 2-2 EV 2016” that didn’t have the defined attributes order according to the TLS Baseline Requirements.
As part of Ballot SC62, the necessary changes were made regarding the order of the subject attributes (RDN). Unfortunately, the change wasn’t completed for the Subordinate CA “D-TRUST CA 2-2 EV 2016”. This means a deviation to the TLS BRs.
How did this error occur? D-Trust uses configuration sets for the standardized creation of products. The error occurred because a configuration set was named incorrectly. Due to the incorrect naming, the configuration set was not selected and was not adapted to the requirements of SC62.
In our opinion, the best way to avoid this is to ensure that the dedicated linter(s) is/are updated to comply with new standards before they become effective. If this is not possible, additional checks must be carried out. Hence, such errors can be avoided from the outset.
Lessons Learned
What went well
- Customers needed to be contacted before the weekend in order to replace the affected certificates in a timely manner. Despite the short time before the weekend, we were able to reach all customers. The revocation of the affected certificates was carried out on time. We were lucky that only a small number of customers were affected.
What didn't go well
- It took more than 24 hours to notify the affected Subscriber and the person who filed the Certificate Problem Report.
- Our linter did not detect the error.
Where we got lucky
- Only a small number of customers were affected by the incident.
Action Items
| Action Item | Kind | Due Date |
|---|---|---|
| Define and implement additional internal checks to address the changes of SC62 | Prevent | 2024-05-02 |
| Integrate at least one additional linter | Prevent | 2024-08-01 |
| Implement additional checks to address some of the changes of SC62 in ZLint (please see also https://bugzilla.mozilla.org/show_bug.cgi?id=1884714) | Prevent | 2024-06-30 |
Appendix
Details of affected certificates
|
|
Assignee | |
Comment 21•1 year ago
|
||
(In reply to Mathew Hodson from comment #19)
(In reply to Leyla Sahin from comment #16)
For example, we have implemented organizational measures outside of ZLint to check the order of subject attributes and to cover the other changes from SC62.
I will add this to the action items.What specifically have you implemented to ensure issued certificates are compliant with the changes in SC62? "Organizational measures" could mean many different things.
What specifically has been done since this incident was created? You have an action item with a date of 2025-05-02 that says, "If a linter does not have lints that comply with the last specification change, internal checks must be established to implement the necessary lints." That doesn't provide any detail at all.
You said that you will add something to the list of action items, but the list in comment #17 is the same as the one in comment #10.
Right now the latest ZLint version we use does not cover the changes of SC62. Together with the partner company MTG we are in the process of implementing some of the necessary changes to cover the changes of SC62 in ZLint that were not addressed by now.
However, we are also in the process of selecting a second linter to be implemented at D-Trust, which we will run independently from ZLint. For the meantime we defined and realized internal checks to address the changes of SC62. As written before, the internal checks are organizational measures. These are e.g. mostly additional checklists for new or existing certificate profiles but also technical checks in our CA system.
Apologies for the confusion in regard to the action items. We established the internal checks by 2024-05-02. Due to a formatting error, the action items list appears to be incomplete. I rewrote and reformatted the action items list so that it is hopefully clearer now.
|
|
||
Comment 22•1 year ago
|
||
Quick update:
We have decided to implement PKILint as a second linter. We are currently reviewing the internal timelines and implementation. Next week, we will have more information on this.
|
|
Assignee | |
Comment 23•1 year ago
|
||
Quick update:
The PKILint will be implemented this month (July). We are on track with the plan to have it running by 08/01/2024 at the latest.
|
|
||
Updated•1 year ago
|
|
|
Assignee | |
Comment 24•1 year ago
|
||
Good news:
On July 9th, 2024 we installed pkilint in our reference system and tested it successfully. On July 19th, 2024 pkilint was installed successfully in our production system and it has been running since then. Now we use two linters to run pre-issuance linting on our TLS pre-certificates and TLS certificates.
|
|
Assignee | |
Comment 25•1 year ago
|
||
We have implemented all measures. They have already been successfully applied.
I kindly ask you to check whether this incident can be closed.
|
|
||
Comment 26•1 year ago
|
||
I intend to close this on or about next Wed. 7-Aug-2024, unless additional items need to be discussed or explained.
|
|
||
Updated•1 year ago
|
Description
•