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?

dev-security-policy mailing list

Reply via email to