译：How Certificate Transparency Works
证书透明为当前的SSL证书系统增加了三个新的功能组件：
- 证书日志
- 证书监控
- 证书审计
这些功能组件代表了能提供补充的监控和审核服务的离散软件模块。他们不替代当前的SSL证书系统，也不作为一个选择。实际上，这些组件没有改变基础的信任链模型--让客户端验证域并与服务器建立安全的连接。相反，这些组件通过支持整个SSL证书系统的公开监督和审查扩充了信任链模型
日志基本功能
证书透明系统的中心在于证书日志。一天证书日志是一个简单的网络服务，保存了一条SSL证书记录。证书日志有三条重要的特性：
- 只能追加--证书只能被添加到日志中；证书不能被删除，修改或追溯地插入到日志中。
- 加密确认--日志使用特殊的Merkle Tree Hashes加密机制来防止篡改和违规行为。
- 公开审核--任何人都能查询一条日志并且验证日志的行为，或验证SSL证书已被正确地添加到日志中。
日志数量不必太大：需要足够的日志来保证日志失败或临时中断，但是还不能多到让监控变的困难--例如，超过10条但远小于1000条。每条日志的操作要独立于其他日志（也就是，日志间没有自动复制）。
日志的只能追加的性质允许使用特殊类型的加密哈希来验证日志没有损坏，并且这条日志中没有删除或修改任何证书的操作。这种特殊的哈希--Merkle Tree Hash--也能让审计发现是否有人分叉了日志或向日志中注入过期的证书。关于哈希机制的更多信息看证书透明化日志工作原理。
每条证书日志必须公开地公布其URL和公钥（除此之外的其他东西）。任何人都可以通过HTTPS的GET和POST消息与日志交互。
日志基本操作
任何人都能向日志提交证书，尽管大多数证书被证书机构和服务器运营商提交。向日志提交有效证书时，日志以签名证书时间戳(SCT) 回应。SCT是一个在某个时间段内将证书添加到日志中的简单的保证。这个时间段称作最大合并延迟(MMD)。
MMD有助于确保日志服务器在合理的时间段内将证书添加到日志中，并且不会阻塞证书的发布和使用，同时允许日志为了弹性和可用性运行分布式服务。SCT伴随证书的整个生命周期。特别是，TLS服务器必须在TLS握手期间将SCT和证书一起交付。
证书透明支持三种交付带有证书的SCT方法，每种的描述如下：
X.509v3扩展
证书机构（CA）使用X.509v3扩展将SCT附加到证书上。图一展示了工作流程。证书机构向日志中提交预认证，并且日志返回SCT。CA然后将SCT作为X.509v3扩展附加到预认证中，对证书签名，然后将证书交付给运营商。
该方法不需要任何服务器更改，使运营商可以像以往一样继续管理其SSL证书。
TLS扩展
运营商可以使用特殊的TLS扩展交付SCT（图2）。这种情况下，CA将证书颁发给服务器运营商，然后服务器运营商将证书提交到日志中。日志将SCT返回给运营商，然后在TLS握手期间，运营商使用带有签名证书时间戳（signed_certificate_timestamp）将SCT交付给客户端。
这种方法没有改变CA颁发SSL证书的方式。然而仍然需要服务器以适应TLS扩展做出改变。
OCSP装订
运营商也可使用在线证书状态协议（OCSP:
Online Certificate Status Protocol）装订来交付SCT（图2）。这种情况下，CA同时向日志服务器和运营商颁布证书，然后运营商向CA进行OCSP查询，CA返回SCT，在TLS握手期间服务器将SCT包含在OCSP扩展中。
这种方法允许CA对SCT担责，但是不能延迟颁布证书，这是因为CA能异步地收到SCT。但是，确实需要修改服务器才能进行OCSP装订。
监视器和审计的基本操作
监视器监控日志中可疑的证书，像非法或未授权的证书，不正常的证书扩展，或者奇怪权限的证书（举例，CA证书）。监视器也验证所有已记录的证书在日志中可见。通过周期性地获取已被添加到日志中的所有新条目来做到这一点。因此，大多数的监视器能完全复制监控到的日志。如果一条日志长时间地处于脱机状态，且监视器有该条日志的副本，监视器就能作为只读的备份日志，向查询该日志的其他监视器和审计提供日志数据。
审计验证日志的整体完整性。有些审计也验证日志中是否有特定的证书。通过周期地获取和验证日志证明来做到这一点。日志证明是被加密哈希签名过的，以证明日志的良好性。每条日志必须按需提供他们的日志证明。
审计可以用日志证明来验证日志的新条目已被添加到日志旧条目中，并且无人能通过追溯地插入，删除，或更改证书来损坏日志。审计也使用日志证明来验证日志中的特定证书。这尤其重要，因为证书透明框架需要所有的SSL证书被登记到日志中。
如果TLS客户端确定（通过审计）日志中没有证书，可以使用日志中的SCT作为日志未正确运行的证据。关于日志证明的更多信息看证书透明化日志工作原理。
尽管日志证明允许审计或监视器验证特定日志的视图和之前视图的一致性，他们也需要和其他监视器和审计验证特定日志的视图的一致性。为了方便证明，审计和监视器通过小道消息协议来交换日志信息。异步通信路径帮助审计和监视器发现分叉的日志。
典型系统配置
证书透明性框架没有规定现有SSL证书系统中监视器和审核器的任何特定配置或位置。也就是说，一些配置比其他配置更常见。在典型的配置中，CA运行监视器，客户端（浏览器）运行审计（图3）。这种配置简化了监控和审计间必要的消息，且让证书机构和客户端开发监控和审计系统，以满足客户和使用者的特殊需求。下面介绍一些驱动该配置的过程。
证书颁布
CA获得日志中的SCT，通过X.509v3扩展将SCT合并到SSL证书中（详细过程看图1）。然后CA向服务器运营商颁布证书（附有SCT）。该方式需要没有服务器更新（所有的当前服务器支持X.509v3扩展），且让服务器运营商像管理SSL证书的同样方式来管理他们的证书。
TLS握手
TLS握手期间，TLS客户端接收SSL证书和证书的SCT。通常，TLS客户端验证证书和签名链。另外，TLS客户端验证SCT上的日志签名，以验证SCT是由有效的日志发布的，且SCT实际上是为该证书（非其他证书）颁布的。如果有异样，TLS客户端可能会拒绝证书。举例，TLS客户端通常会拒绝SCT时间戳还未生效的证书。
证书监控
大部分的监视器由证书机构操作。通过配置，证书机构构建根据自身的特定监视标准和要求进行定制的有效的监视器。
证书审计
大部分的审计可能内置于浏览器中。在此配置中，浏览器会定期批量地发送SCT到其集成的认证组件，并且询问这些SCT（和相应的证书）是否被正确的添加到日志中。之后审计异步地拿到日志并执行验证。
其他系统配置
除了上述典型的配置以为，监视器和审计与现存的TLS/SSL组件紧密集成，证书透明支持多种其他的配置。例如，审计可作为独立实体运行，向证书机构和服务器运营商提供有偿或无偿的服务（图4）。监视器也可以通过服务器运营商运行，像大型的互联网公司谷歌，微软，或雅虎。同样地，设计也可作为独立服务运行，也可是监视器的第二功能。
