预验证是用作证书透明度(CT)一部分的特殊类型的SSL证书。 预先证书与常规SSL证书不同,因为它们不是(也不可以)用于验证服务器或形成经过身份验证的连接(例如HTTPS连接)。它们的唯一目的是允许证明证书已被记录以直接嵌入到证书中。顾名思义,预认证出现在正式证书之前。而预证书几乎很少暴露给最终用户,也就是说你可能收到了预证书但从不知道它的存在。

预证书在证书透明度RFC中定义。本文将用简单的语言解释什么是预先证书,如何使用它们以及它们的工作机制。

什么是SSL预证书?-RadeBit瑞安全

为什么需要预证书?

预证书的存在是为了允许将证书透明度数据直接嵌入到最终证书中。

预验证是将证明提交到证书透明度日志(SCT)的证书的几种方式之一。 预处理的优点是允许将CT数据嵌入SSL证书本身,而不是作为单独的数据提供(其他方法要求在握手期间将SCT作为单独的文件发送,与OCSP Stapling类似)。

CT日志需要能够为该证书的数据生成一个有效的签名(SCT),但是CA还需要日志中的SCT才能创建最终的证书。 于是需要预证书来解决这个问题,它允许日志生成正确的签名,而不需要最终的证书。

以下是需要用到预证书的场景:

1.证书颁发机构(CA)将向客户签名并颁发证书。他们需要使其符合浏览器的CT策略,因此他们需要将证书提交到CT Log。

2.CA对如何提供证书已被记录的证据有不少选择。如果他们想直接将该证明嵌入证书,他们将需要使用预认证。

3.在CA签署最终证书之前,他们首先创建一个预认证,其中包含相同的数据,但格式化为特定方式,以使其不被视为有效的SSL证书。

4.CA将预认证提交到CT日志并接收SCT(签名证书时间戳)。这是一个由日志签署的文件,可用于密码证明客户端证书已被记录。

5.CA发布最终证书,SCT嵌入其中。

6.终端用户可以部署他们的证书,并证明他们的证书中包含它们的CT合规性。这是包含SCT的最佳方式。

当你搜索证书透明度日志时,可能会遇到预认证,但不能检查关联的(有效的)证书。 这是因为CA不需要将后续证书提交到日志。 即使预先认证不被客户视为有效,但是仍然保留相同的发行标准。 CT RFC规定,“预认证的错误被认为等于最终证书的错误”。

预证书如何运作?

预证书不同于普通证书的点在于它使用X.509 v3格式的扩展名的数据字段区。扩展为X.509格式提供了灵活性,并允许采用新功能,而不需要新版本的格式。

预证书包含一个“有毒的扩展”。是的你没看错,这个扩展有毒!之所以这么称呼它是因为该扩展十分关键还不支持客户端。如果它没有被正确解析,那么正式证书就要GG(被判无效)了。而当客户端遇上预认证,十之八九都会把它认作无效。“有毒”扩展的存在可以说是常规证书和预证书之间唯一的区别了。

毒性扩展使用一种独一无二的OID:1.3.6.1.4.1.11129.2.4.3。OID又称对象标识符,是分配给某些目的并用于提供计算机可解析格式的标准化字符串。例如,您可以查看该OID号码,并看到它已被分配了以下目的:“证书透明度预认证毒药扩展(poison extension)”。其他OID(如1.3.6.1.5.5.7.48.1)用于SSL证书中以指示该证书的OCSP URL。

举个栗子,如果你在Windows中下载并打开一个预认证,它将看起来与常规SSL证书非常相似。 但是,在Windows“证书查看器”的“常规”窗格中,您将注意到它将显示为“证书包含未标识为”关键“的扩展名。”在“详细信息”中,您会看到底部附近列出的毒药扩展名(查找OID)。

什么是SSL预证书?-RadeBit瑞安全

因为这个扩展是存在的,Windows将预认证视为无效。 这样可以防止在使用SSL证书的情况下使用SSL,例如在HTTPS连接中。 在macOS上,证书查看器会说“不能使用此证书(无法识别的关键扩展)”。

在证书透明度协议(仍在开发中,RFC6962)的2.0版本中,预认证的格式将从X.509更改为CMS(加密消息语法)。 这意味着预制证的技术格式和编码将会大大改变,并且将不再是与常规SSL证书相同的格式。也就是说,当部署CT 2.0时将不会再有毒药扩展,因为不需要区分预密码和有效的X.509 SSL证书。