Closed Bug 1906467 Opened 1 year ago Closed 1 year ago

Entrust: S/MIME mailbox address not in subjectAltName

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bruce.morton, Assigned: bruce.morton)

Details

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

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

Preliminary Incident Report

Summary

On 2024-07-02 19:50 UTC we received an internal certificate problem report based on a pkilint error about a potential certificate mis-issuance. At 2024-07-03 10:58 UTC, manual review of the error report determined there was a mis-issuance and we halted S/MIME certificate issuance at 2024-07-03 13:13 UTC.

One certificate was mis-issued because a mailbox address in the subject commonName was not included in the subjectAltName as required by section 7.1.4.2.1 of the S/MIME Baseline Requirements, which states:

All Mailbox Addresses in the subject field or entries of type dirName of this extension SHALL be repeated as rfc822Name or otherName values of type id-on-SmtpUTF8Mailbox in this extension.

Impact

One (1) S/MIME Sponsor-Validated certificate issued at 2024-07-02 19:21 UTC. The certificate was not expired or revoked when the problem was reported.

Timeline

All times are UTC.

2024-07-02:

  • 19:50 Email received from post-issuance linting software indicating an error was found by pkilint that a mailbox address was “not found in SAN”.
  • 19:56 Started initial investigation.

2024-07-03:

  • 00:51 Investigation was escalated.
  • 10:58 Investigation determined that a certificate was mis-issued per S/MIME BR section 4.9.1.1 item 11. Directions were provided to halt S/MIME certificate issuance and to search the S/MIME certificate database for any other impacted certificates.
  • 13:13 S/MIME certificate issuance was halted.

2024-07-04:

  • 02:13 Informed subscriber of impacted certificate.

Next steps

The impacted certificate will be revoked on or before 2024-07-08 10:58 UTC, which is per S/MIME BR section 4.9.1.1 item 11, 120h/5-day timeline.

A full incident report including the root cause analysis, lessons learned, and action items will be posted within two weeks per the CCADB full incident report requirement, which is on or before 2024-07-17 10:58 UTC.

Status: RESOLVED → REOPENED
Component: General → CA Certificate Compliance
Ever confirmed: true
Product: Invalid Bugs → CA Program
Resolution: INVALID → ---
Assignee: nobody → bruce.morton
Type: defect → task
Whiteboard: [ca-compliance] [smime-misissuance]
Status: REOPENED → ASSIGNED

The impacted certificate was revoked 2024-07-08 07:58:10 UTC.

We are working on the full incident report and it will be posted per schedule.

Incident Report

Summary

On 2024-07-02 19:50 UTC we received an internal notification of a pkilint error about a potential certificate mis-issuance. At 2024-07-03 10:58 UTC, manual review of the error report determined there was a mis-issuance and we halted S/MIME certificate issuance at 2024-07-03 13:13 UTC.

One certificate was mis-issued because a mailbox address in the subject commonName was not included as a rfc822Name subjectAltName as required by section 7.1.4.2.1 of the S/MIME Baseline Requirements, which states:

All Mailbox Addresses in the subject field or entries of type dirName of this extension SHALL be repeated as rfc822Name or otherName values of type id-on-SmtpUTF8Mailbox in this extension.

Accordingly, revocation was required within 5 days per S/MIME BR section 4.9.1.1 item 11.

Impact

One (1) S/MIME Sponsor-Validated certificate issued at 2024-07-02 19:21 UTC. The certificate was not expired or revoked when the problem was discovered .

Timeline

All times are UTC.

2024-07-02:

  • 19:50 Email received from post-issuance linting software indicating an error was found by pkilint that a mailbox address was “not found in SAN ”.
  • 19:56 Started initial root cause analysis.

2024-07-03:

  • 00:51 Investigation was escalated.
  • 10:58 Investigation determined that a certificate was mis-issued because it was not in accordance with section 7.1.4.2.1 of the S/MIME Baseline Requirements (S/MIME BRs) and revocation was required within 5 days per S/MIME BR section 4.9.1.1 item 11. Directions were provided to halt S/MIME certificate issuance and to search the S/MIME certificate database for any other impacted certificates.
  • 13:13 As an immediate response to this incident, S/MIME certificate issuance was halted .
  • 16:19 From the database search, no other miss-issued certificates were found for this incident.

2024-07-04:

  • 02:13 Informed subscriber of impacted certificate.

2024-07-05:

  • 18:51 Software fix deployed to ensure the mailbox address in the subject CN field matches the mailbox address in the subject email field. , and cCertificate issuance was re-instated .

2024-07-08:

  • 07:58 The mis-issued certificate was revoked.

Root Cause Analysis

Why does Entrust allow a mailbox address to be listed in the CN and Email address?

Entrust recognizes that many of our customers have specific use cases necessitating the inclusion of a mailbox address in the CN field. We preserved this flexibility when implementing the SM BRs on September 1st, 2023, to ensure seamless continuity and integration with our APIs for our customers.

Why was the mailbox address in the subject commonName not included in the subjectAltName?

Our REST API and UI allow users to enter an email address in the CN field of the certificate, which can differ from the email address listed in the E= field. Currently, our system adds the mailbox address from the E= field as a subjectAltName, but it does not include the mailbox address listed in the CN due to a limitation that permits only one rfc822Name subjectAltName in S/MIME certificates. Although we anticipated that customers would enter the one email address in both fields, we did not implement sufficient system validation to ensure they match. We now no longer accept email address specified in the common name different than the mailbox address.

Why is there a limitation on having one rfc822Name subjectAltName in the S/MIME certificate?

This is an existing limitation in our system, where the system was not designed to support more than one subjectAltName SANs in the certificate.

What restrictions were put in place to prevent this from happening again?

We added validation in the UI and REST API to ensure the mailbox address in the CN matches the mailbox in the E= field.

Why was the incident not detected before the certificate was signed?

The pkilint software was used to only perform post-issuance linting not pre-issuance linting. Linting will be updated to use zlint and pkilint before an S/MIME certificate is signed.

Lessons Learned

What went well

  • pkilint detected the mis-issuance
  • only one mis-issued certificate
  • certificate issuance halted, so no other mis-issued certificates were issued
  • revocation happened within the required timeframe

What didn't go well

  • issue detected after certificate signing

Where we got lucky

  • no other active certificates had this issue

Action Items

Action Item Kind Due Date
Implement pre-sign linting for S/MIME Detect 2024-11- 30

Appendix

Details of affected certificates

Issuer: https://crt.sh/?caid=12549

  • S/N: CB48483E66A43F98000000004C3DD077; SHA-256 Fingerprint: 17D0710111F06B2E458B429D48AB2E92E863D5645A515F6F4D0D627238997995

The S/MIME BRs, Section 4.9.1.1, say:

The CA... SHALL revoke a Certificate within 5 days if... [t]he CA is made aware that the Certificate was not issued in accordance with these Requirements

Based on the timeline contained in this incident report, it appears that the CA was made aware that the certificate was misissued via an email notification by 2024-07-02 19:56 UTC at the latest. The certificate was revoked at 2024-07-08 07:58 UTC. This is a time period of over five and a half days.

This report says:

2024-07-03 10:58 Investigation determined that a certificate was mis-issued because it was not in accordance with section 7.1.4.2.1 of the S/MIME Baseline Requirements (S/MIME BRs) and revocation was required within 5 days per S/MIME BR section 4.9.1.1 item 11. Directions were provided to halt S/MIME certificate issuance and to search the S/MIME certificate database for any other impacted certificates.

My interpretation of this sentence is that the CA started the 5-day revocation clock at the time they confirmed the misissuance, not at the time they were made aware of the misissuance. Can the CA please clarify whether this interpretation is correct, and why they believe this interpretation is in accordance with the S/MIME BRs?

(In reply to Aaron Gable from comment #6)

The S/MIME BRs, Section 4.9.1.1, say:

The CA... SHALL revoke a Certificate within 5 days if... [t]he CA is made aware that the Certificate was not issued in accordance with these Requirements

Based on the timeline contained in this incident report, it appears that the CA was made aware that the certificate was misissued via an email notification by 2024-07-02 19:56 UTC at the latest. The certificate was revoked at 2024-07-08 07:58 UTC. This is a time period of over five and a half days.

This report says:

2024-07-03 10:58 Investigation determined that a certificate was mis-issued because it was not in accordance with section 7.1.4.2.1 of the S/MIME Baseline Requirements (S/MIME BRs) and revocation was required within 5 days per S/MIME BR section 4.9.1.1 item 11. Directions were provided to halt S/MIME certificate issuance and to search the S/MIME certificate database for any other impacted certificates.

My interpretation of this sentence is that the CA started the 5-day revocation clock at the time they confirmed the misissuance, not at the time they were made aware of the misissuance. Can the CA please clarify whether this interpretation is correct, and why they believe this interpretation is in accordance with the S/MIME BRs?

You are correct. We treat post-issuance linting findings as Certificate Problem Reports (CPRs). Whether through linting or externally submitted, the reports must be investigated to validate that they are indeed issues. The post-issuance linting runs a broad set of lints against certificates, which can result in some of the reported findings being invalid. We use the review of these automated CPRs to refine our pre-issuance and post-issuance linting policies.

In this case, we started the 5-day clock when we had investigated sufficiently to determine that the error identified in the revocation related notice was indeed a mis-issuance (not from the moment when the revocation-related notice was received). We believe this is an appropriate interpretation based on:

“Section 4.9.1.1.
… The CA SHOULD revoke a Certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:
… Item 11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s CP and/or CPS.”

(In reply to Bruce Morton from comment #7)

In this case, we started the 5-day clock when we had investigated sufficiently to determine that the error identified in the revocation related notice was indeed a mis-issuance (not from the moment when the revocation-related notice was received). We believe this is an appropriate interpretation based on:

“Section 4.9.1.1.
… The CA SHOULD revoke a Certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:
… Item 11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s CP and/or CPS.”

You seem to have forgotten the requirements in 4.9.5, which determines the timelines involved with certificate problem reports:

"""
4.9.5 Time within which CA must process the revocation request

[...] 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. [...]
"""

(emphasis mine)

This clearly describes that the clock starts the moment you receive the CPR, and not only after you've verified its contents.

Thanks for the response. We understand that there may be more than one interpretation for the interplay between sections 4.9.5 and 4.9.1.1. We have created a delayed revocation incident report to address this topic, https://bugzilla.mozilla.org/show_bug.cgi?id=1910237.

We have no updates for this week but will keep following this bug for any questions or feedback.

May we please set the next update at 2024-09-04.

Whiteboard: [ca-compliance] [smime-misissuance] → [ca-compliance] [smime-misissuance] Next update 2024-09-04

We will continue to monitor.

Please set next update to 2024-10-31. Thanks.

Whiteboard: [ca-compliance] [smime-misissuance] Next update 2024-09-04 → [ca-compliance] [smime-misissuance] Next update 2024-10-31

We are on track to implement pre-sign linting for S/MIME before 2024-11-30.

May we please set the next update to be 2024-11-30? Thanks.

Whiteboard: [ca-compliance] [smime-misissuance] Next update 2024-10-31 → [ca-compliance] [smime-misissuance] Next update 2024-11-30
Action Item Kind Due Date
Implement pre-sign linting for S/MIME Detect Done

Pre-sign linting for S/MIME deployed 2024-11-07.

All actions are completed. We request this bug be closed. Thanks.

I will consider closing this on or about next Wed. 13-Nov-2024, unless there is ongoing discussion.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 1 year ago → 1 year ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Whiteboard: [ca-compliance] [smime-misissuance] Next update 2024-11-30 → [ca-compliance] [smime-misissuance]
You need to log in before you can comment on or make changes to this bug.