1390994 - DocuSign/Keynectis: 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:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

Comment 1

[Erwann Abalea]

(In reply to Kathleen Wilson from comment #0)
> 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.

Via a problem report on August 8 2017 (email).

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

It should have been stopped since May 2016, but this problem report showed that some control measures have been incorrect, incomplete, or disabled.

> 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.

A complete analysis is in progress.

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

The mistakes were caught earlier, we added controls on the existing issuance system to only allow properly formatted LDH-domains. This was done on May 2016.
The self-audit tool wrongfully strips space characters, so such invalid names didn't show up in the reports.

> 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.

1. Retrieve the configuration settings of the RA spaces (each customer has its own space).
2. Verify the controls on each of these RA spaces configuration settings, and correct them.
3. Reload the configuration settings if necessary.

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

All listed certificates issued under CLASS 2 KEYNECTIS CA have been revoked today.
The 2 remaining certificates issued under KEYNECTIS SSL RGS will be revoked tomorrow (they were missing from my request to the RA team).
The self-audit tool we use has been corrected and is now running for the analysis.

Comment 2

[Erwann Abalea]

An update:
 - 14 non-compliant certificates were notified issued by 2 CAs, all of them have been revoked on 17 August and 22 August
 - additional non-compliant certificates were later detected issued by the same 2 CAs, all but one have been revoked between 17 August and 30 August
 - it was decided to revoke all "non-LDH" compliant certificates, including certificates with domain names containing an underscore


The people involved in analyzing and solving these issues cannot work full-time on this, as they're currently working on highly time-consuming tasks, in addition to the day-to-day business. The progress is slow, and I apologize for that.

Comment 3

[Ryan Sleevi]

Hi Erwann,

It is now a month since Comment #2, and no update has been provided for questions #3 and #4 from Comment #1. The answer provided in Comment #2 is not sufficient to meet the stated requirements. Similarly, the answer for question #6 does not provide a timeline with respect to these.

As such, this answer is very incomplete. Further, while the apologies are appreciated from Comment #2, it is very concerning that adequate staffing for incident response and remediation has not been made.

Can you please ensure all the information requested is provided? As it is a month later, I believe it's reasonable to expect full and complete answers at this point, including full certificate details.

Comment 4

[Erwann Abalea]

Bonsoir Ryan,

> It is now a month since Comment #2, and no update has been provided for
> questions #3 and #4 from Comment #1. The answer provided in Comment #2 is
> not sufficient to meet the stated requirements. Similarly, the answer for
> question #6 does not provide a timeline with respect to these.


Question #3
47 certificates have been found, 30 new have just been logged to CT. I'm preparing the CSVs to be attached.


Question #4
The problems identified are:
 - invalid LDH (space character, underscore, accented character, IP address in a dNSName, "DNS:" prefix, comma character): 43 certificates issued between 28 October 2014 and 6 June 2017
 - inexistent TLD: 2 certificates issued on 24 November 2015 and 25 May 2016 for the ".corp" TLD; their revocation was internally asked in October 2016
 - internal name: 3 certificates issued on 17 and 20 July 2015, and on 29 September 2016; the revocation of 2 of them was internally asked in October 2016

1 certificate falls in the last 2 categories.


Question #5
The controls put in place to avoid invalid characters in DNS Names (regular expressions added to limit the CN/dNSName content) in May 2016 had been erroneously disabled on one enterprise RA account, and forgotten on another.
The account where this control was disabled has seen it reinstated, the behaviour difference has been explained to the customer, and the modification rules have been recalled to the customer support team.
The account that was forgotten has been disabled and taken back by DocuSign France internal teams to handle revocation requests only. No new certificate is to be issued on this account.


Question #6
The old RA software was aging and is not SSL certs oriented, a new RA system dedicated to SSL certificates issuance was in development since several months, and was installed during August. All but 2 customers have been migrated between mid August and early September, the last 2 will be done in the next weeks (I hope). The new RA system can't have its LDH-form-check disabled, and provides other enhancements.


> As such, this answer is very incomplete. Further, while the apologies are
> appreciated from Comment #2, it is very concerning that adequate staffing
> for incident response and remediation has not been made.

During the last 2 years, DocuSign France:
 - separated from our historic partner OpenTrust/IDnomic (and was bought by DocuSign)
 - installed 2 new datacenters to replace the old ones
 - made them audited for eIDAS compliance
 - maintained the compliance effort with IDnomic (who still hosts some of our CAs and services)
 - created new CAs and new services for eIDAS and have them audited (not the easy transition phase, the full one)
 - developed missing software (for example the new RA)
 - moved our office (that was this month)
(I'm leaving lots of things out)

We're now migrating our existing customers to our new datacenters while ending the transition with IDnomic, and have other tasks running and coming.
That's the reasons why we're mainly silent on CABF, and why I'm no more participating on m.d.s.p. for the moment with my personal hat on (and on other PKI-related groups).

Comment 5

[Erwann Abalea]

Attachment: InvalidLDH.csv

Comment 6

[Erwann Abalea]

Attachment: InternalName.csv

Comment 7

[Erwann Abalea]

Attachment: InexistentTLD.csv

Comment 8

[Erwann Abalea]

Attachment: InvalidLDH2.csv

Corrected into ISO8859-1 instead of the obsolete MacRoman exported by Excel.

Comment 9

[Gervase Markham [:gerv]]

Erwann: just to confirm, are all these certificates revoked?

Gerv

Comment 10

[Erwann Abalea]

Yes, all these certificates are revoked, the revocation date is one of the columns of the CSV files.