Changes

Secondly, the ID of certificates in WoSign's CT log can be used to show the logging sequence of a set of certificates even if they don't have embedded SCTs, because the IDs are sequential. If you order all certs in WoSign's log by ID, up to [https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a ID 109149], where the notBefore is on December 31st, the notBefore values are (approximately) chronologically ordered. Those which have embedded SCTs have timestamps which are about 2 hours later than the notBefore date. But after that follow 64 certificates which are all dated on December 20, 2015 (CST, UTC+8). This suggests that these were logged at the actual time of issuance but that time is not reflected in their notBefore date - i.e. they were backdated. And it further suggests that this behaviour only began after December 31st 2015, i.e. it was not a continuation of some previous behaviour. Thirdly, some certificates which are suspected to be backdated were issued at the same time as SHA-256 certificates for the same domain; the timestamps on the SHA-256 certificates are more likely to be the accurate ones. One example is for congfubao.com, where there is a [https://crt.sh/?id=11900532 SHA-256 cert] with a notBefore of 5th January and an SCT timestamp of 5th January, 17 seconds later than the SCT timestamp in the [https://crt.sh/?id=30773528 backdated SHA-1 cert]. The simplest explanation is that both certs were issued together, on January 5th. Other pairs include for ebank.pcnkbank.com ([https://crt.sh/?id=30773634 SHA-1], [https://crt.sh/?id=15425430 SHA-256]) and mail.gd.gov.cn ([https://crt.sh/?id=12356371 SHA-1], [https://crt.sh/?id=12362293 SHA-256]).