1398247 - DocuSign/Keynectis: Non-BR-Compliant OCSP Responders

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

Problems have been found with OCSP responders for this CA, and reported in the mozilla.dev.security.policy forum here:

https://groups.google.com/d/msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ

As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a “good” status for unissued certificates. The effective date for this requirement was 2013-08-01.

Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Kathleen Wilson]

It was also noted that the 'Problem Reporting Mechanism' field for this CA Owner in the CCADB is empty, so the CA needs to send Kathleen the exact URL and/or email address to put into this field in the CCADB.

Comment 2

[Erwann Abalea]

This intermediate CA is offline and used for the Adobe AATL program (as its name implies), delivering certificates used for seal, signature, and timestamping purposes only. This CA and subordinate CAs are audited following ETSI EN 319411-1/2.

SSL server certificates are issued under a different hierarchy.

Having read the m.d.s.p. thread, and considered that next versions of ETSI EN 319411-1 will have the same requirements regarding nonexistent serial numbers and OCSP responders as what is required in BR, we will change the configuration of this responder and populate its database (the CA being offline, the process is more complicated than from an online CA).

Comment 3

[Gervase Markham [:gerv]]

Erwann: can you provide a timeline for fixing this issue?

Gerv

Comment 4

[Ryan Sleevi]

Erwann: It's now three weeks later. Do you have an update?

Comment 5

[Erwann Abalea]

(In reply to Ryan Sleevi from comment #4)
> Erwann: It's now three weeks later. Do you have an update?

The database has been populated by our sub-contractor. We now have to plan a key ceremony to generate a new OCSP responder certificate.

Comment 6

[Wayne Thayer]

The following report lists an additional non-compliant Docusign/Keynectis CA:

https://crt.sh/ocsp-responders?randomserial=Good&trustedBy=Mozilla&trustedFor=Server%20Authentication&trustedExclude=constrained,expired,onecrl&randomserial=Good&sort=2&dir=v

Erwann: what is the timeline for conducting the ceremony and getting this fixed?

Comment 7

[Erwann Abalea]

Bonjour,

(In reply to Wayne Thayer [:wayne] from comment #6)
> The following report lists an additional non-compliant Docusign/Keynectis CA:
> 
> https://crt.sh/ocsp-
> responders?randomserial=Good&trustedBy=Mozilla&trustedFor=Server%20Authentica
> tion&trustedExclude=constrained,expired,onecrl&randomserial=Good&sort=2&dir=v

This CA does not issue serverAuth certificates, and was audited against ETSI EN 319411-1 v1.1.1.
Certificates issued by this CA include Signature, Seal, and Authentication (client).

> Erwann: what is the timeline for conducting the ceremony and getting this
> fixed?

The key ceremony has been conducted and the OCSP is now active.

Comment 8

[Wayne Thayer]

(In reply to Erwann Abalea from comment #7)
 
Hello,

> This CA does not issue serverAuth certificates, and was audited against ETSI
> EN 319411-1 v1.1.1.
> Certificates issued by this CA include Signature, Seal, and Authentication
> (client).
> 
Neither the "KEYNECTIS ICS ADVANCED Class 3 CA" subordinate or its parent appear to be technically constrained, and the root is enabled for websites in the Mozilla root store, so this subordinate must comply with the BRs even if it does not issue serverAuth certificates. If compliance is not possible, we will add it to OneCRL. Please reply with a date by which this subordinate will comply, or with a confirmation that it should be added to OneCRL.

Comment 9

[Firefox Bug Husbandry Bot]

Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254

Comment 10

[Wayne Thayer]

Still awaiting a response the comment #8...

Comment 11

[Erwann Abalea]

The OCSP responder has been updated to be BR-compliant.

Comment 12

[Wayne Thayer]

(In reply to Erwann Abalea from comment #11)
> The OCSP responder has been updated to be BR-compliant.

I have confirmed that this is fixed.

This bug is still awaiting the incident report as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 13

[Erwann Abalea]

Here's the incident report.


Date we were being aware of the problem: 2018-01-16, by a Bugzilla bug.

Timeline:
 - 2009-06-09: CA issued under the KEYNECTIS ROOT CA hierarchy (not included in Mozilla)
 - 2010-09-03: CA recertified under the Certplus Class 2 Primary CA
 - 2013-08-01: CABForum requirement that OCSP responders MUST NOT respond with a Good status for a non-issued certificate
 - 2014-05-27: CA recertified under the OpenTrust Root CA G1 hierarchy
 - 2018-01-16: Bugzilla bug created
 - 2018-03-20: asked our sub-contractor to activate data replication for the OCSP responder for this CA
 - 2018-03-27: configuration change to be compliant (change from CRL-based to database-based)
 - 2018-03-28: notification of this change in the Bugzilla bug

This CA is not used for serverAuth certificate issuance, only for signature and seal purpose, in the eIDAS context (and previously in the 1999/93/CE European Directive context). It is audited as such since its creation, latest audit was done against ETSI EN 319411-1. We erroneously thought the BR clause 4.9.10 requirement for non-issued certificates didn't apply to such a CA.

Only one TLS serverAuth certificate has been issued under this CA, for testing purposes:
 SHA1 fingerprint: DC74A0AC6E4B54EB894712ED7DFB4563E394AB97
 notBefore:        2010-01-26 10:43:34 UTC
 notAfter:         2011-01-26 10:43:34 UTC
 serialNumber:     2121D54DD4459C62E9E5C18DE37F3BE6305B
 crt.sh link:      <TODO>

Steps to mitigate future problems:
 - next audits will be done under the new ETSI EN 319411-1 standard, which has the same requirements against OCSP responders as what is described in BR clause 4.9.10; the 1.2.1 version is in Final draft status and is publicly available, but we can't be audited against a draft version
 - our new Root CAs (OpenTrust Root CA Gx and Certplus Root CA Gx) will soon be asked to have their serverAuth flag disabled, while the current Certplus Class 2 Primary CA will be maintained up to its expiration date (July 2019)

Comment 14

[Ryan Sleevi]

Erwann: Do you have an update on disclosing that certificate?

https://crt.sh/?serial=2121D54DD4459C62E9E5C18DE37F3BE6305B
https://crt.sh/?sha1=DC74A0AC6E4B54EB894712ED7DFB4563E394AB97

Return nothing.

Can you further provide a concrete timeline for your remediation steps?

Comment 15

[Erwann Abalea]

Was on PTO last week.

(In reply to Ryan Sleevi from comment #14)
> Erwann: Do you have an update on disclosing that certificate?
> 
> https://crt.sh/?serial=2121D54DD4459C62E9E5C18DE37F3BE6305B
> https://crt.sh/?sha1=DC74A0AC6E4B54EB894712ED7DFB4563E394AB97
> 
> Return nothing.
> 
> Can you further provide a concrete timeline for your remediation steps?

The certificate was pushed to Pilot at 11:34 UTC today, I'm waiting for crt.sh to catch it.

Returned SCT was:
{"sct_version":0,"id":"pLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN3BA=","timestamp":1523964889464,"extensions":"","signature":"BAMASDBGAiEAnJbzEhe+zQ9XNvnCLb2vPUklnUCAYFNy+QSvRZK8/E4CIQCMMkf/fpfFf9Zx++SULwDdqokn7B5QDM7c1gjC2rIVjg=="}

Comment 16

[Erwann Abalea]

(In reply to Erwann Abalea from comment #15)
> Was on PTO last week.
> 
> (In reply to Ryan Sleevi from comment #14)
> > Erwann: Do you have an update on disclosing that certificate?
> > 
> > https://crt.sh/?serial=2121D54DD4459C62E9E5C18DE37F3BE6305B
> > https://crt.sh/?sha1=DC74A0AC6E4B54EB894712ED7DFB4563E394AB97
> > 
> > Return nothing.
> > 
> > Can you further provide a concrete timeline for your remediation steps?
> 
> The certificate was pushed to Pilot at 11:34 UTC today, I'm waiting for
> crt.sh to catch it.
> 
> Returned SCT was:
> {"sct_version":0,"id":"pLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN3BA=",
> "timestamp":1523964889464,"extensions":"","signature":
> "BAMASDBGAiEAnJbzEhe+zQ9XNvnCLb2vPUklnUCAYFNy+QSvRZK8/E4CIQCMMkf/
> fpfFf9Zx++SULwDdqokn7B5QDM7c1gjC2rIVjg=="}

https://crt.sh/?id=400890826

Comment 17

[Wayne Thayer]

Erwann: when will these remediation steps be completed?

 - next audits will be done under the new ETSI EN 319411-1 standard, which has the same requirements against OCSP responders as what is described in BR clause 4.9.10; the 1.2.1 version is in Final draft status and is publicly available, but we can't be audited against a draft version
 - our new Root CAs (OpenTrust Root CA Gx and Certplus Root CA Gx) will soon be asked to have their serverAuth flag disabled, while the current Certplus Class 2 Primary CA will be maintained up to its expiration date (July 2019)

Comment 18

[Erwann Abalea]

Bonjour,

(In reply to Wayne Thayer [:wayne] from comment #17)
> Erwann: when will these remediation steps be completed?
> 
>  - next audits will be done under the new ETSI EN 319411-1 standard, which
> has the same requirements against OCSP responders as what is described in BR
> clause 4.9.10; the 1.2.1 version is in Final draft status and is publicly
> available, but we can't be audited against a draft version

The Final version has been published in April 2018.

>  - our new Root CAs (OpenTrust Root CA Gx and Certplus Root CA Gx) will soon
> be asked to have their serverAuth flag disabled, while the current Certplus
> Class 2 Primary CA will be maintained up to its expiration date (July 2019)

This one is done.

Comment 19

[Wayne Thayer]

(In reply to Erwann Abalea from comment #18)
> Bonjour,
> 
> (In reply to Wayne Thayer [:wayne] from comment #17)
> > Erwann: when will these remediation steps be completed?
> > 
> >  - next audits will be done under the new ETSI EN 319411-1 standard, which
> > has the same requirements against OCSP responders as what is described in BR
> > clause 4.9.10; the 1.2.1 version is in Final draft status and is publicly
> > available, but we can't be audited against a draft version
> 
> The Final version has been published in April 2018.
> 
Mozilla hasn't yet received the new audit statements for the Certplus class 2 primary CA.

> >  - our new Root CAs (OpenTrust Root CA Gx and Certplus Root CA Gx) will soon
> > be asked to have their serverAuth flag disabled, while the current Certplus
> > Class 2 Primary CA will be maintained up to its expiration date (July 2019)
> 
> This one is done.

This request is being tracked in bug 1465625.

Comment 20

[Wayne Thayer]

The audits for the Certplus class 2 primary CA are being tracked in bug 1465629.

Comment 21

[Wayne Thayer]

A new audit for the Certplus Class 2 Primary CA has been received and processed. There is a gap in the audit period from 4/8/2017 to 9/16/2017. This root will be removed in July-2019 via bug 1465629, so I am resolving this incident despite the audit violation.