三天前，在生成TLS证书的mozilla.dev.security.policy邮件列表中生成了大规模违规
消息 。 调查显示，包括
GoDaddy ，
Apple和
Google在内的多个证书颁发机构均受到影响。 错误证书的总数超过一百万，甚至更多。 GoDaddy最初
将180万张证书
的数字命名 ，然后将等级降低了两个数量级，降至12,000个。
最重要的是，所有CA伤害都使用错误设置的
EJBCA开源PKI解决方案，结果将63位空间中的随机数用于证书序列号，这违反
了CA / B Forum的最低熵
要求 （64位）。
2
63和2
64之间的差异超过9位数，即9×10
18 ，这是一个非常大的数字（尽管差异只有一半）。 所有证书必须被吊销。 对于SSL.com和GoDaddy，此过程将花费30天，对于其他过程则可能需要大约相同的时间，尽管RFC5280标准要求它们在五天内撤消无效证书。 但是他们显然没有时间满足规范。
这是怎么发生的？
初步分析表明，对于所有证书，相应字段的长度恰好是64位：既不多也少。 如果RNG产生64位的熵，并且所有证书都恰好是64位，那么乍一看一切都很好。 但是问题是根据
RFC5280 ：
序列号
序列号必须是CA分配给每个证书的正整数。 对于由特定CA颁发的每个证书，它必须是唯一的（即，发布者名称和序列号标识唯一的证书）。
CA必须严格控制颁发CERT的过程，以使序列号永远不会是负整数。 上面提出的唯一性要求表明，连续数字可以是长整数。 CERT用户应该能够处理serialNumber子字段中的一个值，该值的长度最多为20个八位位组（含）。 遵循此标准的CA不应在serialNumber子字段中使用超过20个八位位组的值。
需要一个正数意味着不能设置最高有效位。 如果已安装，则不能将其直接用作证书的序列号。
许多CA都在使用流行的EJBCA PKI系统，默认情况下会生成64位数字，对于证书号，只需重置最高有效位即可。 也就是说，实际上，它们的RNG生成63位数字，这就是为什么许多CA遭受损失的原因。
RNG的64位默认要求不是从头开始制定的，而是在
2008年黑客攻击之后制定的，当时200个PlayStation 3游戏机的集群产生了针对MD5哈希的冲突，从而
允许创建所有浏览器和操作系统都将信任的伪造身份验证中心 。
2012年，
美国网络武器Flame使用此技巧渗透了Windows Update更新机制。
但是，现在使用SHA256进行生成，与MD5相比，它是一种更现代的算法，因此出于预防目的，更多采用64位的最低要求。 专家
说 ，现在没有机会找到63位的冲突，并且以某种方式利用错误的证书发现的错误。
但是，吊销数百万个证书对于许多公司的系统管理员来说是一个头痛的问题。
损失1位熵并不是那么可怕，但是某个地方的人可以找到一个窃取另外1-2位的漏洞，依此类推。 因此，必须立即修复所有此类漏洞。
