Richard,
I'm having a really hard time reconciling what you describe with what
is found in the CT logs and what I observed today when doing as you
suggested and getting a cert from https://buy.wosign.com/free/.
I pulled all the WoSign certificates from CT logs that have embedded
SCTs. There are 40418 such certificates (as of a few days ago), of
which 898 are EV certificates. For the EV certificates, other than
the six that were raised as potentially being backdated, the delta
between the notBefore date and the earliest SCT embedded in the
certificate ranged from 1130.54 to 9949.10 seconds. 890 of the 898 EV
certificates had a delta under one hour. When looking at the full set
of 40418, the delta ranges from 1128.91 to 182896.75 seconds. All the
certificates with a delta greater than 10000 seconds have a notBefore
date of 2016-07-29, again with the exception of the six certificates
Gerv raised.
Are you saying out of over 40,000 orders over the last year, only six
"stopped to move forward" for a period of a week or more and these
happen to all have been ordered on Sunday, December 20, 2015 (China
time)?
I also would like to get your feedback on the timeline I observed
today when I get a certificate at the site you suggested. Here is
what I observed (ordered by time):
2015-09-21 15:31 UTC Order created
2015-09-21 19:58 UTC Domain Validated
2015-09-21 20:05 UTC Uploaded CSR (sorry, failed to log time,
approximate time)
State moved to "Pending" (shortly after uploading CSR)
2016-09-21 23:10:42 UTC Certificate NotBefore
2016-09-21 23:36:32 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:35 UTC WoSign Log SCT (using precertificate)
2016-09-21 23:37:08 UTC Date header on Certificate ready for collection email
Mail received headers: 23:37:13 (by mta1.wosign.com), 23:37:44 (by
mx.google.com).
It would appear that the NotBefore was not set until after I completed
validation, uploaded a CSR, and the order passed other (possibly
human) checks. From that point it was less than half an hour until I
had my certificate. Is this the behaviour you expect to see?
Thanks,
Peter
On Wed, Sep 21, 2016 at 7:26 AM, Richard Wang <rich...@wosign.com> wrote:
> Hi Gerv,
>
> See below inline, thanks.
>
> Regards,
>
> Richard
>
> -----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
> happen?
>
> 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
> August/September?
> ------------------------------
> R: see above, we don’t know this bug that mis-issued 6 SHA-1 certs.
> ------------------------------
>
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
