2012511 - D-Trust: CRL HTTP Media Type

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Laura Martorano]

Preliminary Incident Report

Summary

• Incident description: D-Trust received an external report indicating that our HTTP CRL distribution endpoints currently serve CRLs using the media type x-pkcs7-crl instead of application/pkix-crl as specified in RFC 5280, Section 4.2.1.13 (CRL Distribution Points). Because RFC 5280 is treated as a normative reference, this is a deviation from RFC 5280 expectations for CRL publication. At this stage, the potential impact of changing the media type is under active investigation, including any potential interoperability effects. We are disclosing this issue proactively to ensure transparency while our analysis continue.
• Relevant policies: RFC 5280, Section 4.2.1.13 (CRL Distribution Points)
• Source of incident disclosure: Third Party Reported

Comment 1

[Jaime Hablutzel]

I might be wrong here (didn't check further), but the need for application/pkix-crl in the content-type is just a recommendation (note the "SHOULD"):

HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-crl in the content-type header field of the response.

Comment 2

[Peter Cooper Jr.]

Yes, but "SHOULD" means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." And so, if the CA didn't intentionally choose and carefully weigh whether to follow the recommendation or not, it may be helpful to the community and to other CAs to describe how a different media type came to be used. That is, it sounds (from the fact that this is being disclosed at all) that the fact that this didn't comply with the "SHOULD" in the RFC may have been a surprise, and so it may be valuable to follow the incident reporting process even if the resulting behavior itself isn't necessarily "wrong".

Comment 3

[Ana Laura Martorano]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000022
• Incident description: CRLs were served via HTTP using the media type application/x-pkcs7-crl instead of the recommended media type application/pkix-crl as specified in RFC 5280, Section 4.2.1.13. While the RFC defines this requirement as a SHOULD, D-Trust determined—following review—that no current technical or operational justification existed for deviating from the recommendation. The configuration was therefore updated to align with RFC 5280.
• Timeline summary:
  • Non-compliance start date: N/A
  • Non-compliance identified date: 2026-01-23 
  • Non-compliance end date: 2026-02-05
• Relevant policies: RFC 5280, Section 4.2.1.13
• Source of incident disclosure: Third-party reported

Impact

• Total number of certificates: N/A
• Total number of "remaining valid" certificates: N/A
• Affected certificate types: N/A
• Incident heuristic: (2) No certificates affected
• Was issuance stopped in response to this incident, and why or why not?: No
• Analysis: N/A
• Additional considerations:

Timeline

Before 2008: CRL distribution initially configured using application/x-pkcs7-crl
2026-01-23, 21:31: External notification received referencing CRL Watch by sslmate
2026-01-24, 18:28: Response to the reporter, that we received the request and will start our investigation
2026-01-26, 08:30: Internal investigation and review of CRL delivery configuration started
2026-02-04, 13:00: Internal investigation ended; Determination that no current justification for deviation existed
2026-02-05: CRL delivery configuration updated to application/pkix-crl

Related Incidents

Bug	Date	Description
None	-	No directly related incidents identified

Root Cause Analysis

Contributing Factor #: Legacy MIME type retained

• Description: The CRL distribution endpoints were configured to serve CRLs using the media type application/x-pkcs7-crl. This configuration originated from early PKI deployment practices, where non-registered, PKCS#7-based media types were commonly used as informal conventions to support interoperability across heterogeneous client environments. Over time, the configuration remained in place
  Following an external notification referencing CRL Watch (https://sslmate.com/labs/crl_watch/), D-Trust reviewed the configuration in the context of its current client landscape and concluded that the original interoperability considerations no longer applied. No technical or operational reasons to continue deviating from the RFC 5280 recommendation were identified.
• Timeline: Before 2008 – 2026-02-05
• Detection: Third-party reported
• Interaction with other factors:
• Root Cause Analysis methodology used: 5 whys analysis

Lessons Learned

• What went well: The issue was promptly acknowledged following the external notification. A targeted technical review was performed, and the configuration was updated once it was confirmed that no valid justification for deviation remained.
• What didn’t go well: The reasoning behind the deviation from a SHOULD-requirement in RFC 5280 was not questioned for too long.
• Where we got lucky: The deviation was limited to HTTP delivery metadata and did not affect CRL correctness, availability, or revocation processing.
• Additional:

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Serve CRLs with application/pkix-crl	Corrective	Root Cause # 1	Correct Content-Type (externally verifible)	2025-02-05	Completed
Integrate CRL Watch (https://sslmate.com/labs/crl_watch/) monitoring	Prevent	Root Cause # 1	Continuous, automated “CRL Watch” monitoring integrated into internal alerting. Effectiveness measured by absence of unresolved “CRL Watch” findings over time, supported by periodic (6 months) qualitative reviews.	2025-03-02	Planned

Appendix

Comment 4

[Enrico Entschew]

We started with the implementation of “Integrate CRL Watch (https://sslmate.com/labs/crl_watch/) monitoring”. D-Trust continues to monitor this ticket.

Comment 5

[Ana Laura Martorano]

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

Comment 6

[Enrico Entschew]

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

Comment 7

[Ana Laura Martorano]

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

Comment 8

[Ana Laura Martorano]

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

Comment 9

[Ana Laura Martorano]

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

Comment 10

[Enrico Entschew]

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

Comment 11

[bsmith]

It's now over a year since the second action item has been due (due 2025-03-02), is there really nothing new to report on its progress?

Comment 12

[erakura]

Based upon the dates provided in the rest of the Full Incident Report, I assume that the 2025 dates in the Action Items are mistaken and should actually say 2026.

With that said, if the remaining Action Item is taken to be due on 2026-03-02, we are now 25 days past that date. Can D-Trust comment on this overdue Action Item?

Comment 13

[Enrico Entschew]

Apologies for the delayed update and the confusion caused by the missing status report on the action item “Integrate CRL Watch (https://sslmate.com/labs/crl_watch/) monitoring”.

To clarify: The integration of CRL Watch (https://sslmate.com/labs/crl_watch/) monitoring has been completed as of 2026-02-12. Automated monitoring is active and integrated into our internal alerting infrastructure. The action item is therefore completed, ahead of the originally stated due date of 2026-03-02.

We also confirm that the due dates listed in the Action Items table (showing "2025-02-05" and "2025-03-02") are indeed typos and should read 2026-02-05 and 2026-03-02, as noted in Comment 12. We will correct this in a follow-up report update.

Comment 14

[Enrico Entschew]

D-Trust is currently preparing the closure report for this incident. In the meantime, we will continue to monitor this bug.

Comment 15

[Enrico Entschew]

Report Closure Summary

• Incident description: D-Trust received an external report indicating that its HTTP CRL distribution endpoints were serving CRLs using the media type application/x-pkcs7-crl instead of the RFC 5280-recommended media type application/pkix-crl. Following internal review, D-Trust determined that no current technical or operational justification existed for continuing this deviation and updated the configuration accordingly.

• Incident Root Cause(s): The root cause was a legacy CRL delivery configuration that had been retained from early PKI deployment practices, when non-registered PKCS#7-based media types were commonly used as informal interoperability conventions. After re-evaluating the current client landscape, D-Trust concluded that the original interoperability considerations no longer applied and that there were no valid reasons to continue deviating from the RFC 5280 recommendation.

• Remediation description: D-Trust updated the CRL delivery configuration on 2026-02-05 so that CRLs are now served with the media type application/pkix-crl. In addition, D-Trust completed integration of CRL Watch monitoring as of 2026-02-12; automated monitoring is now active and integrated into the internal alerting infrastructure.

• Commitment summary: Beyond the completed action items, D-Trust will continue to follow relevant public community discussions and policy developments for indications that technical configurations may require reassessment. Where indicated, D-Trust will review the affected configuration and determine whether adjustments are appropriate.

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

Comment 16

[incident-reporting]

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

Otherwise, it will be closed on approximately 2026-04-18.