1

之前處理過不少 TLS 憑證無效問題，這回遇上一枚絕對新鮮的罕見茶包。

狀況如上圖所示(純屬模擬示意，非實際狀況)，瀏覽器警示網站不安全，檢視憑證信任鏈，根憑證(TWCA Global Root CA)、中繼憑證(TWCA Global EVSSL Certification Authority)跟網站憑證三者名稱及有效期限都沒問題，網站憑證被標註紅 X 標示顯示無效/不安全，網站憑證錯誤訊息為：「這個憑證具有無效的數位簽章 / This certificate has an invalid digital signature.」，另外網站憑證也出現「無法保證這個憑證的完整性。憑證可能已經損毁或被竄改」的警示。

網站憑證剛換新，前幾天生效還熱騰騰，一年後才到期，主體名稱也與網站 Domain Name www.xxx.tw 相符，看不出瑕疵。

改用 openssl s_client -connnect www.xxx.tw:443 檢查，得到更詳細的錯誤訊息：(此處借用 TWCA 憑證鏈結構舉例，非實際遇到狀況)

CONNECTED(00000134)
depth=0 C = TW, ST = Taiwan, L = Taipei, O = "XXX Company", CN = www.xxx.tw
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = TW, ST = Taiwan, L = Taipei, O = "XXX Company", CN = www.xxx.tw
verify eror:num=21:unable to verify the first certificate
verify return:1
---
Cerificate chain
 0 s:C = TW, ST = Taiwan, L = Taipei, O = "XXX Co.", CN = www.xxx.tw
   i:C = TW, O = TAIWAN-CA, OU = Global EVSSL Sub-CA, CN = TWCA Global EVSSL Certification Authority
 1 s:C = TW, O = TAIWAN-CA, OU = Global EVSSL Sub-CA, CN = TWCA Global EVSSL Certification Authority
   i:C = TW, O = TAIWAN-CA, OU = Root CA, CN = TWCA Global Root CA
 2 s:C = TW, O = TAIWAN-CA, OU = Root CA, CN = TWCA Global Root CA
   i:C = TW, O = TAIWAN-CA, OU = Root CA, CN = TWCA Root Certification Authority
...以下省略...

openssl 提供了兩條重要線索，網站憑證有兩則錯誤 unable to get local issuer certificate 跟 unable to verify the first certificate。

意思是 openssl 找不到網站憑證(depth 0, CN = www.xxx.tw)的簽發者憑證(depth 1, CN = TWCA Global EVSSL Certification Authority)，無法驗證第一張憑證(即網站憑證，depth 0, CN = www.xxx.tw)的有效性。但檢查網站傳回的憑證鏈(Certificate Chain)，網站、中繼 CA、Root CA 都有，且彼此銜接 depth 0 的 i (Issuer) 與 depth 1 的 s (Subject) 一致，depth 1 i == depth s，加上瀏覽器憑證檢視器確認中繼 CA 與 Root CA 憑證皆為有效狀態，為什麼說找不到中繼 CA 憑證無法驗證？

讓情況更加撲溯迷離的是，此一憑證無效問題僅出現在部分客戶端，有些顯示憑證無效的瀏覽器隔天問題自己消失，同時歸納不出什麼情況問題會被觸發，也無法解釋為什麼問題自己消失。

經過一番調查，採集到更多樣本，對照正常瀏覽器與異常瀏覽器看到的憑證差異，也訪談了相關人員，總算理出頭緒：

  1. 問題網站因舊憑證即將到期，稍早有更新 TLS 憑證
  2. 網站為 Web Farm 架構共兩台，並有做 Load Balance (故有些人會連到第一台、有些人連到的是第二台)
  3. 檢視正常與異常案例的三張憑證，發現 CN = TWCA Global EVSSL Certification Authority 這張中繼 CA 憑證有兩種版本，一張到期日為 2024 年，一張則到 2030。網站憑證剛換新，約一年後到期，而 Root CA 憑證則是 2030 到期。
  4. 請 OP 確認本次收到的憑證更新檔與 openssl 列出的三張一致，中繼 CA 憑證與 Root CA 憑證的到時日均為 2030 年(故 2024 到期的中繼 CA 憑證應是舊的)，依據憑證廠商操作手冊，三張憑證都要安裝在網站上

一瞬間，貌似見鬼的現象全有了合理解釋：

合理推論，Web Farm 其中一台網站漏裝了中繼 CA 憑證，導致其傳回舊的中繼 CA 憑證(2024 到期)，新舊中繼 CA 憑證由同一張 Root CA 憑證簽發，都在效期內。

出問題的客戶端連上的是漏裝 2030 中繼 CA 憑證的網站，收到的三張憑證中，網站跟 Root CA 憑證正確，但中繼 CA 憑證卻是 2024 舊版(疑問：IIS 比對不到指紋時會用 CN 相同的憑證替代？)，雖在效期內仍有效，但不是新版網站憑證的真正簽發者，於是出現「找不到憑證的簽發者憑證，無法驗證」錯誤。

Web Farm 其中一台有問題，被 Load Balance 分配到漏裝中繼 CA 憑證網站的客戶端便會遇到憑證失效，其餘客戶端則沒問題，隔陣子被 Load Balance 導向未漏裝網站後，客戶端則會記住 2030 中繼 CA 憑證，之後即使再連到漏裝網站，也能從快取或憑證儲存區找到正確中斷 CA 憑證完成驗證，不再出現憑證無效狀況。

靠著網站 TLS 憑證 CLI 快速檢視工具，連上兩台網站 IP 明確對照出中繼 CA 憑證到期日及指紋差異，獲得鐵證。請 OP 補安裝中繼 CA 憑證，移除及重新匯入網站憑證後，兩台網站傳回的三張憑證都是最新版，問題終告排除。

而歷經本次經驗，我也整理出類似憑證無效案例的處理 SOP：

  1. 先從瀏覽器憑證檢視器初步查看憑證鏈的有效狀況
  2. 使用 openssl s_client -connnect <host>:443 取得詳細錯誤訊息
  3. 使用網站 TLS 憑證 CLI 快速檢視工具確認是否傳回憑證鏈(網站、中繼CA、根CA)的所有憑證，檢查名稱、到期日、指紋是否正確

An odd case of TLS Certificate with an invalid digital signature: This article organizes the problem phenomenon, root cause analysis, and methods of elimination.


Comments

# by 樂透無名

大感謝

Post a comment