On 2016-09-21 12:11, Richard Wang wrote:
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.
This is a little misleading. The hex encoding is 31 / 32 characters. It's probably more useful to say that it has 128 bit, and you had a problem is the top 4 bits where all a 0.
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.
That's a rather weird failure mode. But it was perfectly able to sign it, it just didn't generate a new one. And I'm a little concerned that this failure mode can happen again.
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.
Why is the SHA-1 blocked at the Buy level and not at the PKI level? Kurt _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
