预验证是用作证书透明度（CT）一部分的特殊类型的SSL证书。 预先证书与常规SSL证书不同，因为它们不是（也不可以）用于验证服务器或形成经过身份验证的连接（例如HTTPS连接）。它们的唯一目的是允许证明证书已被记录以直接嵌入到证书中。顾名思义，预认证出现在正式证书之前。而预证书几乎很少暴露给最终用户，也就是说你可能收到了预证书但从不知道它的存在。
预证书在证书透明度RFC中定义。本文将用简单的语言解释什么是预先证书，如何使用它们以及它们的工作机制。
为什么需要预证书？
预证书的存在是为了允许将证书透明度数据直接嵌入到最终证书中。
预验证是将证明提交到证书透明度日志（SCT）的证书的几种方式之一。 预处理的优点是允许将CT数据嵌入SSL证书本身，而不是作为单独的数据提供（其他方法要求在握手期间将SCT作为单独的文件发送，与OCSP Stapling类似）。
CT日志需要能够为该证书的数据生成一个有效的签名（SCT），但是CA还需要日志中的SCT才能创建最终的证书。 于是需要预证书来解决这个问题，它允许日志生成正确的签名，而不需要最终的证书。
以下是需要用到预证书的场景：
证书颁发机构（CA）将向客户签名并颁发证书。他们需要使其符合浏览器的CT策略，因此他们需要将证书提交到CT Log。
CA对如何提供证书已被记录的证据有不少选择。如果他们想直接将该证明嵌入证书，他们将需要使用预认证。
在CA签署最终证书之前，他们首先创建一个预认证，其中包含相同的数据，但格式化为特定方式，以使其不被视为有效的SSL证书。
CA将预认证提交到CT日志并接收SCT（签名证书时间戳）。这是一个由日志签署的文件，可用于密码证明客户端证书已被记录。
CA发布最终证书，SCT嵌入其中。
终端用户可以部署他们的证书，并证明他们的证书中包含它们的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）。
因为这个扩展是存在的，Windows将预认证视为无效。 这样可以防止在使用SSL证书的情况下使用SSL，例如在HTTPS连接中。 在macOS上，证书查看器会说“不能使用此证书（无法识别的关键扩展）”。
在证书透明度协议（仍在开发中，RFC6962）的2.0版本中，预认证的格式将从X.509更改为CMS（加密消息语法）。 这意味着预制证的技术格式和编码将会大大改变，并且将不再是与常规SSL证书相同的格式。也就是说，当部署CT 2.0时将不会再有毒药扩展，因为不需要区分预密码和有效的X.509 SSL证书。