See below inline, thanks.

Best Regards,


-----Original Message-----
From: Gervase Markham []
Sent: Tuesday, September 20, 2016 7:37 PM
To: Richard Wang <<>>
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 16/09/16 11:05, Richard Wang wrote:

> Hi Gerv,


> This is the final report:



> Please let me if you have any questions about the report, thanks.

Thank you for this report. I have a few follow-up questions:

Issue H: Duplicate Serial Numbers

1) You write: "Firstly 313 certificates and secondly 27 certificates were 
affected by a system bug with the serial number generation, generating a serial 
number starting with “0” in the first left position. The signing system had a 
bug that didn’t know how to deal with this kind of serial number."

Can you explain a bit more how such a bug can lead to all the certificates 
having the same serial number?


Richard:  please check the first 313 certificate serial is 
“56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is 
“D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number 
rule is 32 bytes, so the real two serial number is 
“056D1570DA645BF6B44C0A7077CC6769” and “0D3BBDC3A0175E38F9D0070CD050986A” that 
the signing system has a bug that don’t know how to deal with this kind of 
serial and locked to use this same serial number to sign the certificate.

Please notice the two case (313 and 27) happened in the same time that the 
first 313 certificate is issued by one intermediate CA in English, and the 
second 27 certificate is signed by another intermediate CA in Chinese. This is 
why two case, but we fix the bug, then no more happened.


Issue S: Backdated SHA-1 Certs

2) You say that you "found only 8 SHA-1 SSL certificates that were mis-issued 
after January 1st 2016 until June 28th 2016." Why did your searching end at 
June 28th? Have you looked at the rest of June, July and August?


Richard: I checked every system to make sure every procedure step has closed 
the SHA-1 option for SSL certificate at June 28th 2016 after we got report from 
Computest, there are another place in API can go to signing server that don’t 
go to SHA-1 blocking system first, this is a bug from the unused API code for 
StartEncrypt. So I can guarantee no more after that day.


3) You say you sent an email to all your staff at the end of December 
forbidding SHA-1 issuance. Does that mean the staff have control of whether a 
cert uses SHA-1 or not? Does WoSign employ certificate templates to make sure 
all appropriate fields are set correctly? If not, why not? If so, is the hash 
algorithm used something that employees can set or override?


Richard: as I said in the report, after my email, the Buy website don’t accept 
SHA-1 request after Dec. 30th 2015. But due to some pending request in the 
system that ordered before Dec. 30th 2015, so the PKI system still allow to 
sign SHA-1, this is the problem, we have 3 systems: Buy – CMS – PKI. No anyone 
can change the setting since the certificate template setting is controlled by 
me only.


4) All 64 of the certificates being considered here have a notBefore date of 
Sunday, 20th December 2015. Does that correctly reflect the date the 
certificates were created (to within a day)? (For this question, ignore the 2 
certificates mis-issued to CompuTest via the StartEncrypt API.)

If not, what is the technical reason for this back/forward dating? And can you 
please provide a list of the 64 certificates along with their actual dates of 


Richard: For the 62 certificates, there are 22 certificates issued at 19th Dec, 
40 certificates is issued at 20th Dec. 2015.  I checked our system, Dec 20th is 
very normal day, we issued SHA-1 certificate at every day, just one day no 
SHA-1 cert. We provide 24 x 365 service for worldwide customers.
Here is the statistics for the last two weeks SSL certificate issuance in 2015.


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.


Issue S, Category 1

These questions relate to your first category, the six certificates which were 
mis-issued due to a bug.

5) You say that the certificates were pre-signed, at some point before midnight 
on 31st December 2016, but then the process was stopped for payment or proof 
document problems. Is it WoSign's normal practice to sign certificates before 
payment has been received? Is it normal practice to sign certificates before 
all identity checks have been completed?

Richard: 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: The first one is this 
customer’s customer service executive that he/she is responsible for 
communicating for what proof document need, and check this customer’s document 
is missing and have distinct problem; the second person is the customer service 
team manager to check each order to try to find out each customer service team 
make any mistake that need to record to KPI; the 3rd person is the Validation 
Employee A view the order and proof document, the 4th person is the Validation 
Employee B double check and phone call verification, the 5th person is the PKI 
issuer that approve the order to PKI for signing, the 6th person is the 
financial casher to check if it is paid and responsible for upload the bank 
payment information screenshot to system as a very important proof document I 
describe it in the first report, the 7th person the next day reviewer from the 
validation team that it maybe involve more person that I described in the first 
report. Anyone can stop the order process if he/she find some problem.


6) Taking as an example these two certs:

and their SHA-256 counterparts:

On January 4th 2016, you CT-logged a SHA-1 pre-cert, got some SCTs from the CT 
server, and then (mistakenly) created the SHA-1 cert and stored it in your 
internal log. (Later, you uploaded it to CT as part of your batch upload.) On 
the same day, January 4th 2016, you also CT-logged a

SHA-256 pre-cert, got some SCTs back from the CT server, and then created a 
SHA-256 cert, to send to the customer. These two processes seem very similar, 
so I would expect the certificate contents to be very similar. Why, then, does 
the SHA-1 cert have a notBefore of 2015-12-19, whereas the SHA-256 cert has a 
notBefore of 2016-01-04?

7) You say these certificates were misissued due to a bug. It seems that the 
effect of the bug was such that it incorrectly retained the SHA-1 pre-cert 
version of the cert (created before 2016-01-01), sent it to CT (on 4th Jan), 
received the SCTs, incorporated them into the cert, signed the cert using SHA-1 
(after 2016-01-01), and then stored it in your internal systems? That seems 
like quite an extensive bug.


Richard: Not the case, only one simple bug from CT Post system. I try to say 
more clear. 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:, 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.


8) You say that the six certs in category 1 are all now revoked. When did you 
revoke them? If this was not at the time you discovered and fixed the bug which 
created them (around 18th January 2016), why not?


Richard: 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, some certificate 
is even not retrieved by customer, no any website used the SHA-1 certificate. 
This also certify that no any intentional possibility to sign SHA-1 to 
customers. This bug is fixed but it is no chance to function more case since 
BUY system blocked the SHA-1 order.


I may have some more questions later, as I am still working through the report. 
However, I thought I'd give you a chance to get started on these ones :-) 
Thanks for any additional information you can provide,


dev-security-policy mailing list

Reply via email to