從sslyze看TLS證書的點點滴滴

時間 2020-03-31

標籤 sslyze tls 證書點點滴滴简体版

原文原文鏈接

縱觀眼下，https已經深刻大街小巷，成爲網絡生活中不可或缺的一部分了。提到了https，咱們又不得不想到TLS（SSL），而提到了TLS，咱們又不得不提到一個讓人捉摸不透的東西：TLS證書。html

關於證書的原理，這裏就不展開了，簡言之，就是服務器讓客戶端放心，我就是你要找的那個，不信你看看那誰誰給開的介紹信。python

在平常使用或者開發中，咱們有時會不可避免地須要分析診斷TLS證書，而分析證書呢，有一款很是不錯的開源工具你應該不會錯過：sslyzegit

這篇文章旨在提綱挈領地跟你們一塊兒經過使用sslyze進行TLS證書分析診斷的結果，從而熟悉下證書診斷的點點滴滴的知識。證書相關的知識比較龐雜，說點點滴滴也有點寒酸，充其量只能是些皮毛，算是拋磚引玉吧。姑且先讓咱們順着sslyze的思路，邊走邊聊吧。github

1. 安裝及使用

sslyze是一個python項目，安裝使用比較容易：算法

pip install --upgrade sslyze

若是想使用它來進行對某個域名對應的證書進行診斷，好比說我想知道www.baidu.com這個域名對應的證書是否是合法。你們知道，證書是服務器傳給客戶端的，而在何時傳的呢，那是在TLS握手的時候傳的，而咱們知道TLS是創建在TCP之上的，要進行TLS握手，必須先有了TCP鏈接，而要進行TCP鏈接，必須知道五元組（源目地址、端口和協議），關於這個目的地址，就有文章可作了，萬一host這個證書是在不一樣的服務器上、對應於不一樣的ip呢？好比說，www.baidu.com這個域名對應了10個ip，我更新了證書了，可是我不肯定某個服務器ip對應的證書是否是跟其餘的同樣正確，那我可能須要對某個特定的ip進行診斷，讓sslyze告訴我，你去跟這個ip通訊，拿到它傳給你的證書，看看是否是正確。這時，須要這麼辦：編程

sslyze --certinfo www.baidu.com{36.152.44.96}

其中，36.152.44.96是對應於www.baidu.com的一個ip。json

至於其輸出是什麼樣，咱們一會再說。windows

2. 輸出解析

咱們一般使用sslyze時，可能會用到兩種輸出。一種是通常的命令行輸出，其優勢是，簡潔、可讀性好。另一種呢，是JSON輸出，這種輸出格式機器友好，便於編程解析，所以也不可或缺。瀏覽器

原本呢，兩種輸出常理之中應該僅僅是格式差別，結果應該是換湯不換藥吧。但是，sslyze的這兩種輸出內容還真是不同，並且差異還不小，雖然夠不上互補，但也足以讓初學者難於一一對應上。因此咱們還得分別說道說道。安全

須要首先說明的是，咱們如下的輸出是基於sslyze版本2.1.4，而openssl版本是2.8.3.

2.1 命令行文本輸出

在上文中，咱們已經說起了這個命令，這裏重複下：

sslyze --certinfo www.baidu.com{36.152.44.96}

其輸出以下：

 1  AVAILABLE PLUGINS
 2  -----------------
 3 
 4  SessionRenegotiationPlugin 5  OpenSslCipherSuitesPlugin 6  FallbackScsvPlugin 7  CertificateInfoPlugin 8  HeartbleedPlugin 9  SessionResumptionPlugin 10  EarlyDataPlugin 11  CompressionPlugin 12  OpenSslCcsInjectionPlugin 13  RobotPlugin 14  HttpHeadersPlugin 15 16 17 18  CHECKING HOST(S) AVAILABILITY 19 ----------------------------- 20 21 www.baidu.com:443 => 36.152.44.96 22 23 24 25 26 SCAN RESULTS FOR WWW.BAIDU.COM:443 - 36.152.44.96 27 ------------------------------------------------- 28 29 * Certificate Information: 30  Content 31  SHA1 Fingerprint: d1f6323db6f2ec81e7023690f49b2d91e0c3993a 32  Common Name: baidu.com 33 Issuer: GlobalSign Organization Validation CA - SHA256 - G2 34 Serial Number: 13905183944940287882518820211 35 Not Before: 2019-05-09 01:22:02 36 Not After: 2020-06-25 05:31:02 37  Signature Algorithm: sha256 38  Public Key Algorithm: RSA 39 Key Size: 2048 40 Exponent: 65537 (0x10001) 41 DNS Subject Alternative Names: ['baidu.com', 'click.hm.baidu.com', 'cm.pos.baidu.com', 'log.hm.baidu.com', 'update.pan.baidu.com', 'wn.pos.baidu.com', '*.91.com', '*.aipage.cn', '*.aipage.com', '*.apollo.auto', '*.baidu.com', '*.baidubce.com', '*.baiducontent.com', '*.baidupcs.com', '*.baidustatic.com', '*.baifae.com', '*.baifubao.com', '*.bce.baidu.com', '*.bcehost.com', '*.bdimg.com', '*.bdstatic.com', '*.bdtjrcv.com', '*.bj.baidubce.com', '*.chuanke.com', '*.dlnel.com', '*.dlnel.org', '*.dueros.baidu.com', '*.eyun.baidu.com', '*.fanyi.baidu.com', '*.gz.baidubce.com', '*.hao123.baidu.com', '*.hao123.com', '*.hao222.com', '*.im.baidu.com', '*.map.baidu.com', '*.mbd.baidu.com', '*.mipcdn.com', '*.news.baidu.com', '*.nuomi.com', '*.safe.baidu.com', '*.smartapps.cn', '*.ssl2.duapps.com', '*.su.baidu.com', '*.trustgo.com', '*.xueshu.baidu.com', 'apollo.auto', 'baifae.com', 'baifubao.com', 'dwz.cn', 'mct.y.nuomi.com', 'www.baidu.cn', 'www.baidu.com.cn'] 42 43  Trust 44 Hostname Validation: OK - Certificate matches www.baidu.com 45 Android CA Store (9.0.0_r9): OK - Certificate is trusted 46 Apple CA Store (iOS 13, iPadOS 13, macOS 10.15, watchOS 6, and tvOS 13):OK - Certificate is trusted 47 Java CA Store (jdk-13.0.2): OK - Certificate is trusted 48 Mozilla CA Store (2019-11-28): OK - Certificate is trusted 49 Windows CA Store (2019-11-10): OK - Certificate is trusted 50 Symantec 2018 Deprecation: WARNING: Certificate distrusted by Google and Mozilla on September 2018 51 Received Chain: baidu.com --> GlobalSign Organization Validation CA - SHA256 - G2 52 Verified Chain: baidu.com --> GlobalSign Organization Validation CA - SHA256 - G2 --> GlobalSign Root CA 53 Received Chain Contains Anchor: OK - Anchor certificate not sent 54 Received Chain Order: OK - Order is valid 55 Verified Chain contains SHA1: OK - No SHA1-signed certificate in the verified certificate chain 56 57  Extensions 58 OCSP Must-Staple: NOT SUPPORTED - Extension not found 59 Certificate Transparency: WARNING - Only 2 SCTs included but Google recommends 3 or more 60 61  OCSP Stapling 62 NOT SUPPORTED - Server did not send back an OCSP response 63 64 65 SCAN COMPLETED IN 0.85 S 66 ------------------------

1-14行，是sslyze本身可使用的一些plugin，若是不打算本身enable或者編寫plugin的話，咱們暫且先略過。

18-21行，表示當前診斷域名www.baidu.com對應的ip是36.152.44.96，這也沒有什麼可爭議的，由於是咱們預先指定的，假如咱們不指定，這裏或許就有意義了，會給你看經過DNS解析出來的ip地址，即當前咱們診斷的是哪一個ip。

29行向下的Certificate Information，纔是咱們想知道的東西，讓咱們來一一查看。

Contents

位於輸出結果的30至41行，主要告訴咱們關於證書自己的一些事情，咱們要知道，全部的公開的證書都是由一個權威的機構給簽發的，這個機構叫CA（certificate authority），它是一個公開的第三方，是具備一些公信力的第三方機構。

你們知道，咱們的系統或者瀏覽器在出廠的時候，就內置了一些CA，好比說我用的MacBook，剛到手就已經爲我內置了一系列世界上公認的一些CA了，這樣能夠避免你從一些不安全的地方來獲取他們，由於，這些CA是全部信任的原點，他們不安全，那麼全部的TLS就都不安全了。這些CA的做用就是來驗證，這些證書是否是本身簽發或者信任的。若是一個CA，好比說GlobalSign Organization Validation CA告訴你說，沒問題的，這個是我簽發的，你就放心好了。那你就能夠相信它了。

既然內置了這麼些CA，咱們跟服務端TLS通訊前，收到了證書，怎麼知道找哪一個CA來驗證呢？總不至於把全部的CA都驗證一遍吧？不至於，那樣實在過低效了，你收到的每一個證書都會直接告訴你，你應該找誰去驗證，在哪裏告訴的呢？33行有個Issuer字段。咱們這裏是GlobalSign Organization Validation CA - SHA256 - G2，告訴咱們是GlobalSign的CA簽發的，SHA256簽名的，那後面的G2是什麼意思呢？"G"表明Generation，若是這個CA想換一個chain的話，那直接變成G二、G3就行了。

咱們還能夠看到這個證書只有在2019-05-09 01:22:02至2020-06-25 05:31:02期間纔是合法的，想要僞造出非法證書也很容易，只要把你的系統時間改到這個以外就能夠了。公鑰是RSA的，簽名是SHA256的。

最有意思的是最下面那個DNS Subject Alternative Names，能夠看到這麼多的域名使用着和"www.baidu.com"同樣的證書。

Hostname Validation

這個是實際上是openssl內置的一個基礎功能，目的是驗證證書裏說的hostname是否是跟你所請求的一致。好比你或者了一個證書A，是合法的證書，可是它不是baidu.com的證書，一下就被識破了，你不能用它來和baidu.com的服務器通訊。

Android/Apple/Java/Mozilla CA Store

咱們前文也說過，任何一個公開的平臺或者瀏覽器，它都必須提供一系列CA集合，用來方便絕大多數通常用戶安全鏈接網絡。這樣，每個平臺本身的CA集合就或多或少地跟其餘的平臺在這個CA集合上有了差別，這裏sslyze就模擬了這些系統或者瀏覽器的CA集合，來驗證假設用戶在這些平臺上，經過這些系統或者平臺自帶的CA集合，是否是獲得證書被信任的結果。

Symantec 2018 Deprecation

我見過的每個證書驗證在這項都會出現這麼一個WARNING，所以，能夠判定這項你就不要擔憂了吧。其實，這一項涉及了一個很是狗血的故事，Symantec本來是一個比較大
的CA供應商，在2018年的時候，Google對Symantec簽發證書的方式已經很是不滿到忍無可忍了，因而乎，發佈了一個聲明，決定到2018年某個時間點，就在本身的瀏覽器上斷定Symantec的證書都是不合法的，隨後獲得了Mozilla的響應，而後Symantec就比較被動了，你簽發的證書已經遭到了兩大瀏覽器的抵制了嘛，而後無奈之下，只得把本身
的簽發證書這塊業務給賣掉了，表示今後金盆洗手，不玩這個了。你如今見到的Symantec證書已是另一個公司在運營的了，並且，你也不用擔憂，由於2018年早就過去了，原來那個Symantic簽發的被認定爲非法的證書要麼整改了要麼已通過期了，因此呢，任何健在的證書你都不用擔憂這個問題啦。

Received/Verified Chain

要了解這兩個Chain，咱們先得了解什麼是信任鏈（Trust Chain）。咱們剛也提到過，這世間的著名的頂級CA也就那麼幾家，而這世間的證書可謂難以計數，若是每個證書的申請和維護都由這幾家頂級CA來完成的話，頂級CA可真是煩透了。這時候，分治的思想就來了，頂級CA那是大咖啊，他認證了一些小弟，若是誰要找他，他會說大事找我行，小事就不要找我了，找個人小弟去，跟找我效果差很少。這裏他的這些小弟都是他給背書的，信用天然沒的說，你信任了頂級CA，也就天然信任了他的小弟。這些小弟也叫中間證書（Intermediate Certificate），提供了一個引導用戶到頂級CA的路徑，並且小弟可能還不止一級，小弟還能夠信任小小弟，這就造成了一個鏈，這個鏈叫作「信任鏈」。

這具體是怎麼操做的呢？咱們來看下圖：

用戶在訪問baidu.com的時候，首先經過DNS解析拿到某個服務器IP，鏈接到某個服務器，在TLS握手過程當中，首先得到baidu.com的證書，用戶一看它的Issuer，是GlobalSign Organization Validation CA - SHA256 - G2，而這也不是已知的頂級CA，因而又問服務器要GlobalSign Organization Validation CA - SHA256 - G2證書(實際是跟baidu.com證書一塊兒發送給用戶的，這裏只是爲了讓你們容易理解一點)，再看它的Issuer，一看是GlobalSign Root CA，這是他知道的一個頂級CA，那就到此爲止了，沒必要再麻煩服務器了。再回頭看下，咱們剛纔接收到了幾回證書？一共是兩次，baidu.com -> GlobalSign Organization Validation CA - SHA256 - G2，兩次到達了頂級CA，這個鏈就是所謂的Received Chain。因而可知，服務器不光要保存baidu.com這種域名對應的證書，還要保存其中間證書，由於用戶也須要從它這裏得到。

證書都已經齊活了，那用來幹嗎呢？那天然是用來驗證了。首先仍是驗證baidu.com的有效性，從它的Issuer字段知道，它是由GlobalSign Organization Validation CA - SHA256 - G2簽發的，那咱們就拿到GlobalSign Organization Validation CA - SHA256 - G2證書，獲取它的公鑰，而後利用公鑰算法，來驗證baidu.com的簽名，因爲公私鑰算法的嚴密性，簽名是很是難以僞造的，若是咱們驗證出了簽名是正確的，就能夠認爲該證書是GlobalSign Organization Validation CA - SHA256 - G2給簽發的。可是這個GlobalSign Organization Validation CA - SHA256 - G2是剛纔你服務器那裏得到的，這不等於你本身證實你本身嗎，不要緊，你能夠驗證它的Issuer，也就是GlobalSign Root CA，這個是頂級CA，本地有它的證書，那拿過來照着上面的作法來一通，就能夠知道GlobalSign Organization Validation CA - SHA256 - G2是否是GlobalSign Root CA 給簽發的了，驗證經過了，那證實就是GlobalSign Root CA簽發了GlobalSign Organization Validation CA - SHA256 - G2，而GlobalSign Organization Validation CA - SHA256 - G2又簽發了baidu.com，從而證實你拿到的baidu.com是有效的。剛剛咱們走完了一個鏈，就是baidu.com -> GlobalSign Organization Validation CA - SHA256 - G2 -> GlobalSign Root CA，爲了驗證而爲之的，因此就是Verifed Chain了。

以上過程比較簡化和粗糙，若是可以說明白了，並且還不暈乎的話，那麼咱們就來看看一個實際的並且更加詳實的證書解析結果吧。在本地運行以下openssl命令：

openssl s_client -showcerts -connect www.baidu.com:443

輸出結果以下：

 1 CONNECTED(00000006)
 2 depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
 3 verify return:1
 4 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
 5 verify return:1
 6 depth=0 C = CN, ST = beijing, L = beijing, OU = service operation department, O = "Beijing Baidu Netcom Science Technology Co., Ltd", CN = baidu.com
 7 verify return:1
 8 ---
 9 Certificate chain
10  0 s:/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com
11    i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
12 -----BEGIN CERTIFICATE-----
13 MIIJrzCCCJegAwIBAgIMLO4ZPBiCeOo+Q3VzMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
14 BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
15 // ... 省略若干行...
16 oZ0B5qslIww7JAJAWCT/NAKLlGEQaC+2gOPQX0oKpwLSwJg+HegCyCdxJrKoh7bb
17 nRBHS8ITYjTG0Dw5CTklj/6i9PP735snPfzQKOht3N0X0x8=
18 -----END CERTIFICATE-----
19  1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
20    i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
21 -----BEGIN CERTIFICATE-----
22 MIIEaTCCA1GgAwIBAgILBAAAAAABRE7wQkcwDQYJKoZIhvcNAQELBQAwVzELMAkG
23 A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
24 b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
25 // ... 省略若干行...
26 K1pp74P1S8SqtCr4fKGxhZSM9AyHDPSsQPhZSZg=
27 -----END CERTIFICATE-----
28 ---
29 Server certificate
30 subject=/C=CN/ST=beijing/L=beijing/OU=service operation department/O=Beijing Baidu Netcom Science Technology Co., Ltd/CN=baidu.com
31 issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
32 ---
33 No client certificate CA names sent
34 Server Temp Key: ECDH, P-256, 256 bits
35 ---
36 SSL handshake has read 4265 bytes and written 322 bytes
37 ---
38 New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
39 Server public key is 2048 bit
40 Secure Renegotiation IS supported
41 Compression: NONE
42 Expansion: NONE
43 No ALPN negotiated
44 SSL-Session:
45     Protocol  : TLSv1.2
46     Cipher    : ECDHE-RSA-AES128-GCM-SHA256
47     Session-ID: 42FD0DF68EDA274407EC33AD8B9E98177D10CBE8DA1F07E03F6E03A0CDB58FC3
48     Session-ID-ctx:
49     Master-Key: F863A3EB7527D0EC1F752C26CF8670749F7C02BFE451584E16CAAED22A414374DA5F06A24434CA1B7B69781D7C14AB7D
50     TLS session ticket:
51     0000 - b9 e4 f4 ab 7d 8a 32 7d-f3 56 1b 04 b6 62 89 f9   ....}.2}.V...b..
52     0010 - ff c0 b8 14 dd 2e 87 94-6c 16 c6 28 5a bd a1 e0   ........l..(Z...
53     0020 - ae c7 20 c8 7b c5 10 57-f5 6d 7f 40 a9 75 ed 7b   .. .{..W.m.@.u.{
54     0030 - cd 3d 3e 1b c0 c5 86 c7-24 55 ff d4 2c b2 58 e1   .=>.....$U..,.X.
55     0040 - 48 7f b9 e7 b5 c5 e9 0e-3b df 44 ce 5e 1c 03 9f   H.......;.D.^...
56     0050 - 92 a1 9a ec 93 d1 bd f3-f1 89 81 a7 d0 f4 ce 38   ...............8
57     0060 - 4d 87 17 99 d9 d4 eb 4c-46 75 8f e2 4b 62 03 18   M......LFu..Kb..
58     0070 - 63 86 83 e9 d6 54 0b ea-b8 ea bf 87 cc e6 4b c6   c....T........K.
59     0080 - 34 19 0f b0 25 2c a2 66-a4 5f 99 90 bd 61 00 74   4...%,.f._...a.t
60     0090 - 3e 45 f7 92 e9 2e f9 6c-12 c1 35 8e 4f 3c dd 7a   >E.....l..5.O<.z
61 
62     Start Time: 1585465282
63     Timeout   : 7200 (sec)
64     Verify return code: 0 (ok)
65 ---
66 closed

看看以上openssl輸出結果的第9行如下，Certificate chain那裏，能夠看到咱們這裏從服務器端接受到了兩個證書，咱們應當注意到如下幾點：

證書0的名字（Subject）是baidu.com（CN）, 簽發者（Issuer）是GlobalSign Organization Validation CA - SHA256 - G2
證書1的名字是證書0的簽發者，其簽發者是GlobalSign Root CA
沒有收到GlobalSign Root CA的證書
Received Chain Contains Anchor

這裏所謂的包含Anchor，實際上是服務器端傳遞給客戶端的證書中，包含了根證書。這是不容許的，若是包含了根證書，那會是怎麼樣，根證書是自簽名的，也就是它是能夠本身驗證本身的，並且是用你服務器傳過來的驗證，那這還有什麼驗證的價值呢？因此，看到了這個，必定是證書出了問題了，告訴證書管理員，把Chain中的根證書給去掉，根證書客戶端那裏有的，用不着麻煩服務器。

Received Chain Order

若是理解了 Received/Verified Chain中所說的，那這裏就很容易理解了。就是告訴你接收到的Chain中的順序不對了。咱們先不說不對的順序是什麼，咱們先說說什麼是對的吧：

首先是域名對應的證書
其次是中間證書
前一個證書的Issuer必然對應後一個證書的Subject
最後一個證書的Issuer必然是某個Root CA

而後咱們來探討一種不對的狀況，就是，若是我服務器端處於某種目的，須要準備多個Certificate Path，即最終的Root CA是多個。假設以上baidu.com的例子，如今的Root CA是GlobalSign Root CA，假如服務器那邊還想爲本地沒有這個Root CA的用戶作點什麼，他想加一個好比說Baltimore CyberTrust Root，這樣用戶只要擁有兩個CA中的一個就會驗證成功。而咱們知道中間證書的做用是造成一個Chain來鏈接域名證書和Root CA的，那麼這樣就會造成兩條路徑，可能接受到了兩個不一樣的中間證書，這樣是合理的，可是卻違背了咱們以上說的那個被指望的順序了，即兩個中間證書中的前一個證書的Issuer不對應後一個的Subject，於是會被斷定爲"Certificate chain out of order!".

Verified Chain contains SHA1

以上咱們已經知道，證書之間是經過「簽名」來構建這個信任鏈的。於是，「簽名」是這個信任鏈安全的核心，而「簽名」一個證書，則須要簽發者擁有一個絕密的只有本身才能知道的私鑰和一個公開的、用來驗證簽名正確性的私鑰，還須要一個單向哈希算法，這樣用本身的公鑰和須要簽名的內容經過這個哈希算法得出一個簽名，任何人能夠經過公開的公鑰要驗證，從而肯定這個證書是否是他簽發的。剛剛提到這個哈希算法的單向性是很是重要的，由於，若是很是容易地經過簽名和公鑰來推算出這個私鑰的話，那就能夠任意僞造證書了。相比較而言，SHA1就是這種哈希算法中比較弱的了，而SHA256等相對比較強，難以攻破。咱們再來看這個檢查項，它表示在驗證證書的過程當中，是否包含了SHA1來簽發的證書，若是有，證實這個信任鏈是不夠安全的。

OCSP Must-Staple

要理解這個，咱們首先要理解OCSP。OCSP即Online Certificate Status Protocol，這個是用來幹嘛的呢，還得從歷史提及。話說，自有TLS證書的時候，就有了一個問題，就是萬一某個原本合法的證書泄露了(Leak)，變得不安全了，這個證書的全部者，就是使用這個TLS證書來跟客戶端打交道的那些網站等服務器全部者，他們所要作的第一件事就是通知這個證書的簽發機構，幫我吊銷這個證書吧，省得不法分子正在冒充他跟客戶端通訊。證書的簽發機構（CA）就會標記這個證書被吊銷了（Revoke）。客戶端怎麼知道哪些證書被吊銷了呢？這時，CA提供一個機制，就是按期把全部被他吊銷的證書打包，而後客戶端按期下載，當客戶端下次拿到一個證書後，就會跟這個吊銷的集合進行比對，來確認證書是否被吊銷。問題來了，按期下載，太頻繁吧，客戶端嫌麻煩，不頻繁吧，這容易漏掉某個剛剛被吊銷的，並且，被吊銷的證書天天有千千萬，這些證書原來對應的網站可能用戶絕大多數都訪問不到，這低效性可見一斑。怎麼辦呢？可能你已經想到改進措施了，就是用戶每次拿到一個證書後，本身到這個CA去驗證一下，看看有沒有被吊銷，這就造成了OCSP，這樣確實可以避免了用戶下載過多沒有用的證書，也避免了由於時效性問題致使的把被新吊銷的誤判。但是，這樣也不是沒有成本的，用戶每次TLS會話都須要訪問CA來次檢查，對用戶過低效，對CA服務器那邊也是壓力，並且用戶看了什麼網站都須要向CA彙報一次，那也就等於CA能夠一直監控用戶的網絡行爲，這樣用戶也是不開心的。那這樣改進下，咱也不用客戶去檢查了，把這個負擔轉嫁給服務器吧，服務器每隔一段時間都去CA那邊報道下，讓他給像簽發證書同樣簽發一個證實，表示這個證書沒有過時，每次客戶端來訪問的時候，服務器就把這個證實連同證書一塊兒發給客戶端，客戶端拿CA的公鑰輕鬆一驗證就知道真假，也不用去請求CA服務器了，服務器這邊也只要隔一段時間纔去CA請求一次這個證實就能保證用戶拿到的證書都不過時的，是不就是皆大歡喜。這裏的這個證實咱們叫作Staple，這個TLS證書的擴展功能就是OCSP Must-Staple。用戶在TLS握手的時候，看到這個標記了，就知道服務器傳過來的證書中包含了staple，那客戶端驗一下就能夠了。

Certificate Transparency

所謂Certificate Transparency，其實就是一個開放標準用以限制或者要求CA不會亂簽發證書，特別是對於一個域名相關的證書進行亂簽發，好比一個CA給baidu.com簽發了證書，若是他再給另一個組織簽發next.baidu.com，這可就亂套了，因此baidu.com的管理員須要有某種方法，來監控（或者某種意義上說是監督）這個CA，要按套路。爲了保證證書的透明度，證書界出了一個「正義聯盟」，它推出了一個Certificate Transparency Project，主要達成如下目的：

讓一個CA不可能或者說很難簽發一個域名下的證書而不被這個域名的管理員發現
提供一個審計和監控平臺，這樣域名管理員和CA就能夠輕易地發現某個證書被錯誤地或者惡意地簽發了
方便地告訴用戶，某個域名被錯誤地或者惡意地使用了

它是如何保證工做的呢？這個項目的核心就是使用一個append-only log系統，來保存全部的證書記錄，每一個證書在簽發的時候必定要向這個系統提交這個證書的記錄，因此每一個證書籤發成功的時候返回一個記錄在證書中回執，就是Signed Certificate Timestamp (SCT)，這是一個憑證，表示這個log系統已經接受了這個證書的信息了。

Google的Chrome做爲這方便的先鋒，被業界承認，他倡導了CA的一些規範，總結下來主要有以下幾點：

Certificate Extension：證書中要包含SCT
TLS Extension：SCT信息經過一個TLS擴展字段signed_certificate_timestamp包含在TLS握手中
OCSP Stapling：CA必須支持域管理者使用OCSP Stapling

假如這個證書缺乏其中一項或者幾項的功能，你或許會看到相似這樣的信息「WARNING - Only 2 SCTs included but Google recommends 3 or more」。

OCSP Stapling

這一項在上面OCSP Must-Staple中已經介紹過了，OCSP Must-Staple事實上是證書的一個擴展，而OCSP Stapling是服務器的一個功能，便是不是在客戶端向服務器發出stapled OCSP請求的時候給出相應的迴應。

2.2 JSON輸出

咱們先前也提到過，JSON輸出便於代碼解析，所以在sslyze這個工具使用中場景甚至多餘命令行輸出。對應於上面的例子，這裏咱們用JSON輸出一遍：

sslyze --certinfo --json_out=- www.baidu.com

其結果以下所示（注：這裏結果很是詳細，但也很是冗長，爲了避免影響觀看，對某些內容作了摺疊，請你們注意行號）：

剔除一些一眼就能知道的內容，上面的輸出結果中，咱們能夠看到主要有certinfo和server_info兩塊內容，而其中server_info又都是server自己的一些信息或者再TLS握手中拿到的信息，與證書自己關聯不大，於是，咱們仍是把注意力集中在certinfo上吧。

leaf_certificate_has_must_staple_extension

跟命令行輸出結果中「OCSP Must-Staple」對應，表示證書中是否含有OCSP must-staple擴展。

leaf_certificate_is_ev

咱們能遇到的證書能夠分爲三類，即Domain Validated (DV), Organization Validated (OV)和Extended Validated (EV)，咱們先對比下他們的差別：

- DV:
  - 單個域名級別的認證
  - 便宜
- OV:
  - CA在簽發這個證書的時候驗證公司信息
  - 安全性比DV高
  - 比DV稍貴
- EV：
  - 比上面兩種安全性都高
  - 用戶鍵入瀏覽器時會顯示公司名，且顯示爲綠色（看瀏覽器）
  - 貴

對比了以上以後，不用我說了吧，EV是對用戶最好的，對服務提供商而言，除了貴，其餘都好。

leaf_certificate_signed_certificate_timestamps_count

關於Signed Certificate Timestamp (SCT)上面已經介紹過了，這裏能夠認爲跟上文所述的「Certificate Transparency」相似，表示含有多少個SCT檢查項。

leaf_certificate_subject_matches_hostname

即域名跟證書是否匹配，跟上文的「Hostname Validation」相相似。

ocsp_response/ocsp_response_is_trusted/ocsp_response_status

用戶要求服務器發送Stapled OCSP時，服務器的返回，以及本地驗證結果如何，具體道理在命令行輸出「OCSP Stapling」中咱們說起過，他們是相似的。

path_validation_error_list/path_validation_result_list

在命令行輸出分析中，咱們也說起過，在不一樣的平臺上Root CA的集合可能不一樣，而從域名證書 -> 中間證書 -> Root CA 的路徑可能會有差異。「path_validation」實際就是模擬各個平臺或者系統對其驗證的路徑的遍歷結果，若是驗證失敗了，就會追加到「path_validation_error_list」中，若是成功了，天然會在「path_validation_result_list」中。