SSL.com: Issuance of one Sponsored-Validated S/MIME certificate with organization information in givenName and surName of the subjectDN
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: secauditor, Assigned: secauditor)
Details
(Whiteboard: [ca-compliance] [smime-misissuance])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Steps to reproduce:
Summary
A Sponsored-Validated S/MIME certificate, issued by an enterprise customer, had the organization information in the givenName and surName fields of the subjectDN.
The Subscriber used the bulk order tool for active ePKI agreements to issue 26 Sponsor-validated S/MIME certificates. 25 certificates were correctly issued to natural entities. 1 certificate was intended to be an OV only S/MIME certificate. The Subscriber did not find an option for an OV only certificate, so he chose a Sponsor-validated (IV+OV) and entered the organization information in the Given name and Surname fields of the tool.
This caused an issuance that constitutes a violation of the following CP/CPS clauses:
§7.1.4.2.2 c. “Certificate Field: subject:givenName (2.5.4.42) and subject:surname (2.5.4.4) – Contents: If present, the subject:givenName field and subject:surname field MUST contain a natural person Subject’s name as verified under Section 3.2.3.”
Impact
One (1) Sponsor-validated S/MIME certificate, issued on 2023-12-14, was affected. The issue related to misuse of the bulk order tool by a single subscriber, hence it did not result to ceasing issuance.
Actual results:
Timeline
All times are UTC.
2023-12-14:
- 20:29 - An Enterprise Customer placed an order request for an Sponsor-validated S/MIME certificate via the bulk order tool. Certificate was automatically issued based on the Enterprise RA Agreement that is in place with the customer.
2023-12-18:
-
10:32 During a random check, a member of the Validation team spots the issuance of an S/MIME certificate with givenName and surName that look like a company name rather than a name of an individual. The Validation Manager is notified.
-
20:29 The Validation Manager examines the case and registers a Security Event ticket in accordance with our Incident Management Policy.
-
20:49 Customer is notified via email.
-
20:58 Customer replied saying that they their intention was to issue an Organization-validated certificate, but they did not find this option in the bulk ordering tool. They reverted to the Sponsor-validated option and used organization information as givenName and surName.
2023-12-19:
-
16:00 Initial analysis of the Security Event by the Validation and Security Auditing teams.
-
17:28 Certificate is revoked by the Validation team.
-
20:50 Analysis of the Security Event by the Validation and Security Auditing teams. Escalation to an Incident. Compilation of this Incident Report.
2023-12-20
- Finalization and submission of this Incident Report to Bugzilla.
Root Cause Analysis
Lessons Learned
What went well
Detective controls and incident reporting processes: The prompt detection of the issue by the Validation team during a random check shows that the team is actively monitoring certificate orders to detect, investigate and report any irregularities that may consist a violation.
Immediate response: The prompt notification of the customer and revocation of the affected certificate.
What didn't go well
The bulk order tool did not provide sufficient guidance for the end user to order the desired type of S/MIME certificates.
Where we got lucky
The fact that, in this case, the bulk order tool was used to order a single certificate, limited the impact of this incident.
Action Items
Expected results:
| Action Item | Kind | Due Date |
|---|---|---|
| Update the bulk order tool to guide the user through the process | Prevent | 2024-02-28 |
| Update the public documentation (https://www.ssl.com/how-to/bulk-enrollment-of-personal-idorganization-s-mime-certificates/) to include guidance for Organization-validated S/MIME certificates | Prevent | 2024-01-31 |
|
||
Updated•2 years ago
|
This is an update to post the missing root cause analysis section.
The certificate in question was issued by an Enterprise RA who is authorized to use our bulk order tool for Organization-validated and Sponsor-validated S/MIME certificates. The customer succesfully used the same tool to request Sponsor-validated certificates in several other occassions. When attempting to request an Organization-validated certificate, the customer erroneously used the Sponsor-validated option and provided organization information in the givenName and surName fields.
This was a mistake by the applicant. However, we believe there is value in improving the UI and supporting the user with guidance material, in order to minimize the risk of such mistakes in the future.
So a subscriber can just pick these values and the CA issues them? How does this bulk order flow prevent malicious issuances?
Our bulk order tool only facilitates the request process for the applicant. Orders received through the tool are subject to the same checks that a request placed through the user portal would experience. The situation at hand involves an organization which had established an Enterprise RA relationship with SSL.com by signing an agreement to adhere to the S/MIME BRs and the SSL.com CP/CPS with regards to the collection and investigation of evidence that establishes the identity of natural human subjects with relation to their organization. The model is based on the defined process for Sponsor-validated S/MIME certificates taken from the S/MIME BRs and which is used by many Certificate Authorities.
I'd argue that because it's done by other CA's that doesn't make it okay.
What I'm reading is that "they promised they won't lie about whats in the certificate." Clearly this model is leading to a mis-issuance, and I believe the root cause of this incident is the fact that there are these special subscribers (Enterprise RAs), that are able to effectively bypass the various checks that should be in place by you the CA.
Please correct me if I'm wrong here but it seems like all this is depending on is non-technical controls of contracts and hoping the subscriber doesn't do the wrong thing?
And, it seems like this is a failure of following #2 in: https://github.com/cabforum/smime/blob/main/SBR.md#1321-enterprise-registration-authorities
What action items will you take to put technical limitations on preventing these mis-issuances? While I think the UI work is worthwhile, it doesn't prevent an applicant mistakenly, or maliciously, causing an improper certificate to be issued.
Thank you for your comments and questions; they give the opportunity to discuss further the Sponsor-validated model and the expectations of the industry. For this reason, our response is somewhat lengthy.
With regards to our previous post: the fact that it is being used by other CAs is not a compliance argument. It simply conveys the information that it’s a well-known and commonly used model in the industry. This model has been adopted in the S/MIME BRs as ‘Sponsor-validated’ and is described in Section 1.2.3.1 that you referenced.
SSL.com applies exactly the model described therein. In particular, mapping the language of that Section to this case, SSL.com applies the following:
SSL.com has delegated to this Enterprise RA to verify Certificate Requests only for Subjects within the Enterprise RA's own organization. SSL.com accepts Sponsor-validated Certificate Requests authorized by this Enterprise RA only if the following requirements are satisfied:
-
SSL.com has confirmed that the Enterprise RA has authorization or control of the requested email domain(s) in accordance with Section 3.2.2.1 or Section 3.2.2.3.
-
SSL.com has confirmed that the subject:organizationName name is that of the delegated Enterprise RA, by validating and technically enforcing it.
Further, SSL.com has imposed these limitations, including the Enterprise RA’s obligations, as a contractual requirement. SSL.com also monitors compliance by the Enterprise RA to ensure their practices and procedures are in compliance with the S/MIME BRs and the SSL.com CP/CPS, via sample-based internal audits that take place on a quarterly basis (Quarterly Certificate Reviews).
The above are evaluated by our internal Compliance function and independently, by Webtrust auditors as part of SSL.com’s external audits.
With regards to the technical limitations, please note that several sessions took place internally to discuss possible options, especially regarding prevention. Facts show that this was not a case of a malicious subscriber; it was a mistake that was assisted by the complexity of the user interface and the lack of in-situ guidance. Our mitigation actions focus on addressing exactly these issues to minimize the risk of such mistakes.
More generally, the Sponsor-validated model is not a “blind-trust” model; several controls are applicable: preventive ones like pre-issuance linting, robust user guidance, contractual provisions (also mitigative), and detective ones like internal and external audits or random checks. However, it is quite clear that the Sponsor-validated model, as described in the S/MIME BRs, accepts some dependency on third parties to perform validation and pass the correct content to the CA. Suggesting that the CA should remove this dependency, e.g. by enforcing review and approval by the CA (or the central RA) before issuance, would, in our opinion, defeat the purpose of the Sponsor-validated model.
We would like to inform the community that we are preparing an update to the public documentation to include guidance for bulk-ordering procedures when requesting Organization-Validated S/MIME certificates. The update is expected to go live next week. We will make another update to this bug when the documentation is published.
This is an update to report current progress on this issue.
Guidance for bulk-ordering Organization-Validated S/MIME certificates has been published at https://www.ssl.com/how-to/bulk-enrollment-of-organization-validation-ov-s-mime-certificates/. This completed action no.2.
Action no.1 is progressing according to our plan. We have completed requirements analysis and set acceptance criteria.
We will provide a progress update next week.
We would like to report that implementation of action item #1 has been completed and is currently undergoing internal testing. We will provide another update next week.
|
Assignee | |
Comment 10•2 years ago
|
||
Action #1 has been completed. A wizard has been deployed to guide the user through the process, thus reducing the risk of mistakes.
This completes all pending actions for this bug.
|
||
Comment 11•2 years ago
|
||
Did SSL.com do a scan and analysis of all their certificates to see if any others were affected with similar issues? I didn't see that mentioned in the report.
(In reply to Thomas Zermeno from comment #0)
Where we got lucky
The fact that, in this case, the bulk order tool was used to order a single certificate, limited the impact of this incident.
I think another place where you got lucky that wasn't addressed is that this was detected because the certificate was in the random sample used for checking. Presumably if it hadn't been in that sample, it wouldn't have been detected.
|
|
Assignee | |
Comment 12•2 years ago
|
||
RE: Scan for other affected certificates
Yes, without revealing any other affected certificates. The scan involved cross-checking the contents of givenName and surName of the subjectDN for SV and IV certificates, against a list of common corporate keywords and abbreviations (e.g. Corporation, SA, Ltd, GmbH) and their variations (e.g., Corp., S.A.). Matching certificates were reviewed by our Validation team and were all found to be false positives.
RE: Where we got lucky
Correct. On the other hand, we consider the alertness of our Validation team through time to be one of the strong points.
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 13•2 years ago
|
||
We would like to remind the community that all action items for this report have been completed. At this time we would respectfully ask that the report be closed. We will continue to monitor the topic.
|
|
||
Comment 14•2 years ago
|
||
Are there any other questions or concerns? If not, I will close this on 15-May-2024.
|
|
||
Updated•2 years ago
|
Description
•