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?
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
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?
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 creation?
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
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.
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?
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