1313873 - SHA-1 issuance by DocuSign root

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Gervase Markham [:gerv]]

In mozilla.dev.security.policy, Patrick Figel writes:

<blockquote>
I found a number of SHA-1 certificates chaining up to CAs trusted by
Mozilla that have not been brought up on this list or on Bugzilla yet.
Apologies in case I missed prior discussion for any of these, and kudos
to censys for making this search incredibly easy.

...

#4
https://crt.sh/?id=20279777&opt=cablint
  Common Name: styles.ag2rlamondiale.fr
  Serial: 11:21:79:9c:b3:3b:51:dd:43:a5:40:b5:a2:4b:81:38:b8:4a
  Not Before: May 23 12:02:20 2016 GMT
  Chains to: "Class 2 Primary CA" (DocuSign (OpenTrust/Keynectis)) via:
   - CLASS 2 KEYNECTIS CA
</blockquote>

These issuances are in violation of the Baseline Requirements, which Mozilla policies require adherence to. Please can you explain what has happened, with particular reference to the following questions:

A) Does the CP/CPS of the relevant issuing CA forbid the use of SHA-1? If not, why not?

B) What is the audit status of the relevant issuing CAs?

C) What technical controls are in place within DocuSign to prevent SHA-1 issuance and how were they bypassed?

Gerv

Comment 1

[Kathleen Wilson]

Erwann, Please look into this and update this bug with the information listed above as soon as possible.

Comment 2

[Gervase Markham [:gerv]]

Also: https://crt.sh/?id=16157906&opt=cablint .

Gerv

Comment 3

[Erwann Abalea]

In addition to these 2 certificates, 2 more have been erroneously issued:
* one with serial number 1121741263ED77D31273BB5048A39EBCCB02
* one with seri112164145DE3211F0B8D3EC2F5ABD01B62FB

Two of these certificates have been revoked on 11 February 2016, the other two have been revoked on 26 May 2016.

A) The CP/CPS of this CA forbids the use of SHA1, and mandates the use of SHA256 (see https://www.docusign.fr/sites/default/files/DBD_PC-Certificats-SSL-RGS-et-ETSI-V1-7s_0.pdf, section 7.1.2).


B) The CA has a current ETSI TS 102 042 audit, last audit was done on 13-14 october 2016. It was mentioned to the auditor that these 4 certificates have been erroneously issued, and what corrective actions have been made.


C) Technical controls are currently in place at RA level. There are distinct RA workspaces for SHA1/SHA256 certificates, and distinct workspaces for enterprise RA and internal RA.

Technical controls were in place for enterprise RA workspaces. Organizational controls were in place for our internal RA workspaces. Technical controls are set up by a dedicated DocuSign France admin team over the RA teams, and each of the RA teams verifies and issues certificates on workspaces it has access to.
Technical controls are done by access rights associated to a client certificate (such as right to issue, revoke, audit, etc).

The February certificates have been issued by our internal RA workspace, by our internal RA team, for our own web servers. Organizational controls were not followed for these 2 certificates, the RA team detected that situation on 11 February and revoked the certificates. This fault was detected by the compliance team during a self-audit in May, and the rights of the actors have been reduced on our internal SHA1 workspaces (to be "audit+revoke").

The May certificates have been issued by an enterprise RA workspace, after the renewal of a client certificate; human error led to bad access rights associated to the SHA1 workspace (should have been "audit+revoke", was granted "issue" also). This was detected and the certificates have been revoked on 26 May. This misissuance was detected by the compliance team during a self-audit in July, access rights were corrected, and procedures were reminded to the DocuSign France admin team.


For information, we cannot disable the SHA1 workspaces for now, because it means that an RA actor wouldn't be able to revoke the certificates associated to these workspaces.
We plan to set up technical means for SHA1 issuance to always fail, by modifying certificate templates at CA level and introduce a constraint that can't pass whatever access rights are setup at RA level.

Comment 4

[Erwann Abalea]

(In reply to Erwann Abalea from comment #3)
> In addition to these 2 certificates, 2 more have been erroneously issued:
> * one with serial number 1121741263ED77D31273BB5048A39EBCCB02
> * one with seri112164145DE3211F0B8D3EC2F5ABD01B62FB

(The Tab key is too close to the A key)

The second certificate has serial number 112164145DE3211F0B8D3EC2F5ABD01B62FB.
Both certificates have been pushed to Google CTlogs (aviator, pilot, rocketeer), I'm waiting for their retrieval by crt.sh to provide a direct link to them.

Comment 5

[Erwann Abalea]

(In reply to Erwann Abalea from comment #4)
> (In reply to Erwann Abalea from comment #3)
> > In addition to these 2 certificates, 2 more have been erroneously issued:
> > * one with serial number 1121741263ED77D31273BB5048A39EBCCB02
> > * one with seri112164145DE3211F0B8D3EC2F5ABD01B62FB
> 
> (The Tab key is too close to the A key)
> 
> The second certificate has serial number
> 112164145DE3211F0B8D3EC2F5ABD01B62FB.
> Both certificates have been pushed to Google CTlogs (aviator, pilot,
> rocketeer), I'm waiting for their retrieval by crt.sh to provide a direct
> link to them.

And the links:
https://crt.sh/?id=50704808
https://crt.sh/?id=50705117

Comment 6

[Gervase Markham [:gerv]]

Thank you for the explanation, and the details of the steps you are taking to make sure this doesn't happen again.

Gerv