Thanks for your good test to have an experience to know more how we work. What I told Gerv that you can place an order at our site today -- Sept. 22nd 2016, but DON'T do the domain validation, leave it here. Four months later, you login your account to finish the domain validation, then system will post to CT log server to get SCT data, then the cert issued data is Jan 22nd 2017, the cert notBefore is Jan 22nd 2017. But the order data in our system is Sept 22nd 2016.
This is for explanation that Gerv ask why the order time is four month ago- Aug 15th, but the notBefore (the issuance day) is Dec. 20th for a free DV SSL certificate that take so long time. I wish I said this clearly, thanks. Best Regards, Richard -----Original Message----- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Thursday, September 22, 2016 11:38 AM To: Richard Wang <rich...@wosign.com> Cc: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Incidents involving the CA WoSign 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.com@lists.mozilla.o > rg] 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
