Hi Gerv,

See below inline, thanks.



-----Original Message-----
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On 
Behalf Of Gervase Markham
Sent: Wednesday, September 21, 2016 9:19 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

Thanks for the additional information.

On 21/09/16 11:11, Richard Wang wrote:
> Some SHA-1 certificate is free SSL certificate that no any reason for 
> us to help them get the SHA-1 certificate if we are intentional, and 
> some certificate is even never used or even not retrieved from our 
> system, this also can be certified it is a normal order without any 
> doubt.

I have examined the spreadsheet you sent (note: may not be available to 
mozilla.dev.security.policy participants due to lack of attachment support). 
The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
contains 12 certificates, which have no cost associated with them, and no 
identity vetting other than domain control. Why did each of these take over a 
month, and in some cases nearly 4 months, to be issued? What was the hold-up?
R: You can place order there and don't do the domain validation, 4 months 
later, you finished the domain control validation, then issue the certificate. 
Please try it by yourself here: https://buy.wosign.com/free/ 
> I think there are many reasons to stop to sign it due to double check, 
> for EV order, it must pass at least 6 person’s check:

Yes, indeed. But at what point during these checks do the following events 

A) Pre-cert is created and signed (if needed)
B) Pre-cert is sent to CT (if needed)
C) Real cert is created and signed
D) Cert is sent to the customer

I would expect none of these things to happen until all checks are completed. 
We know from previous conversations that your step 7 (next day review) happens 
after C) and D). Where do those four events fit into your seven steps, exactly?
R: not of all. The process is stopped after pre-signed the cert but not post to 
CT log server.
> Not the case, only one simple bug from CT Post system. I try to say 
> more clearly.
> https://crt.sh/?serial=6D24E483E27F55479C5C555B37745353 is ordered in 
> 19th Dec. 2015, and system pre-signed the pre-cert using SHA-1, no any 
> problem. But it is stopped due to some more check. At 4th Jan.
> 2016, this order finished the final check and go to signing server, 
> signing server generated a new SHA-2 pre-cert to post to CT log server 
> since SHA-1 is not allowed, and get SCT data to the certificate, this 
> is the second certificate:
> https://crt.sh/?serial=31742a2b12809bfca04cffc050903837, also no any 
> problem. The problem is the CT post system have a bug that posted the 
> two related pre-cert to CT log server (SHA-1 pre-cert is the original 
> one, and SHA-2 pre-cert is the new copied one), then get two 
> certificates one signed with SHA-1 and one is SHA-2.  We also posted 
> the two issued certificates to CT log server later.

But that's not how CT works. You don't sent the CT server a pre-cert and get a 
cert back. You send it a pre-cert, and it sends SCTs back. You then need to get 
those SCTs, incorporate them into a new certificate which has the SCTs but not 
the poison extension, and then sign that using your signing server, and then 
store it in your database. All that happened by mistake, due to a single bug? 
You stored the certificate in your system for a number of months because you 
still had it in September when you uploaded it to CT.
R: let me try to draw a work flow:
1) SHA-1 cert request at Dec 19th 2015, system pre-signed it as "Pre-cert A" in 
our database, this order is in pending issuance status;
2) but this order is reviewed and stopped to move forward by some reason; so 
this order still in pending status;
3) at Jan 4th 2016, this order is released to move forward. But today is Jan 
4th that SHA-1 cert is forbidden, so the signing server sign the same CSR again 
using SHA-2 to be "Pre-cert B";
4) then the CT Post system posted the two pre-cert into CT log server since 
this two pre-cert is in one order record, this is the bug, it must post the 
Pre-cert B to CT log server, not Pre-cert A, but it posted both;
5) the two pre-cert get SCT data, back to signing server, the signing server 
signed the two cert out: one is SHA-1 with notBefore Dec 19th 2015, one is 
SHA-2 with notBefore Jan 4th 2016;
6) this means the original order copied to two orders in system with two signed 
certificate. The interesting thing is customer just retrieve the SHA-2 cert and 
installed it in his website.
We don't know this bug till someone expose this in the email discussion since 
we issued few EV SSL certificate. So only 6 cases happened in this bug. Sure, 
we fixed the bug and revoked the six SHA-1 certificate. But this bug can't 
bring more harm since BUY system stop to accept SHA-1 order since Dec 30th, 
2015. This bug only happened in the SHA-1 to SHA-2 transitional period. In our 
case, till Jan. 18, no more happened since no more SHA-1 order placed in 2015.

> The six certificates are revoked after someone pointed it out in the 
> email discussion, then we try to find out the reason and know that 
> this is a bug from CT Post system, then we revoked the six 
> certificate,

So you discovered the bug in January and fixed it, but did not look to see if 
it had led to any misissued certificates until the bug was discussed in 
R: see above, we don’t know this bug that mis-issued 6 SHA-1 certs.

dev-security-policy mailing list
dev-security-policy mailing list

Reply via email to