譯： 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）。監視器也可以通過服務器運營商運行，像大型的互聯網公司谷歌，微軟，或雅虎。同樣地，設計也可作為獨立服務運行，也可是監視器的第二功能。
