1293366 - WoSign issued SHA-1 SSL certs and backdated the issuance date on SSL certificates

Status: RESOLVED FIXED

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

Description

[Kathleen Wilson]

The following was reported by Christiaan Ottow on July 1, 2016, in the mozilla.dev.security.policy forum.

""
If you plan on checking CT logs, make sure to check WoSign-signed certs as well. The "caID" parameter in the POST request to the StartEncrypt API allows you to select which CA will sign you certificate. The default, "2", makes that your request is signed by "StartCom Class 1 DV Server CA", "1" selects "WoSign CA Free SSL Certificate G2" and "0" selects "CA 沃通根证书". Perhaps the certificates are being logged into a different CT audit server because of this feature. 

We selected "1" for a test certificate last week, and the certificate we obtained was dated 20 December 2015, and signed using a SHA-1 checksum. I've attached the certificate (excluding modulus and signature). The checksum (SHA256) of the full cert is D1:2F:AB:12:E2:40:70:40:B4:2B:FF:46:FF:9B:A8:BB:8C:1F:63:E4:7F:ED:F2:D3:70:D2:12:3B:54:28:D1:4B
""

Of particular note, WoSign has issued SSL certs that have a backdated issuance date, and are SHA-1.

Comment 1

[Kathleen Wilson]

Richard (of WoSign), please reply in this bug to the following questions as soon as possible.

1) When were you notified of this problem, and when was the problem contained/resolved?

2) What analysis have you done to determine which SHA-1 and backdated SSL certificates were issued?
Presumably, if Christiaan Ottow was able to use that API, anyone on the internet could have been using that API.

3) Please provide the information (in this bug) about which mis-issued certificates should be added to OneCRL.

4) What actions have and will you be taking to fully resolve the noted problems?
What is the timeline that you are targeting for implementation/resolution?

Comment 2

[Richard Wang]

Attachment: two mis-issued_certs.zip

Comment 3

[Richard Wang]

(In reply to Kathleen Wilson from comment #1)
> Richard (of WoSign), please reply in this bug to the following questions as
> soon as possible.
> 
> 1) When were you notified of this problem, and when was the problem
> contained/resolved?

We got report from Computest before Computest public this bug, after we get this bug report, we checked that no anyone use this bug except Computest, we deleted the discard API parameter, and also ask StartCom stop to use this API. Here is the details:
+-----------------------------------------------------------------------------------------------------------
* domain   |    source IP    |    serial Number    |   requet time    |  issue time         | Client   |
------------------------------------------------------------------------------------------------------------
* startssl9.s.xnyhps.nl |  46.19.32.61  |6565e1710a48fbbe1e2b61835c789c39 | 2016-06-23 16:28:33 |  2016-06-23 16:28:37  | ssl_fairy-1.0.0-Linux.x86_64  StartEncrypt   |
------------------------------------------------------------------------------------------------------------
* startssl9.s.xnyhps.nl |  46.19.32.61  |6745ed57fe25880fb7d93a774310cf59 | 2016-06-28 16:41:17 |  2016-06-28 16:41:19  | ssl_fairy-1.0.0-Linux.x86_64  StartEncrypt   |
------------------------------------------------------------------------------------------------------------
 
 
> 2) What analysis have you done to determine which SHA-1 and backdated SSL
> certificates were issued?
> Presumably, if Christiaan Ottow was able to use that API, anyone on the
> internet could have been using that API.

Yes, anyone can use this bug to issue backdated SSL certificate that the issuance time is Dec 20, 2015, this date is the day we stop to use this code.
Luckily, we checked our PKI system that only two test cert from Computest issued this kind of certificate, no any one found this bug due to the API released less than one month.
this is non-used, non-public API parameter that Computest guess out.

> 3) Please provide the information (in this bug) about which mis-issued
> certificates should be added to OneCRL.

Only two test cert is issued that Computest don't use it, the two cert is attached in attachment 8779147 [details]. I don't think it is need to add to OneCRL, we have revoked it.

 
> 4) What actions have and will you be taking to fully resolve the noted
> problems?
> What is the timeline that you are targeting for implementation/resolution?

After we got report from Computest, we delete this non-used API parameter, and stop this API in server side that no any one can call this API. And we also notice StartCom stop to use this API. StartCom also stop the StartEncrypt service that plan to use ACME protocol for the future version at July 4th.

Comment 4

[Richard Wang]

To prevent the mis-issuance in the future, WoSign is logged all issued SSL certificates to Google log server and other log servers for full transparency: https://www.wosign.com/english/News/2016_wosign_CT.htm 
For browsers, if any SSL certificate issued by WoSign after July 5th, 2016 that don’t include SCT data, browsers can distrust this SSL certificate and report to us as an incident. For WoSign customers, if you find the SSL certificate don’t include the SCT data, then you can refuse to accept it and ask for re-issuance or ask for refund, including free SSL certificate and charged certificate, including DV SSL, IV SSL, OV SSL and EV SSL certificate.

Comment 5

[Kathleen Wilson]

(In reply to Richard Wang from comment #3) 
> We got report from Computest before Computest public this bug, after we get
> this bug report, we checked that no anyone use this bug except Computest, we
> deleted the discard API parameter, and also ask StartCom stop to use this
> API. Here is the details:
> +----------------------------------------------------------------------------
> -------------------------------
> * domain   |    source IP    |    serial Number    |   requet time    | 
> issue time         | Client   |
> -----------------------------------------------------------------------------
> -------------------------------
> * startssl9.s.xnyhps.nl |  46.19.32.61  |6565e1710a48fbbe1e2b61835c789c39 |
> 2016-06-23 16:28:33 |  2016-06-23 16:28:37  | ssl_fairy-1.0.0-Linux.x86_64 
> StartEncrypt   |
> -----------------------------------------------------------------------------
> -------------------------------
> * startssl9.s.xnyhps.nl |  46.19.32.61  |6745ed57fe25880fb7d93a774310cf59 |
> 2016-06-28 16:41:17 |  2016-06-28 16:41:19  | ssl_fairy-1.0.0-Linux.x86_64 
> StartEncrypt   |
> -----------------------------------------------------------------------------
> -------------------------------
>  

Cert issued 2016-06-23 16:28:37 
serial number:	6565e1710a48fbbe1e2b61835c789c39
signature:	sha1WithRSAEncryption
issuer:	C=CN, O=WoSign CA Limited, CN=WoSign CA Free SSL Certificate G2
not before:	Sat Dec 19 2015 17:27:28 GMT-0800 (PST)
not after:	Thu Dec 29 2016 08:00:00 GMT-0800 (PST)
subject:	CN=startssl9.s.xnyhps.nl
subjectAltName	DNS name:startssl9.s.xnyhps.nl
sha1 hash:	D8:68:F1:7A:D6:27:B1:88:57:26:D0:46:5D:93:6F:AE:62:56:CD:D0
sha256 hash:	D1:2F:AB:12:E2:40:70:40:B4:2B:FF:46:FF:9B:A8:BB:8C:1F:63:E4:7F:ED:F2:D3:70:D2:12:3B:54:28:D1:4B
extKeyUsage	clientAuth, serverAuth
basicConstraints	cA: false
authorityInfoAccess	ocsp: http://ocsp1.wosign.com/ca6/server1/free, caIssuers: http://aia1.wosign.com/ca6.server1.free.cer


Cert issued 2016-06-28 16:41:19
serial number:	6745ed57fe25880fb7d93a774310cf59
signature:	sha1WithRSAEncryption
issuer:	C=CN, O=WoSign CA Limited, CN=WoSign CA Free SSL Certificate G2
not before:	Sat Dec 19 2015 19:50:42 GMT-0800 (PST)
not after:	Thu Dec 29 2016 08:00:00 GMT-0800 (PST)
subject:	CN=startssl9.s.xnyhps.nl
subjectAltName	DNS name:startssl9.s.xnyhps.nl
sha1 hash:	02:CA:14:8B:21:FA:C1:B7:A3:BF:65:90:EA:FE:9C:B1:BE:F7:66:1C
sha256 hash:	EF:F6:ED:36:3A:D6:DE:9A:4C:CA:F5:87:DF:C5:E4:D0:1B:B8:48:B7:DD:2A:ED:6D:AA:E7:96:E9:08:42:46:AD
extKeyUsage	clientAuth, serverAuth
basicConstraints	cA: false
authorityInfoAccess	ocsp: http://ocsp1.wosign.com/ca6/server1/free, caIssuers: http://aia1.wosign.com/ca6.server1.free.cer

Comment 6

[Filip Jirsák]

Because of bug #585352 users can't mark WoSign certificate as untrusted withou untrust whole StartSSL CA.

Comment 7

[Kathleen Wilson]

Additional problems with WoSign SSL cert issuance process/code listed here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/mKSMaz9eCgAJ

Comment 8

[Gervase Markham [:gerv]]

Mozilla has taken action with regard to WoSign; see m.d.s.policy.

Gerv