這是否調用「openssl s_client -connect」實際查詢OCSP響應者服務器以確認證書的當前有效性？

Question

我很好奇，調用一行openssl命令行界面是否有能力執行完整的OCSP驗證協議，例如，查詢鏈中的所有OCSP應答方服務器以確認證書的當前有效性。

要看看這可能是這樣，我指定的-CAfile選項爲/dev/null，希望將避免任何緩存的證書來代替查找的使用：作爲@pepo的答案解釋，服務器證書鏈被髮送在RFC 5246（在下文中更新更多細節）中指定的基本TLS1.2握手的一部分

# openssl s_client -CAfile /dev/null -connect www.equifaxsecurity2017.com:443 

這給了輸出：

CONNECTED(00000003) 
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority 
verify return:1 
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA 
verify return:1 
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3 
verify return:1 
depth=0 CN = www.equifaxsecurity2017.com 
verify return:1 
--- 
Certificate chain 
0 s:/CN=www.equifaxsecurity2017.com 
    i:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3 
1 s:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3 
    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 
--- 
Server certificate 
-----BEGIN CERTIFICATE----- 
<omitted> 
-----END CERTIFICATE----- 
subject=/CN=www.equifaxsecurity2017.com 
issuer=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3 
--- 
No client certificate CA names sent 
.... 

看起來好像openssl已經發現，在鏈中的所有三個環節沒有任何幫助從緩存文件，因此必須傳達在互聯網上與代理商（1）GeoTrust的DV SSL CA - G3，和（ 2）GeoTrust Global CA，建立連鎖。那是對的嗎？ 不！這是不正確的！

是否openssl也通過向三個OCSP響應者中的每一個發出適當的OCSP請求來驗證鏈？我也知道openssl ocsp ...可以與證書上的手動文本操作一起使用，一次執行一個鏈接執行OSCP驗證。但是，它看起來似乎是合理的，甚至更可取的openssl會被寫入到執行全OCSP驗證，這就是爲什麼我問）

UPDATE 2017年9月14日：

由於@pepo的回答「SSL服務器（如果配置正確）將發送證書鏈（根CA證書除外）「，我查了RFC 5246，發現第」7.4.2 Se rver證書」這解釋了的內容‘的TLS1.2握手的服務器證書’部分：

這是證書的序列（鏈）。發件人的
證書必須在列表中排在第一位。每個以下證書 必須直接證明前面的證書。由於證書 驗證要求根密鑰是獨立分發的，因此可以從鏈中省略指定根證書 權限的自簽名證書，前提條件是遠程端必須已經擁有它才能驗證它 任何情況。

此外，由於@西葫蘆的有關-crl_check_all選項答案，我想這一點，得到了以下的輸出：

CONNECTED(00000003) 
depth=0 CN = www.equifaxsecurity2017.com 
verify error:num=3:unable to get certificate CRL 
verify return:1 
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3 
verify error:num=3:unable to get certificate CRL 

它失敗，錯誤unable to get certificate CRL。事實證明，這並不重要，因爲所選網站已啓用OCSP裝訂。

如果不是-crl_check_all執行CRL檢查，我們反而 add the option -status 它要求OCSP裝訂，那麼下面的輸出被接收：

CONNECTED(00000003) 
<stuff omitted omitted> 
OCSP response: 
====================================== 
OCSP Response Data: 
    OCSP Response Status: successful (0x0) 
    Response Type: Basic OCSP Response 
    Version: 1 (0x0) 
    Responder Id: CE2C8B1E8BD2300FD1B15446E9B594254949321B 
    Produced At: Sep 10 11:12:45 2017 GMT 
    Responses: 
    Certificate ID: ... 
    Cert Status: good 
    This Update: Sep 10 11:12:45 2017 GMT 
    Next Update: Sep 17 11:12:45 2017 GMT 
    Signature Algorithm: sha1WithRSAEncryption 
<stuff omitted> 

這表明OCSP裝訂在服務器上啓用但是它似乎只對第一個（葉子）證書啓用，而不是對第二個證書啓用。 （無論如何，自簽名的第三份證書必須獨立驗證）。因此，要驗證第二個證書，必須使用CRL檢查或必須使用OCSP請求響應。由於CRL檢查未由此特定授權鏈啓用，僅留下OCSP請求響應。

由於@pepo的答覆，我明白好得多openssl之間的TLS1.2協議並且這些方法用於驗證授權的關係，（在歷史順序列出）：

• CRL（證書撤銷列表）檢查
• OSCP請求和響應
• OCSP裝訂

然而，一個新的問題也被提出：

• 關於OCSP-裝訂的「服務器證書」消息步驟中通過與鏈中的證書一起服務器發送響應 - 這有簽名信息（從下級別）需要驗證。這個簽名信息是否在openssl ... -status的處理過程中被實際驗證過？

更新：2017年9月15日

的安全問題的答案「？是的openssl ... -status加工過程中實際驗證了這個簽名信息」似乎是NO，根據本 answer 也@ dave_thompson_085的評論如下（他瀏覽了源代碼）。

它是否令人困惑？是!奇怪的是， 「OpenSSL食譜（feistyduck，IvanRistić）」 是 unusually unclear about this question, 顯示沒有明確的方式來驗證簽名，同時也沒有明確說明簽名是否已被驗證。與此相反，對於其他類型吊銷檢查的：

• CRL-checking
• and OCSP-request-response (find "submit OCSP request")

的「OpenSSL的食譜」顯示了明確的方法（配方）去額外的距離和手動完成驗證使用已由openssl產生的信息。推斷原因「OpenSSL Cookbok」不包含完整驗證訂閱OCSP響應的原因是因爲它不是必需的，這將是一個非常人爲的錯誤。

恕我直言，這將是非常負責任的OpenSSL（或任何類似的庫）的，包括頂層文件，在下列優先順序

• （1）解釋，即OpenSSL的不提供黑箱解決方案到TLS +授權，
• （2）解釋什麼限制了溶液它確實提供（例如，未經授權的TLS握手檢查）的一部分，
• （3）上用於組裝OpenSSL的組分配方文檔來完成 授權檢查方案。

誤區傳播變得非常容易。就在幾天前，我試圖編寫一個簡單的程序來從我的Linux Ubuntu PC發送通知郵件。標準的Python版本（包括版本2和版本3）包括一個SMTP和一個SSL庫「實施」TLS1.2。在10分鐘內，我可以編寫程序並在調試器中遍歷它。我可以看到python SSL庫對OpenSSL的handshake()函數的調用，並假定handshake()必須處理所有的授權檢查，這是基於假設在不包括授權檢查的情況下不會發布SSL庫和SMTP庫。奇怪的是，SSL庫中的調用代碼包含post-handshake()檢查以確保接收到的證書名稱與被調用服務器的名稱相匹配。 「如果handshake()已經處理了所有的簽名驗證等，爲什麼還要進行這樣的原始檢查呢？」我想。這種懷疑開始了剝離TLS安全洋蔥層次的旅程，我從此無法停止哭泣。

我不想嘗試重新發明輪子，這很可能是不穩定反正。但是，我似乎無法找到任何可用的輪子。然後去哪兒？

Answer 1

SSL服務器（如果配置正確地）將發送證書鏈（除了根CA證書）。你可以驗證它here。

Openssl沒有獲取這些證書，但它在啓動ssl連接時獲得了它們的服務。你可以閱讀更多有關的s_client.First行爲openssl documentation

我不知道它是否執行OCSP驗證，但我對此表示懷疑。恕我直言（基於The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors.），它完全不執行任何默認驗證，但至少可以使CRL通過指定參數-crl_check_all

openssl s_client -connect www.equifaxsecurity2017.com:443 -crl_check_all