2018年四月份 Let’s Encrypt 宣布其發(fā)布的證書將直接嵌入 SCT 信息，作為全球最大的免費(fèi) CA 機(jī)構(gòu)蠢棱，他的一舉一動(dòng)對(duì)于 HTTPS 網(wǎng)站部署者來說非常關(guān)鍵，我們不禁要問甩栈，SCT 作用是什么泻仙？總結(jié)來說，證書透明度（Certificate Transparency量没，CT）特性（注意 CT 和 SCT 的區(qū)別玉转，CT 是證書特性，而 SCT 是 CT 特性的一種表現(xiàn)形式）是證書的有效補(bǔ)充殴蹄，它能夠讓你的網(wǎng)站更安全究抓。

這篇文章全面回顧 CT猾担，如果你的網(wǎng)站還不支持該特性，那么應(yīng)該快速行動(dòng)起來了刺下。

證書透明度

CT 是證書的一個(gè)特性绑嘹，正因?yàn)樽C書存在一些缺點(diǎn)，CT 才被創(chuàng)造出來橘茉，在理解 CT 之前工腋，我們有必要理解什么是證書、證書的作用捺癞、證書的缺陷夷蚊。

如果想部署 HTTPS 網(wǎng)站构挤，首先向 CA 機(jī)構(gòu)申請(qǐng)一張證書髓介，CA 機(jī)構(gòu)在審核申請(qǐng)者的身份后，會(huì)簽發(fā)一張證書筋现，證書中包含了申請(qǐng)者網(wǎng)站的主機(jī)名唐础、主機(jī)公鑰，同時(shí) CA 機(jī)構(gòu)會(huì)用自己的私鑰對(duì)整個(gè)證書進(jìn)行簽名矾飞，并將簽名添加到證書文件中一膨，然后發(fā)送給證書申請(qǐng)者。

證書是 TLS 協(xié)議中非常關(guān)鍵的一環(huán)洒沦，其主要作用：

• 向網(wǎng)站訪問者確認(rèn)服務(wù)器的真實(shí)身份豹绪，確保客戶端（瀏覽器）是和真正的網(wǎng)站提供者在通信申眼，避免遇到中間人攻擊瞒津，實(shí)現(xiàn)密碼學(xué)中的身份認(rèn)證特性。
• 客戶端和服務(wù)器使用證書中的公鑰（依賴于不同的密碼協(xié)商算法括尸，功能有所不同）協(xié)商出主密鑰（Master Secret）巷蚪，有了主密鑰，客戶端和服務(wù)器端就可以保證通信數(shù)據(jù)是加密且沒有被篡改濒翻。

證書的細(xì)節(jié)信息比較多屁柏，可以參考其他書籍和文章，本文主要描述證書在 PKI（public key infrastructure有送，公鑰基礎(chǔ)設(shè)施）體系中的一些缺陷淌喻。

對(duì)于一個(gè) HTTPS 網(wǎng)站來說，PKI 體系并不是孤立的技術(shù)解決方案雀摘，它由很多機(jī)構(gòu)組成似嗤，比如 CA 機(jī)構(gòu)、網(wǎng)站部署者届宠、用戶烁落、瀏覽器乘粒，證書是 PKI 最核心最重要的內(nèi)容，通過下圖可以了解 PKI 的構(gòu)成伤塌。

圖1：PKI

證書最大的問題就是偽造證書的存在灯萍，一旦出現(xiàn)偽造證書，PKI 安全體系將會(huì)非常脆弱每聪，出現(xiàn)偽造證書的原因如下：

• CA 機(jī)構(gòu)有意無意會(huì)簽發(fā)一些錯(cuò)誤的證書旦棉，比如 CA 機(jī)構(gòu)沒有正確校驗(yàn)申請(qǐng)者的身份。
• CA 機(jī)構(gòu)是一個(gè)追求盈利的機(jī)構(gòu)药薯，在利益的驅(qū)動(dòng)下绑洛，可能會(huì)無節(jié)制的簽發(fā)證書，如果簽發(fā)一個(gè)惡意的二級(jí) CA 證書童本，帶來的危害更大真屯。
• 攻擊者會(huì)通過各種技術(shù)攻擊手段，冒充或者偽造某個(gè)域名的擁有者穷娱，從而成功申請(qǐng)到一張證書绑蔫，然后通過證書進(jìn)行危害操作。

在 PKI 基礎(chǔ)設(shè)施中泵额，瀏覽器校驗(yàn)證書的時(shí)候配深，只能判斷證書是否是合法 CA 機(jī)構(gòu)簽發(fā)的，沒有技術(shù)手段校驗(yàn)證書是否是非法的嫁盲。即使未來發(fā)現(xiàn)證書是非法的篓叶，證書吊銷更新機(jī)制（CRL和OCSP）也是非常滯后的。

非法證書帶來的危害是非常大的羞秤，如果非法證書校驗(yàn)成功缸托，對(duì)于用戶來說，他認(rèn)為在和真正的服務(wù)器在通信锥腻，實(shí)際上是和潛在的攻擊者在通信嗦董，用戶的隱私和安全性將得不到保障。

在 PKI 基礎(chǔ)設(shè)施中瘦黑，可能會(huì)出現(xiàn)以下一些困惑：

• 域名擁有者無法知曉那些 CA 機(jī)構(gòu)給他簽發(fā)了證書京革，也不知道是否有人冒充他的身份申請(qǐng)證書并提供服務(wù)。
• CA 機(jī)構(gòu)并不清楚它到底簽發(fā)了多少證書幸斥，也不確定是否簽發(fā)了偽造證書匹摇，二級(jí) CA 簽發(fā)機(jī)制不可控。
• 對(duì)于瀏覽器來說甲葬，它沒有技術(shù)手段校驗(yàn)證書是否是合法的廊勃。

證書透明度

為了解決證書潛在的問題，谷歌提出了一個(gè)解決方案，這就是證書透明度（CT）坡垫，目前這個(gè)技術(shù)解決方案已經(jīng)非常成熟了梭灿，了解 CT，以下兩個(gè)網(wǎng)站必須了解：

• www.certificate-transparency.org
• rfc6962

CT 是一組技術(shù)解決方案冰悠，它能夠?qū)徲?jì)堡妒、監(jiān)控證書的簽發(fā)、使用溉卓，從而讓證書在 PKI 體系中更透明皮迟，它不是證書的替代解決方案，而是證書的有效補(bǔ)充桑寨，它也沒有改變 PKI 體系伏尼，這幾點(diǎn)務(wù)必要記住。

通過 CT尉尾，能夠達(dá)成以下的幾個(gè)目標(biāo)：

• CA 機(jī)構(gòu)能夠知曉其簽發(fā)了那些證書蔼两，并快速檢測(cè)到是否簽發(fā)惡意證書了拉宗。
• 網(wǎng)站擁有者能夠知曉域名對(duì)應(yīng)證書簽發(fā)的全過程漩仙，一旦發(fā)現(xiàn)有攻擊者偽造了域名對(duì)應(yīng)的證書踊兜，可以快速聯(lián)系 CA 機(jī)構(gòu)兽掰，吊銷該證書芭碍。
• 瀏覽器廠商能夠?qū)徲?jì)證書的使用情況，如果發(fā)現(xiàn)有惡意證書孽尽，可以快速關(guān)閉HTTPS連接窖壕，保障用戶的安全。

CT 是一個(gè)公開的技術(shù)解決方案杉女，并不是封閉的瞻讽，也不是谷歌專有的，PKI 體系中任何一個(gè)組織都可以參與熏挎，從而有效保障網(wǎng)站的安全性速勇。

CT 由三部分組成：

• Certificate logs
• Certificate monitors
• Certificate auditors

這三部分的結(jié)構(gòu)如下圖，詳細(xì)細(xì)節(jié)會(huì)逐步描述坎拐。

圖2：ct結(jié)構(gòu)

（1）Certificate logs

Certificate logs 是一個(gè)網(wǎng)絡(luò)服務(wù)（需要部署烦磁，也要提供查詢服務(wù)），是 CT 最核心的組成部分哼勇，Certificate logs 記錄了證書所有簽發(fā)記錄都伪，相當(dāng)于一個(gè)證書中心數(shù)據(jù)庫，任何人都可以新增积担、查詢證書簽發(fā)記錄陨晶。

Certificate logs 有幾個(gè)特性：

• 只讀，只能新增記錄帝璧，不能更新或者刪除記錄
• 通過一種稱為 Merkle Tree Hash 的機(jī)制進(jìn)行密碼學(xué)保護(hù)先誉，保證數(shù)據(jù)沒有篡改湿刽。
• 任何人都可以向 Certificate logs 提交證書，并且查詢證書是否合法存在于 Certificate logs 中褐耳。

向 Certificate logs 提交證書新增請(qǐng)求后叭爱，Certificate logs 會(huì)返回 SCT 信息（Signed Certificate Timestamp），SCT 非常重要漱病，相當(dāng)于證書簽發(fā)的票據(jù)买雾。

在 HTTPS 協(xié)議握手過程中，瀏覽器就是通過 SCT 信息（可以通過三種途徑獲妊蠲薄）確認(rèn)網(wǎng)站是否支持 CT漓穿，如果發(fā)現(xiàn)網(wǎng)站不支持，可以中止握手過程∽⒂現(xiàn)在大家應(yīng)該明白 CT 和 SCT 的區(qū)別了晃危。

任何人都可以構(gòu)建 Certificate logs 服務(wù)，一般情況下老客，CA 機(jī)構(gòu)給證書申請(qǐng) SCT 的時(shí)候僚饭，會(huì)向多個(gè) Certificate logs 服務(wù)發(fā)送請(qǐng)求。

下列表格列舉了部分符合 Chrome CT 策略的 Certificate Logs 服務(wù)：

（2）Certificate monitors

有了 Certificate Logs 服務(wù)的中心數(shù)據(jù)胧砰，Monitors 服務(wù)就可以基于 Certificate Logs 服務(wù)進(jìn)行監(jiān)控操作鳍鸵，任何人（主要是 CA 機(jī)構(gòu)）都可以構(gòu)建 Certificate monitors 服務(wù)。

通過 Certificate monitors 服務(wù)尉间，能夠查詢證書是否是未授權(quán)或者非法的偿乖，也能檢測(cè)證書包含的擴(kuò)展是否合法，也能檢測(cè)證書信息是否存在于 Certificate Logs 服務(wù)中哲嘲，總之通過 monitors 服務(wù)贪薪，證書的簽發(fā)和使用納入了 PKI 監(jiān)控體系，證書的使用更加透明了眠副。

下表列舉幾個(gè)常見的 CT Monitors 服務(wù)画切。

重點(diǎn)推薦 crt.sh囱怕，輸入域名就可以查看所有的證書簽發(fā)記錄了霍弹，如下圖：

圖3：crt

Facebook 的監(jiān)控服務(wù)也非常好，你可以在該服務(wù)上登記你擁有的域名光涂，一旦該域名有相應(yīng)的證書簽發(fā)了庞萍，F(xiàn)acebook 就會(huì)立刻發(fā)送消息通知你，這樣你就可以更好的監(jiān)控證書的使用了忘闻。

潛在的一個(gè)問題钝计，任何人可以查詢?nèi)我庥蛎?CT 信息，潛在帶來一定的隱私問題，當(dāng)然證書和域名一樣私恬，使用過程確實(shí)應(yīng)該處于監(jiān)控之下债沮，這樣才能保障安全。

（3）Certificate auditors

Certificate auditors 服務(wù)主要由瀏覽器來完成本鸣，主要有二個(gè)步驟：

• HTTPS握手階段校驗(yàn)證書是否包含 SCT 信息疫衩，如果沒有說明證書不符合 CT 機(jī)制，可能存在潛在的危險(xiǎn)荣德。
• 異步校驗(yàn)證書是否存在錯(cuò)誤簽發(fā)闷煤，惡意使用的情況，相當(dāng)于完成 Certificate monitors 服務(wù)的功能涮瞻，整個(gè)過程是異步的鲤拿，避免影響 HTTPS握手。

如何獲取 SCT

前面描述了基礎(chǔ)性的知識(shí)署咽，對(duì)于網(wǎng)站部署者來說近顷，其更關(guān)心如何讓網(wǎng)站支持 CT，確切的說宁否，如何獲取 SCT 信息窒升，網(wǎng)站支持 CT 有三種途徑，分別是證書擴(kuò)展慕匠、OCSP 協(xié)議饱须、TLS/SSL 協(xié)議擴(kuò)展。這三種方式有不同的應(yīng)用場(chǎng)景絮重，有些需要 CA 機(jī)構(gòu)處理冤寿，有些需要網(wǎng)站部署者處理歹苦，接下去分別描述青伤。

（1）通過證書擴(kuò)展獲取 SCT

目前 Let’s Encrypt 證書直接包含了 SCT 信息，這種方式無需網(wǎng)站部署者做任何的操作就能讓網(wǎng)站支持 CT殴瘦，從效率上和可管理性看狠角，這種方式是最好的，CA 機(jī)構(gòu)提供的證書直接包含 SCT蚪腋。

對(duì)于 CA 機(jī)構(gòu)（以 Let’s Encrypt 為例）來說丰歌，需要注意在簽發(fā)證書的時(shí)候，先要獲取 SCT 信息屉凯，然后再將 SCT 信息嵌入到證書中立帖，但是由于沒有證書就無法獲取 SCT，為了解決這個(gè)問題悠砚，Let’s Encrypt 先生成一張 precertificate 證書晓勇，然后向兩個(gè) Certificate Logs 提交 precertificate 證書（一個(gè)是谷歌的 Certificate Log 服務(wù)，另外一個(gè)是非谷歌的 Certificate Log 服務(wù)），獲取到 SCTs 后绑咱，再修改 precertificate 證書绰筛，添加 SCTs 擴(kuò)展。

從 2018 年4月30號(hào)以后描融，所有在 Let’s Encrypt 簽發(fā)或更新的證書將自動(dòng)包含 SCTs铝噩。

可以使用 OpenSSL 命令行工具獲取證書 SCTs 信息，比如運(yùn)行下列命令：

$ openssl x509 -in  /etc/letsencrypt/live/simplehttps.com/cert.pem -noout -text

該命令和 SCTs 有關(guān)的輸出如下：

CT Precertificate SCTs: 
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
                    6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
        Timestamp : Apr 18 09:03:52.458 2018 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256
                    30:45:02:20:51:E8:EB:BF:7E:0A:BA:F8:6D:94:C2:3A:
                    B6:4B:02:B5:24:F3:7B:A8:7A:B9:C1:C2:D7:02:2A:F1:
                    7A:92:7D:5B:02:21:00:D3:7F:51:B1:87:E5:A8:9A:F2:
                    24:43:10:65:76:31:26:25:2C:9A:1C:4E:DB:4F:F0:EF:
                    E4:25:82:4E:5D:16:7F
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : 55:81:D4:C2:16:90:36:01:4A:EA:0B:9B:57:3C:53:F0:
                    C0:E4:38:78:70:25:08:17:2F:A3:AA:1D:07:13:D3:0C
        Timestamp : Apr 18 09:03:52.480 2018 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256
                    30:44:02:20:5F:DE:E5:DD:AC:FE:85:99:A7:22:67:28:
                    86:0E:2C:81:62:F6:2F:66:ED:18:AC:93:E2:99:6F:76:
                    5D:4B:7C:F3:02:20:6E:1F:66:EB:A0:E9:09:D9:B3:F0:
                    70:69:90:D6:30:5A:E0:BD:ED:F8:6F:8C:71:65:CF:A7:
                    5B:8E:56:D3:C8:7D

從輸出可以看出窿克，由兩個(gè) Certificate Logs 提供 SCTs 信息骏庸。

（2）OCSP 封套的方式

CA 機(jī)構(gòu)可以使用 OCSP 協(xié)議的方式提供 SCT 信息，這屬于一種異步提供 SCT 信息的方式年叮，OCSP 協(xié)議主要提供證書吊銷信息敞恋，相比 CRL 來說，OCSP 擴(kuò)展性更好谋右，也就是說 CA 機(jī)構(gòu)的 OCSP 服務(wù)也可以包含 SCTs 信息硬猫。

從操作性上看，網(wǎng)站部署者如果想支持 CT改执，需要部署 OCSP 封套服務(wù)（原生 OCSP 服務(wù)有很多的缺點(diǎn)）啸蜜，當(dāng)然現(xiàn)在 OCSP 封套服務(wù)已經(jīng)很普及了。

可以尋找一個(gè)支持 OCSP 封套的網(wǎng)站（且包含 SCTs 信息）辈挂，檢查 OCSP 響應(yīng)中的 SCT 信息衬横，運(yùn)行以下命令：

$ openssl s_client -connect sslanalyzer.comodoca.com:443 -status </dev/null

關(guān)鍵輸出如下：

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: D34EC319BA5859D11C60B76153473BA7778FF88A
    Produced At: Jun 16 12:02:50 2018 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: D5C398C21A2572B0EA4272663FFBD90522DFE38D
      Issuer Key Hash: D34EC319BA5859D11C60B76153473BA7778FF88A
      Serial Number: 9E487D65A15ACAA085C2DEE46DD1B0FC
    Cert Status: good
    This Update: Jun 16 12:02:50 2018 GMT
    Next Update: Jun 23 12:02:50 2018 GMT
        Response Single Extensions:
            CT Certificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                                3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
                    Timestamp : Mar  6 16:12:54.862 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:0B:2D:26:5F:B4:04:EC:95:75:F1:40:DE:
                                16:8F:73:BA:44:39:B6:C2:F5:FB:F2:ED:F9:9B:6D:20:
                                CA:2C:33:E6:02:20:5F:41:C9:18:14:8D:E4:1A:72:7F:
                                4E:B1:67:A7:EA:E9:8F:90:6D:F9:7F:F6:80:D6:96:03:
                                D5:05:7D:C7:44:B0
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:
                                46:76:B9:BC:99:11:5C:C0:EF:94:98:55:D6:89:D0:DD
                    Timestamp : Mar  6 16:12:54.280 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:3D:F3:DD:77:1F:4A:73:4B:F5:88:95:07:
                                BD:37:EC:D9:E3:80:1F:7E:48:AC:ED:79:FE:90:FC:AA:
                                1F:2B:11:A1:02:20:46:7E:8C:CB:7B:FB:15:EC:D4:04:
                                E6:93:01:31:57:FF:FA:A8:E2:FF:C1:DB:83:CF:90:49:
                                0C:FC:4B:A9:2C:41

（3）TLS 擴(kuò)展方式獲取 SCT

如果前兩種獲取 SCT 的方式都不能用，可以采用 signed_certificate_timestamp TLS/SSL 協(xié)議擴(kuò)展獲取 SCT终蒂。

這種方式需要網(wǎng)站部署者自行向 Certificate Log 服務(wù)申請(qǐng) SCTs 信息（如果 CA 機(jī)構(gòu)不能支持 SCT蜂林，那么只能采取這種方式），大概的步驟如下：

• 服務(wù)器實(shí)體向 Certificate Logs 服務(wù)申請(qǐng) SCT 信息拇泣。
• 配置 TLS/SSL 協(xié)議擴(kuò)展支持 SCT 信息噪叙，比如 Nginx nginx-ct 模塊就能支持 signed_certificate_timestamp TLS/SSL 協(xié)議擴(kuò)展 。

那么客戶端如何通過 TLS 擴(kuò)展的方式獲取 SCT 信息呢霉翔，步驟如下：

• 客戶端向服務(wù)器發(fā)送 HTTPS 協(xié)議請(qǐng)求睁蕾。
• 客戶端請(qǐng)求的 Client Hello 消息包含 signed_certificate_timestamp TLS/SSL 協(xié)議擴(kuò)展，請(qǐng)求服務(wù)器返回 SCT 信息债朵。
• 服務(wù)器接收到 Client Hello 消息后子眶，在 Server Hello 消息中返回 SCT 信息。
• 客戶端接收到 SCT 信息后序芦，代表該證書是一個(gè)有效的證書臭杰，是經(jīng)過審計(jì)的。

使用 Wireshark 工具抓取 HTTPS 協(xié)議消息谚中，在 Client Hello 消息中可以看到 signed_certificate_timestamp TLS/SSL 協(xié)議擴(kuò)展渴杆，消息如下：

Extension: signed_certificate_timestamp (len=0)
    Type: signed_certificate_timestamp (18)
    Length: 0

服務(wù)器 Server Hello 消息會(huì)響應(yīng) signed_certificate_timestamp TLS/SSL 協(xié)議擴(kuò)展射窒，響應(yīng)信息如下：

Extension: signed_certificate_timestamp (len=243)
    Type: signed_certificate_timestamp (18)
    Length: 243
    Serialized SCT List Length: 241
    Signed Certificate Timestamp (Google 'Pilot' log)
        Serialized SCT Length: 119
        SCT Version: 0
        Log ID: a4b90990b418581487bb13a2cc67700a3c359804f91bdfb8...
        Timestamp: Dec 13, 2017 14:28:56.004000000 UTC
        Extensions length: 0
        Signature Hash Algorithm: 0x0403
        Signature Length: 72
        Signature: 3046022100b1ad781896f9659d2107a63a3221bc1dfc66e1...
    Signed Certificate Timestamp (Symantec log)
        Serialized SCT Length: 118
        SCT Version: 0
        Log ID: ddeb1d2b7a0d4fa6208b81ad8168707e2e8e9d01d55c888d...
        Timestamp: Dec 13, 2017 14:28:55.786000000 UTC
        Extensions length: 0
        Signature Hash Algorithm: 0x0403
        Signature Length: 71
        Signature: 3045022100a5f24b5025366f6d47f943dbb236b2ecceb0ea...

該響應(yīng)包含了兩個(gè) SCT 信息，分別是 Pilot 和 Symantec 提供的 Certificate Logs 服務(wù)将塑。至于 Nginx 如何配置脉顿，此處就不進(jìn)行描述了。

這種方式需要網(wǎng)站部署者做很多工作点寥，沒有特殊情況艾疟，建議不要采用。

CT 普及度

CT 是谷歌提出來的解決方案敢辩，在 Chrome 瀏覽器上做了很多的嘗試蔽莱，截止到今日，其普及程度越來越高了戚长，F(xiàn)irefox 也準(zhǔn)備開始校驗(yàn) SCT盗冷，但目前還沒有實(shí)施完。

如果想了解 Chrome 瀏覽器支持 CT 的情況同廉，可以訪問 chromium 的 ct-policy 倉庫仪糖，其中講解了在 Chrome 中校驗(yàn) CT 的策略。

• 從 2015年1月份開始迫肖，Chrome 要求所有的 EV 證書開始支持 CT锅劝。
• 從 2018年4月30號(hào)開始，Chrome 要求所有的證書支持 CT（2018年4月30號(hào)以后簽發(fā)的證書蟆湖，老的證書沒有該限制）故爵，如果訪問的網(wǎng)站包含 SCT，則在 TLS/SSL 協(xié)議握手階段就會(huì)失敗隅津。

對(duì)于 CT 來說诬垂，是否生效，取決于瀏覽器的處理策略伦仍，但從本質(zhì)上來說结窘，CA 機(jī)構(gòu)應(yīng)該提交證書簽發(fā)信息，讓證書簽發(fā)行為透明化呢铆。而且目前已經(jīng)證明晦鞋，CT 是具備可行性的一種技術(shù)解決方案。

那么在 Chrome 上如何讓用戶感知 CT 的存在呢棺克？在老的 Chrome 版本開發(fā)者工具上可以看到 CT 信息（較新版本的 Chrome 已經(jīng)去除，可見 CT 可以進(jìn)入生產(chǎn)階段了）线定。下圖描述 Chrome 42 版本處理 CT 的相關(guān)情況娜谊。

圖4：chrome-ct

如果你不了解網(wǎng)站用戶使用的瀏覽器（針對(duì) CT，目前其實(shí)就是 Chrome）斤讥，但又想了解客戶端處理 CT 是否遇到問題（應(yīng)對(duì) Chrome 硬性要求網(wǎng)站支持 CT 的期限）;或者從安全的角度考慮纱皆，強(qiáng)制希望客戶端瀏覽器校驗(yàn) SCTs湾趾，那么可以提前了解一個(gè)新的 HTTP 消息頭 Expect-CT。

如果你想了解網(wǎng)站 CT 支持情況派草，可以使用報(bào)告模式搀缠，比如：

Expect-CT: max-age=0, report-uri="https://www.simplehttps.com/ct/reportOnly"

如果瀏覽器在處理 SCTs 的時(shí)候遇到問題，會(huì)向 report-uri 屬性對(duì)應(yīng)的地址發(fā)送報(bào)告近迁，以便讓管理員了解詳細(xì)的信息艺普。max-age=0，表示每次訪問都處理 SCTs 信息鉴竭。

如果你向讓瀏覽器強(qiáng)制校驗(yàn) SCTs歧譬，可以使用 enforce 模式，比如：

Expect-CT: enforce max-age=30, report-uri="https://www.simplehttps.com/ct/reportOnly"

enforce 屬性表示強(qiáng)制讓瀏覽器校驗(yàn) SCTs搏存，max-age=30 表示在 30 秒內(nèi)緩存校驗(yàn)結(jié)果瑰步。

這個(gè)消息頭的詳細(xì)定義可以參考Expect-CT Extension for HTTP draft-ietf-httpbis-expect-ct-02，目前 Chrome 61 開始的版本已經(jīng)支持該特性璧眠，可以進(jìn)行相關(guān)測(cè)試缩焦。

作為全球最大的瀏覽器廠商，Chrome 在推進(jìn) CT 普及上做了很多工作责静，主流的收費(fèi) CA 機(jī)構(gòu)也逐漸支持 CT舌界，對(duì)于開發(fā)者來說，應(yīng)該校驗(yàn)下自己的證書或者網(wǎng)站是否支持 CT泰演，如果沒有呻拌，應(yīng)該快速行動(dòng)起來。