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? > 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? > 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. > 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? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
