1879845 - Asseco DS / Certum: S/MIME certificates with error in subjectAlternativeName

Status: REOPENED

(CA Program :: CA Certificate Compliance, task)

Description

[Kateryna Aleksieieva]

Preliminary Incident Report

Summary

Certum's compliance team found that Certum issued a number of S/MIME certificates with incorrect subjectAlternativeName.

Full incident report will be provided no later than on February 19th.

Comment 1

[Kateryna Aleksieieva]

Incident Report

Summary

Certum has issued 96 SMIME certificates since January 16, 2024, with invalid content in SubjectAlternativeName.

Impact

After January 16th, 2024, a total of 96 SMIME certificates were issued with invalid content in SubjectAlternativeName.

Upon identifying this error on February 12, 2024, Certum stopped the issuance of SMIME certificates. On February 13, 2024, the system fix version was deployed, and after that the certificate issuance process was resumed.

All certificates affected by this mis-issuance have been revoked.

Timeline

All time is CET.

2024-01-16

21:00 The system version with an error was deployed.

2024-02-12

9:00 During routine certificate review, we encountered 1 certificate containing an error in SubjectAlternativeName field and initiated an analysis.

9:05 Certificate issuance of new S/MIME certificates was suspended.

10:30 We confirmed the error, identified that it only affects S/MIME Sponsor, Organization and Individual certificates.

14:22 A preliminary report was filed in bugzilla.

15:55 System fix version was released.

16:55 The list of the affected certificates and customers was provided; it was assessed that for the list a data fix could be made to allow reissue process without duplicating error.

21:15 Data fix that corrects the subjectAlternativeName value was executed to allow reissuance of certificates with correct SAN entry.

2024-02-13

7:00 The affected customers were informed and were asked to replace and revoke the affected certificates as soon as possible.

11:00 We conducted additional checks and detected one additional certificate affected by the error.

21:00 System fix version is deployed.

2024-02-14

9:00 We restarted issuance of S/MIME Sponsor, Organization and Individual certificates.

2024-02-16

14:30 All affected certificates were revoked.

Root Cause Analysis

On January 16th, we deployed a version with a new interface for retail customers, featuring a new flow for selecting CN for S/MIME. The problem appeared when a customer changed CN, there was a possibility that the system saved CN in the SAN field, while the correct email was still being entered in the email field. Nonetheless, when the chosen CN happened to be an email, SAN had the correct entry - the email.

Lessons Learned

What went well

• Quick identification and resolution of the problem after it was detected.

• Efficient communication with clients and smooth exchange of certificates made it possible for us to revoke all affected certificates on time.

What didn't go well

• The problem was not noticed during application testing.

• No errors occurred during certificate issuance on the production system.

Where we got lucky

• Not all S/MIME Sponsor, Organization and Individual certificates were affected.

• S/MIME Mailbox certificates weren’t affected at all.

Action Items

Action Item	Kind	Due Date
Add new test scenarios for this and similar errors	Prevent	2024-02-19
Include linting for SMIME issuing process	Detect	2024-10-01

Appendix

Details of affected certificates

List of affected certificates is provided in attachments

Comment 2

[Kateryna Aleksieieva]

Attachment: Affected certificates Serial Number List.txt

Comment 3

[Kateryna Aleksieieva]

We have added test scenarios mentioned in action items, apart from that - we have no additional update to this bug.

Comment 4

[Kateryna Aleksieieva]

We have no update in this bug.

Comment 5

[Kateryna Aleksieieva]

We have no updates on this bug. Can it be closed if the community does not have any questions?

Comment 6

[Aaron Gable]

The CCADB Incident Report Template says that "the Appendix must include a listing of the complete certificate details of all affected certificates" (emphasis mine). The attached file contains only serials numbers and certificate fingerprints, and these certificates do not appear to exist in crt.sh, so the community still cannot see the complete details of these certificates. If possible, please provide the full contents of all affected certificates, or links to where those contents can be seen, or provide justification for why the full contents cannot be shared here.

I ask because after reading this incident report I am still confused as to exactly what content was in the SAN. Was is an unvalidated email address? An incorrectly-formatted email address? Nonsense bytes? The sentence "The problem appeared when a customer changed CN, there was a possibility that the system saved CN in the SAN field, while the correct email was still being entered in the email field" is not clear to me.

Comment 7

[Kateryna Aleksieieva]

(In reply to Aaron Gable from comment #6)

The CCADB Incident Report Template says that "the Appendix must include a listing of the complete certificate details of all affected certificates" (emphasis mine). The attached file contains only serials numbers and certificate fingerprints, and these certificates do not appear to exist in crt.sh, so the community still cannot see the complete details of these certificates. If possible, please provide the full contents of all affected certificates, or links to where those contents can be seen, or provide justification for why the full contents cannot be shared here.

Hello,

Thank you for your question. We only made certificate number + SHA256 hash of the certificate available because affected certificates contain data such as name, surname or email address and we did not want them to reach a wider group unnecessarily.

I ask because after reading this incident report I am still confused as to exactly what content was in the SAN. Was is an unvalidated email address? An incorrectly-formatted email address? Nonsense bytes? The sentence "The problem appeared when a customer changed CN, there was a possibility that the system saved CN in the SAN field, while the correct email was still being entered in the email field" is not clear to me.

I will try to clarify what happened and what content was in the SAN.
In our system, the default value for the CN in S/MIME certificate is the Mailbox Address. For example, if the user's email address is [e-mail], the default CN and the SAN would be:
CN=[e-mail]
E=[e-mail]
SAN=[e-mail]

However, in S/MIME Sponsor, Organization and Individual certificates, customers may want to change the CN to a different value, such as their Personal Name or Organization Name. In this case, the system should not overwrite the SAN and E field with the new CN value but keep the original email address. For example, if the user changes the CN to Alice Smith, the CN and the SAN should be:
CN=Alice Smith
E=[e-mail]
SAN=[e-mail]

The problem that occurred was that the system did not handle this scenario correctly, and instead of keeping the original email address as the SAN, it copied the new CN value to the SAN. This resulted in SAN that did not match the email address in the Subject email field E. For example:
CN=Alice Smith
E=[e-mail]
SAN=Alice Smith

The correct email was still in the Subject email field E and that email was validated.
I hope this explanation has cleared up your confusion.

Comment 8

[Aaron Gable]

Thank you, yes, that is much clearer.

When these values (e.g. "Alice Smith") were included in the SAN, how were they encoded? The Subject Common Name field is simply a printableSteing, but the Subject Alternative Names extension requires that each value within it be tagged with what kind of name it is, e.g. a dnsName for domain names or an rfc822Name for email addresses. When a name like "Alice Smith" was included in the SANs, was it encoded as an rfc822Name, or as something else?

I will note that this explanation makes it clear that this incident is not just a case of "invalid content" in the SAN, but also a violation of the S/MIME BRs Section 7.1.4.2.1 Subject Alternative Name Extension:

All Mailbox Addresses in the subject field... SHALL be repeated as rfc822Name... in this extension.

Comment 9

[Kateryna Aleksieieva]

(In reply to Aaron Gable from comment #8)

Thank you, yes, that is much clearer.

When these values (e.g. "Alice Smith") were included in the SAN, how were they encoded? The Subject Common Name field is simply a printableSteing, but the Subject Alternative Names extension requires that each value within it be tagged with what kind of name it is, e.g. a dnsName for domain names or an rfc822Name for email addresses. When a name like "Alice Smith" was included in the SANs, was it encoded as an rfc822Name, or as something else?

The encoding was rfc822Name, system did not change encoding for the field, just the content.

I will note that this explanation makes it clear that this incident is not just a case of "invalid content" in the SAN, but also a violation of the S/MIME BRs Section 7.1.4.2.1 Subject Alternative Name Extension:

All Mailbox Addresses in the subject field... SHALL be repeated as rfc822Name... in this extension.

You are right, thank you for pointing it out. This will help us enhance the quality of our reports in future.

Comment 10

[Kateryna Aleksieieva]

We have no updates on this bug.
I'd like to suggest closing it, unless there are any further questions.

Comment 11

[Ben Wilson]

I will close this on Wed. 27-Mar-2024, unless there are any questions.

Comment 12

[Ben Wilson]

Reopening this based on Bug #1888689.

Comment 13

[Kateryna Aleksieieva]

We will keep you updated on our progress and I'd like to ask for scheduling the next update for October 1st to avoid weekly updates.

Comment 14

[Kateryna Aleksieieva]

Attachment: ## Incident Report ### Summary Cross-certificate SHA-256 FINGERPRINT 949424DC2CCAAB5E9E80D66E0E3F7DEEB3201C607D4315EF4C6F2D93A917279D was not included in 2024 S/MIME Audit statement ### Impact Cross-certificate was not included in the a

Comment 15

[Zacharias]

(In reply to Kateryna Aleksieieva from comment #7)

Thank you for your question. We only made certificate number + SHA256 hash of the certificate available because affected certificates contain data such as name, surname or email address and we did not want them to reach a wider group unnecessarily.

I think that this was a good decision, and follows the data minimization principle of GDPR. While that of course has other supervising authorities, the goal of keeping physical persons information is shared.