Closed Bug 1884714 Opened 7 months ago Closed 19 days ago

D-Trust: LDAP-URL in Subscriber Certificate Authority Information Access field

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: enrico.entschew, Assigned: enrico.entschew)

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Attachments

(2 files)

List of affected certificates.txt
237.60 KB, text/plain
Details
affected certificates with no CT log
3.48 KB, application/x-zip-compressed
Details

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 because future products are already specified without any LDAP entry and to avoid possible misunderstandings in this specific case. TLS certificates issued after March 4th, 2024, 2:40PM MET no longer contain the LDAP URL.

All affected customers got informed today (March 11th, 2024) that D-Trust came to the conclusion to revoke the effected certificates. We will revoke the certificates within the expected time frame.

Impact

After the September 15th, 2023 D-Trust issued TLS certificates containing an LDAP-URL in the Subscriber Certificate Authority Information Access field. All effected certificates will be revoked within the next 5 days.

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-03-04:

  • 13:00 e-mail via ssl-issue@bdr.de about a potential violation of the BRs in respect to the Subscriber Certificate Authority Information Access field
  • 13:10 start investigating the issue, review of existing TLS certificates issued after September 15th,
  • 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
  • 13:40 All effected TLS certificate profiles have been adjusted.
  • 21:21 Reply to e-mail sender

2024-03-11:

  • 08:00 Decision to revoke the effected TLS certificates within 5 days as a precautionary measure
  • 14:00 Informing all effected customers by e-mail

Root Cause Analysis

D-Trust issued certificates with a LDAP-URL in the Subscriber Certificate Authority Information Access field when it was allowed by the standards. As part of Ballot 62, the changes to the Subscriber Certificate Authority Information Access were also reviewed.

At the time we analyzed the ballot, we came to the following conclusion:
id-ad-caIssuers with the OID 1.3.6.1.5.5.7.48.2 should contain an HTTP URL of the Issuing CA's certificate, but it is not prohibited that an additional LDAP URL of the Issuing CA's certificate is also included. Other access methods are prohibited. However, the LDAP URL in id-ad-caIsuers is not another access method.

After analysing the discussions at the time the changes were made, we came today to the conclusion that there is a formal violation of the BRs, which makes it necessary to revoke the affected TLS certificates.

Furthermore, the linter in use didn’t show any warning or error during the testing and production process. We are using the most updated version of the linter.

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

Assignee: nobody → enrico.entschew
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [ov-misissuance]

Update to the Preliminary Incident Report

Summary

This is an update of the preliminary report.

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

After we were made aware of this fact, D-Trust adjusted its certificate profiles firstly, to avoid possible misunderstandings in this specific case in the future. And secondly, because our future products are already specified without any LDAP entry. TLS certificates issued after March 4th, 2024, 1:40PM UTC no longer contain the LDAP URL.

All affected customers were informed on March 11th, 2024 that D-Trust decided to revoke the effected certificates. We will revoke the affected certificates within the expected time frame.

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 TLS certificates will be revoked within the 5 days after March 11th, 2024.

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-03-04:

  • 13:00 Email via ssl-issue@bdr.de 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:

  • 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:

  • 14:13 Conformity Assessment Body was informed about the issue.

Root Cause Analysis

D-Trust issued certificates with a LDAP-URL in the Subscriber Certificate Authority Information Access field when it was allowed by the standards. As part of Ballot 62, the changes to the Subscriber Certificate Authority Information Access field were also reviewed.

At the time we analyzed the ballot, we came to the following conclusion:
id-ad-caIssuers with the OID 1.3.6.1.5.5.7.48.2 should contain an HTTP URL of the Issuing CA's certificate, but it is not prohibited that an additional LDAP URL of the Issuing CA's certificate is also included. Other access methods are prohibited. However, the LDAP URL in id-ad-caIsuers is not another access method.

After analyzing the discussions at the time the changes were made, on March 11th, 2024 we decided that there is a formal violation of the BRs, which makes it necessary to revoke the affected TLS certificates.

Furthermore, the linter in use didn’t show any warning or error during the testing and production process. We are using the most updated version of the linter ZLint.

Lessons Learned

What went well

  • The preliminary decision to remove the LDAP address from all TLS certificate profiles was quickly reached. The change was implemented immediately.
  • The majority of D-Trust’s customers have so far reacted quickly to the announcement that the affected certificates must be revoked within 5 days.
  • D-Trust's customers could be reached in good time as up-to-date customer contact information was available.

What didn't go well

  • Misinterpretation of the Baseline Requirements – For us, the requirements of the BRs are misleading in regard to the Subscriber Certificate Authority Information Access. Only a presentation during the 56th CA/B F2F provided clarity. This interpretation should be included in the BRs so that there is no more room for misunderstandings in the future.
  • Trust in the linters in use as technical instruments – That shows that human interpretation is still needed. It would be very helpful if in the future the linters were adapted to the new standards before they come into force.
  • We have received customer complaints that the revocation period is far too short. It shows again that the burden of exchanging the certificate in complex infrastructures within 5 days is still too high and too costly. That’s of course only if the TLS certificates need to be revoked but are not creating any harm to certificate consumers or contain misleading information.

Where we got lucky

  • Many customers reacted well. They understood that a revocation was necessary, even though the incident was a formality and they were not exposed to any security risk.

Action Items

Action Item Kind Due Date
Proposal to adjust the BRs in section Subscriber Certificate Authority Information Access Prevent 2024-06-01
Adaptation of ZLint Prevent 2024-06-01

Appendix

Details of affected certificates

Will be provided with a next update

It would be very helpful if in the future the linters were adapted to the new standards before they come into force.

Does D-Trust have any plans to dedicate resources to the development of the linter tools it relies on to help make this a reality? Is there an action item to take for this?

(In reply to Daniel McCarney from comment #2)

It would be very helpful if in the future the linters were adapted to the new standards before they come into force.

Does D-Trust have any plans to dedicate resources to the development of the linter tools it relies on to help make this a reality? Is there an action item to take for this?

Yes, we will support the development of linter tools. D-Trust will provide resources to support the further development of ZLint.

Two certificates were issued by Issuing CAs whose associated Root CAs are currently in the root inclusion process. Therefore, these certificates have not yet been accepted by CT logs.

Final Incident Report

Summary

This is the final incident report.

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

After we were made aware of this fact, D-Trust adjusted its certificate profiles firstly, to avoid possible misunderstandings in this specific case in the future. And secondly, because our future products are already specified without any LDAP entry. TLS certificates issued after March 4th, 2024, 1:40PM UTC no longer contain the LDAP URL.

All affected customers were informed on March 11th, 2024 that D-Trust decided to revoke the effected certificates.

On March 15th, 2024 we revoked all affected TLS certificates.

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 TLS certificates were revoked on March 15th, 2024.

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-03-04:

  • 13:00 Email via ssl-issue@bdr.de 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:

  • 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:

  • 14:13 Conformity Assessment Body was informed about the issue.

2024-03-15:

  • 15:30 All affected TLS certificates were revoked.

Root Cause Analysis

D-Trust issued certificates with a LDAP-URL in the Subscriber Certificate Authority Information Access field when it was allowed by the standards. As part of Ballot 62, the changes to the Subscriber Certificate Authority Information Access field were also reviewed.

At the time we analyzed the ballot, we came to the following conclusion:
id-ad-caIssuers with the OID 1.3.6.1.5.5.7.48.2 should contain an HTTP URL of the Issuing CA's certificate, but it is not prohibited that an additional LDAP URL of the Issuing CA's certificate is also included. Other access methods are prohibited. However, the LDAP URL in id-ad-caIsuers is not another access method.

After analyzing the discussions at the time the changes were made, on March 11th, 2024 we decided that there is a formal violation of the BRs, which makes it necessary to revoke the affected TLS certificates.

Furthermore, the linter in use didn’t show any warning or error during the testing and production process. We are using the most updated version of the linter ZLint.

Lessons Learned

What went well

  • The preliminary decision to remove the LDAP address from all TLS certificate profiles was quickly reached. The change was implemented immediately.
  • The majority of D-Trust’s customers have so far reacted quickly to the announcement that the affected certificates must be revoked within 5 days.
  • D-Trust's customers could be reached in good time as up-to-date customer contact information was available.

What didn't go well

  • Misinterpretation of the Baseline Requirements – For us, the requirements of the BRs are misleading in regard to the Subscriber Certificate Authority Information Access. Only a presentation during the 56th CA/B F2F provided clarity. This interpretation should be included in the BRs so that there is no more room for misunderstandings in the future.
  • Trust in the linters in use as technical instruments – That shows that human interpretation is still needed. It would be very helpful if in the future the linters were adapted to the new standards before they come into force.
  • We have received customer complaints that the revocation period is far too short. It shows again that the burden of exchanging the certificate in complex infrastructures within 5 days is still too high and too costly. That’s of course only if the TLS certificates need to be revoked but are not creating any harm to certificate consumers or contain misleading information.

Where we got lucky

  • Many customers reacted well. They understood that a revocation was necessary, even though the incident was a formality and they were not exposed to any security risk.

Action Items

Action Item Kind Due Date
Proposal to adjust the BRs in section Subscriber Certificate Authority Information Access Prevent 2024-06-01
Adaptation of ZLint Prevent 2024-06-01

Appendix

Details of affected certificates

https://bugzilla.mozilla.org/attachment.cgi?id=9391716

Thank you for this report. A few questions below.

In the timeline on 2023-02-06:

07:30 Check of existing certificate profiles against Ballot SC62

This check of existing certificate profiles against Ballot SC62 was also detailed in 1861069 and it appears the check was not effective in identifying both of these issues.

Question #1: Should there be an Action Item added to increase the effectiveness of your certificate profile reviews?

Also, in the timeline on 2024-03-11:

14:00 Email to all affected customers

Question #2: Should this activity be considered the preliminary report on findings resulting from the Certificate Problem Report sent on 2024-03-04, or was there a separate activity accounting for this action currently not detailed in the timeline? Section 4.9.5 of the TLS BRs specifies:

Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.

Finally, in the Timeline, we interpret the “Email via ssl-issue@bdr.de [...]” to be the receipt of the Certificate Problem Report, which if true, was on 2024-03-04.

Question #3: What events transpired between receiving the initial Certificate Problem Report and coming to the conclusion that D-Trust should revoke the affected subscriber certificates on 2024-03-11? The timeline describes revocation as a precautionary measure on this date, but the Root Cause Analysis Section later describes D-Trust’s acknowledgement of non-compliance with the TLS BRs on the same date.

Question #4: When considering this timeline, along with the above requirements from Section 4.9.5 of the TLS BRs, would D-Trust not consider revocation delayed for the affected certificates (necessitating a separate incident report)?

Specific to the current list of Action Items:

Question #5: Can you elaborate on “Adaptation of ZLint”? Is this intended to address some of what was listed in your second bullet point from “What didn’t go well”, or are there other Action Items that could be proposed?

Question #6: Is there consideration for incorporating pkilint? It appears that pkilint could have also been helpful in identifying, and possibly preventing, the mis-issuance reported in 1861069.

(In reply to Chris Clements from comment #6)

Thank you for this report. A few questions below.

In the timeline on 2023-02-06:

07:30 Check of existing certificate profiles against Ballot SC62

This check of existing certificate profiles against Ballot SC62 was also detailed in 1861069 and it appears the check was not effective in identifying both of these issues.

Question #1: Should there be an Action Item added to increase the effectiveness of your certificate profile reviews?

Also, in the timeline on 2024-03-11:

14:00 Email to all affected customers

Question #2: Should this activity be considered the preliminary report on findings resulting from the Certificate Problem Report sent on 2024-03-04, or was there a separate activity accounting for this action currently not detailed in the timeline? Section 4.9.5 of the TLS BRs specifies:

Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.

Finally, in the Timeline, we interpret the “Email via ssl-issue@bdr.de [...]” to be the receipt of the Certificate Problem Report, which if true, was on 2024-03-04.

Question #3: What events transpired between receiving the initial Certificate Problem Report and coming to the conclusion that D-Trust should revoke the affected subscriber certificates on 2024-03-11? The timeline describes revocation as a precautionary measure on this date, but the Root Cause Analysis Section later describes D-Trust’s acknowledgement of non-compliance with the TLS BRs on the same date.

Question #4: When considering this timeline, along with the above requirements from Section 4.9.5 of the TLS BRs, would D-Trust not consider revocation delayed for the affected certificates (necessitating a separate incident report)?

Specific to the current list of Action Items:

Question #5: Can you elaborate on “Adaptation of ZLint”? Is this intended to address some of what was listed in your second bullet point from “What didn’t go well”, or are there other Action Items that could be proposed?

Question #6: Is there consideration for incorporating pkilint? It appears that pkilint could have also been helpful in identifying, and possibly preventing, the mis-issuance reported in 1861069.

Dear Chris,
Thanks for your questions. Please find our answers below.

To Question #1:
This issue occurred, because the language of the BRs was from our perspective not clear. Because of the incident we think the BRs should be more precise (e.g. must not contain any ldap url), to outline the requirements without any doubt or external information, such as presentations or forum threads.
Currently we consider an Action Item within our certificate profile reviews not to be effective.

To Question #2:
We consider the information provided to be compliant with die BRs. Hence we think our actions and analysis were process compliant, as we considered our investigation to be absolutely relevant to complete the steps and process requirements in question; with our target and customer based approach.

To Question #3:
At the time we analyzed the ballot, we came to the following conclusion:
id-ad-caIssuers with the OID 1.3.6.1.5.5.7.48.2 should contain an HTTP URL of the Issuing CA's certificate, but it is not prohibited that an additional LDAP URL of the Issuing CA's certificate is also included. Other access methods are prohibited. However, from our point of view the LDAP URL in id-ad-caIsuers is not another access method.

We needed time to collect all necessary information to analyze the situation.

After collecting and analyzing all information from external sources, we understood on March 11th that there is another interpretation of the BRs. Therefore, we decided that under these circumstances this interpretation of the BRs makes it necessary to revoke the affected TLS certificates.

To Question #4:
Please see answer to Question 2 and 3.

To Question #5:
Our first aim is to ensure that linters are adapted to the new standards, before they come into force. Hence, such errors can be avoided from the outset. D-Trust will provide resources to support the further development of ZLint. However, we are open to additional suggestions and are happy to collaborate.

To Question #6:
We decided on ZLint because we’d like to use the most updated version of this linter. The more linters that support adaptation to the new standards before they come into force, the better it is for the CAs and therefore for the customers. We will evaluate the use of pkilint in the future.

Quick Update: There is nothing new to report.

Quick Update: There is nothing new to report.

Unfortunately, we have a delay in both action items we wanted to have finished by June 01, 2024. We are planning to complete both action items in the next 4 weeks.

Let me quickly explain why we have the delay: For the planned ZLint changes, we need support from a partner company. The process for this was not started on time. We underestimated the amount of time the internal procedures take.

Regarding the proposed changes to adjust the BRs in section Subscriber Certificate Authority Information Access, the internal discussion process is ongoing. But that should be finished within the next two weeks. The proposal is in the last stages of developement.

Quick update: Our partner company created the pull request for ZLint to address the checks of the Subscriber Certificate Authority Information Access field. You can find it here: https://github.com/zmap/zlint/pull/852.

Quick update: We presented the proposal to adjust the BRs in section Subscriber Certificate Authority Information Access during the last meeting of the Validation Subcommittee of the Server Certificate Working Group and got good feedback. We were asked to check whether the proposed language is also applicable for CRL Distribution Points and the content of id-qt-cps. After finishing that, we will open a pull request on github and distribute the link here as well as through the mailing list of the Validation Subcommittee to discuss the change.

Quick update: We continue to work on ZLint. A new pull request has been created to address the need to use only the http scheme for OCSP in the context of authorityInformationAccess. You can find it here: https://github.com/zmap/zlint/pull/860

Quick update: There is nothing new to report.

Quick update: We have also applied the proposed changes to CRL Distribution Points and the content of id-qt-cps in the BRs. We still have a minor ambiguity. As soon as this has been clarified, we will publish the link to the proposal here and start the discussion. This should be at the beginning of next week.

Quick update: Here is the suggested github-link to the possible changes to the BRs: https://github.com/cabforum/servercert/pull/534
The changes are open for comments.

Quick update: There is nothing new to report.

Quick update: The proposed changes regarding the Subscriber Certificate Authority Information Access field are part of ZLint v3.6.3-rc1. The proposed changes to introduce the definition of scheme according to RFC 3986, section 3.1 to the BRs are drafted and can be discussed now. Our next goal is to include them in a ballot proposal for an adjustment of the BRs.

There is nothing new to report.

There is nothing new to report.

Hi Enrico,

A few questions below:

  • Lines 2598 and 2599 of the attachment appear as “https://crt.sh/?sha256=not CT-logged". Do you intend to log these certificates, or otherwise make them publicly-available for evaluation?
  • A random sampling identifies these affected certificates that do not contain a revocation reason code (examples: 1, 2, 3). Can you help us understand, from D-Trust’s perspective, whether this is consistent with the expectations of TLS BR 4.9.1.1 (12) (“The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement (CRLReason #4, superseded);”).

Thanks,
Ryan

Flags: needinfo?(enrico.entschew)

Hi Ryan,

Thank you for your questions.

I will upload the two certificates which are not CT logged to this ticket.

On your second point, this is a violation of the TLS BRs. I will open a new incident report on Bugzilla. A first quick investigation revealed that the internal revocation ticket didn’t contain the revocation reason code. For this reason, no reason code was provided as part of the revocation.

We will investigate the case and report on the incident in the new incident report. The number of the incident report will be communicated soon.

Thanks,
Enrico

Flags: needinfo?(enrico.entschew)

These are the two affected TLS certificates without a CT log entry.

This is the newly opened Bugzilla incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1913310

(In reply to Enrico Entschew from comment #23)

Created attachment 9419236 [details]
affected certificates with no CT log

These are the two affected TLS certificates without a CT log entry.

I've submitted these two certificates to some CT logs, so you can now find them here:
https://crt.sh/?sha256=30A63E1C18AF4446CD1322DA48FEF60166FBCACF4B3695E12B4E9D3276D4D1AE&opt=pkimetal
https://crt.sh/?sha256=37D06B714373C8AF7ABE6299E949EAA7FABF10D0CD8379AA58869F05E8563DBC&opt=pkimetal

Neither of these certificates contain an LDAP caIssuers URL though, so I'm not clear why you consider them to be "affected".

(In reply to Rob Stradling from comment #25)

Thanks, Rob.

You are right. They are not affected. We investigated this issue. Back in March when searching for the certificates affected by the original incident, our product management carried out a query of all TLS certificates issued in the period from 15/09/2023 to 04/03/2024.

The query was made based on selected product groups. A product group consists in several product types. In this specific case we didn’t take into account, that we have already added our rollover product types to this PTC TLS product group. As a result we had two additional product types that were not affected by the non-compliance in our query result containing this two certificates.

No end-user TLS certificates have yet been issued from either product type, only certificates for test websites, as the associated roots are still in the root inclusion process.

As part of this ticket, we had proposed various action items. The current status is as follows:

The proposal for adjusting the BRs in section 7.1.2.7.7 (Subscriber Certificate Authority Information Access) is very advanced, has already been discussed in the Validation Subcommittee, and will hopefully be introduced as a ballot in the near future.

The adaptation of ZLint has been carried out. The change is live.

Are there other issues to be addressed within this ballot?

I kindly ask you to check whether this incident can be closed.

Flags: needinfo?(bwilson)

I'll close this on Wed. 11-Sept-2024.

Status: ASSIGNED → RESOLVED
Closed: 19 days ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: