1390996 - Entrust: Non-BR-Compliant Certificate Issuance

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. 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; 
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Certificates with metadata-only subject fields (at least one subject field that only contains ASCII punctuation characters)
https://groups.google.com/d/msg/mozilla.dev.security.policy/Sae5lpT02Ng/-lsC11JnBwAJ
Prevent further issuance of certs with N/A and other metadata but revocation not necessary in this case.

Comment 1

[Kirk Hall]

1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.

We first became aware by means of the posting “Certificates with metadata-only subject fields” by Jonathan Rudenberg on August 9, 2017 which listed one certificate issued by Entrust with a hyphen in the OU field.  https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Sae5lpT02Ng

2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.

Confirmed, although as indicated below it’s not clear that including a hyphen in the OU field at the customer’s request (as opposed to at the decision of the CA) is a violation of the BRs.

3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.

After an investigation of our records, five certificates were found to have been issued since BR Sec. 9.2.7 was first included in the BRs - Version 1.1, dated July 1, 2012.  All five certificates contained a ‘-‘ (hyphen) in the OU field.  No occurrences of ‘.’ or ‘ ‘ (period or space) were found.  Of those certificates, two have already expired.  Of the remaining three, two will expire before the end of September 2017 while the final one will expire in October 2019.  Since the inclusion of this value (a hyphen) is not viewed as a security risk the unexpired certificates will not be revoked.  We have attached copies of the five certificates in question.

All of the certificates were issued from our Retail certificate services which require manual review by two data verification people.  The hyphen in the OU field was requested by the customer in its CSR for each certificate.  No indication was found in the vetting file as to why the hyphen was allowed by the verification people, but our best guess is that they were approved due to an interpretation of the BRs concerning allowable values for the OU field (i.e., that a hyphen requested by the customer in the OU was permissible under subjection (i), and is not prohibited in that circumstance by subsection (j)).

To prevent future occurrences (whether or not a hyphen in the OU requested by the customer is a violation of BR 7.1.4.2.2(j)), the following actions have been taken:
•	Enhanced education around allowable values for the OU and other subject name fields has been created and pushed out to the verification team.
•	A change will be made to the product to prevent issuance of certificates with OU values of ‘-‘ or ‘.’ (hyphen or period). OU values are already prevented from containing ‘ ‘ (only a space).

ADDITIONAL INFORMATION

The BR language in question (now BR 7.1.4.2.2(j)) was initially added to the EV Guidelines in October 2009 by Ballot 33.  Later, it was added to the BRs v. 1.1 in July 2012.  Checking with other Forum members, it appears this language was added in 2009 because some CAs were adding these characters to the O, L, S, and/or C fields of DV certificatess to indicate there was “no data”, but this action made it impossible for some automated applications to tell the difference between OV and DV certs at that time.  The language was added as a restriction to avoid this problem so researchers and other interested parties could readily figure out the type of certificate on an automated basis without having to review and evaluate the data fields themselves.

In the case of the five certificates in question, as noted the hyphen in the OU field was requested by the customers in their CSRs.  We don’t know why the customers made this request, but it could have been that the use of a hyphen in the OU field was meaningful to the customer and its systems (e.g., like inserting “x” to the OU field because the cert would be used on system “x” – and not inserted to indicate “no data” in the field).  Normally, CAs try to accommodate this type of request from a customer, especially if the data entered is not misleading.

BR 7.1.4.2.2(i) would seem to authorize this practice by a customer concerning data in OU fields, and allow a CA to approve it:

i. Certificate Field: subject:organizationalUnitName

Optional.

The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 3.2 and the Certificate also contains subject:organizationName, subject:givenName, subject:surname, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 3.2.2.1.

The language of this subsection allows any characters in an OU field that a customer may request, but requires the CA to verify any information in the OU field that includes a “name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity”.  This verification requirement would clearly not apply to a character such as a hyphen requested by a customer in the OU field, so it appears a hyphen in the OU field would be allowed by the BRs if requested by a customer (but not allowed if added by a CA on its own for some purpose).  In addition, including a hyphen in the OU field will not interfere with an application’s ability to determine whether the cert is a DV or OV cert.  Also, that problem (how to tell if a cert is DV, OV, or EV) has been solved by the Microsoft root program, which requires CAs to include the official certificate-type OID in all certificates to indicate what kind of cert it is.  See Sec. 4.A.15 at https://social.technet.microsoft.com/wiki/contents/articles/31633.microsoft-trusted-root-program-requirements.aspx  

4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.

This information is provided in section 3.

5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.

First, it’s not clear that this action was a “mistake.”  We have no specific record of why the verification staff permitted a hyphen in the OU field for these five certificates after it was requested (via the submitted CSR) by the customer.  It is possible they were approved due to an interpretation of the BRs around that allows values like a hyphen in the OU field – believing that such characters are permitted when requested by the customer and not misleading – see discussion above.  However, to be conservative we have decided to block such characters in the future, even if requested by and meaningful to the customer.

6) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

See discussion above.  Some steps have already been implemented, and the remaining steps will occur during the next development cycle.

7) Regular updates to confirm when those steps have been completed.

•	Enhanced education around allowable values for the OU and other subject name fields has already been created and pushed out to the verification team.
•	We will notify you when our systems have been modified to block such characters in the OU field even when requested by the customer.

Comment 2

[Kirk Hall]

Attachment: Entrust certificates mentioned on the Bug

Here are copies of the five Entrust certificates discussed in this Bug.

Comment 3

[Kirk Hall]

Typo correction - the word "subjection" in the text above should be changed to "subsection", as shown below.

All of the certificates were issued from our Retail certificate services which require manual review by two data verification people.  The hyphen in the OU field was requested by the customer in its CSR for each certificate.  No indication was found in the vetting file as to why the hyphen was allowed by the verification people, but our best guess is that they were approved due to an interpretation of the BRs concerning allowable values for the OU field (i.e., that a hyphen requested by the customer in the OU was permissible under subsection (i), and is not prohibited in that circumstance by subsection (j)).

Comment 4

[Jonathan Rudenberg]

(In reply to Kirk Hall from comment #2)
> Created attachment 8899022 [details]
> Entrust certificates mentioned on the Bug
> 
> Here are copies of the five Entrust certificates discussed in this Bug.

These certificates are now in CT and are listed at https://misissued.com/batch/19/

Comment 5

[Jonathan Rudenberg]

While looking at these certificates, I noticed that one is not BR-compliant in another way.

https://crt.sh/?id=193603787&opt=cablint contains an IP address in a dnsName SAN, which is not allowed by RFC 5280.

For context, this specific error was discussed at length on the CAB Forum public mailing list in April 2016, where Richard Barnes[0] (representing Mozilla) and Ryan Sleevi[1] (representing Google) were extremely clear that it is a violation of the Baseline Requirements.

There are 29 additional certificates with invalid dnsNames containing IPs issued by Entrust that are unexpired and known to CT, they can be found in this list: https://misissued.com/batch/9/

[0] https://cabforum.org/pipermail/public/2016-April/007288.html
[1] https://cabforum.org/pipermail/public/2016-April/007289.html

Comment 6

[Jonathan Rudenberg]

(In reply to Jonathan Rudenberg from comment #5)
> For context, this specific error was discussed at length on the CAB Forum
> public mailing list in April 2016, where Richard Barnes[0] (representing
> Mozilla) and Ryan Sleevi[1] (representing Google) were extremely clear that
> it is a violation of the Baseline Requirements.

Looking back further, this was also indicated by Gerv and Ryan in August 2015 as well:

https://cabforum.org/pipermail/public/2015-August/005851.html
https://cabforum.org/pipermail/public/2015-August/005852.html

Comment 7

[Stephen Hillier]

In response to the CA/Browser Forum discussion of this issue in 2016, Entrust stopped issuing these certificates in August 2016.  Because no security issues have been found from these certificates, we decided it was not necessary to revoke the certificates previously issued but rather allow them to expire.

Comment 8

[Ryan Sleevi]

(In reply to Kirk Hall from comment #1)
> 6) List of steps your CA is taking to resolve the situation and ensure such
> issuance will not be repeated in the future, accompanied with a timeline of
> when your CA expects to accomplish these things.
> 
> See discussion above.  Some steps have already been implemented, and the
> remaining steps will occur during the next development cycle.

This is a very imprecise "timeline", as it does not provide a schedule for these changes to be implemented.

Can you provide a more concrete statement about your intended deployment timelines?

Comment 9

[Stephen Hillier]

The implementation timeline is as follows:

  1.  Education and process changes were completed as of 18 Aug 2017. Since all OU values require manual verification, issuance of certificates containing the indicated values is now prevented.

  2. Additional software fail-safe checks preventing the issuance of certificates containing these OU values will be deployed as part of the next product release in November 2017.

Comment 10

[Ryan Sleevi]

Thank you for your complete and detailed response to this, and I do not believe there are any further questions.

I am now marking this issue as Remediation Accepted, with an update to be provided in November 2017 regarding the status of this deployment. Should there be any anticipated delays, please update this bug before then. Upon completion of the system deployment, we will mark this as Resolved/Fixed.

Comment 11

[Stephen Hillier]

Quick update since it is now mid-November. We are currently on track to complete installation of the software fail-safe checks on all production systems by end of month. I will provide another update when completed.

Comment 12

[Stephen Hillier]

Just to close this off. Deployment of the software fail-safe check for OU values was completed for all production Entrust CA systems on November 27th.