【茶包射手日記】網站憑證無效案例分析

小閃光提供茶包一枚 - 速食店網站在 Android 手機 Chrome 瀏覽時出現憑證無效警示，但在電腦(Windows 10)用 Chrome 檢視卻完全正常。

陸續試了家中幾支 Android 手機跟平板，清一色得到相同 ERR_CERT_AUTHORITY_INVALID 警告訊息。我初步推測是根憑證信任問題，有可能它的根憑證 - ePKI Root Certification Authority - G2 較新，而我測試用的 Android 版本都不算新(很久沒買新手機、平板惹)，未將其納入信任根憑證清單，但 Windows 有，故造成 Android 不行，Windows OK 的結果。但我衍生兩個疑問：

1. Android 會透過什麼機制更新信任根憑證清單？若只能隨 OS 版本更新，那舊手機怎麼辦？
2. 在購買 TLS 憑證時，是否應優先選擇老牌的知名 CA，以避免這種未列在客戶端內建信任清單而視為不安全的狀況？
   (有一部分使用者可能因警告而放棄，錯失商機)

在臉書專頁舉手發問，小站的讀者群一向臥虎藏龍，紛紛回饋意見及診斷工具，讓我學到不少新知識，在此統一感謝。依據大家給的資訊，我進一步偵察分析，最後算是搞清楚了問題所在，以下為筆記整理。

我以前只用過 Qualys SSL Labs 的 SSL Server Test，這回再學到兩個新工具，能得到額外憑證細節：

第一個是 What's My Chain Cert?，依其分析，摩斯網站的信任鏈(Certificate Chain)確實有問題(Misconfigured)

第二個是 SSLChecker，又提了更多憑證資訊，以本案為例，Vender Signed 顯示為 SSL is not trusted，而 Certifcate Chain 中的 CHAIN CERT1 及 ROOT1 也呈現無效，Issuer 為 NA：

以上測試結果均指向憑證信任鏈出了問題，而我初步推測是 Android 版本不夠新，內建信任根憑證清單未包含 ePKI Root Certification Authority - G2 根憑證造成。但隨後發現的新事證，很快地推翻此一假設!

我想確認問題所在，是根憑證未被信任、網站 SSL 憑證本身瑕疵，還是網站安裝設定有問題？最好的方法是找到另一張由該根憑證發行的網站憑證對照一下，若兩個網站在 Android 手機都呈現憑證無效，即代表根憑證不被信任有關；否則便是摩斯網站這張憑證或是安裝設定方面的問題。臉書討論串提到中華電信憑證管理中心的 SSL 憑證安裝手冊下載網頁，順手查了該網站的 SSL 憑證，喜出望外，二者的根憑證都是 ePKI Root Certification Authority - G2 根憑證，信任鏈結構相同，而中華電信憑證中心的網站憑證設定不可能出錯，是再完美不過的對照組：

奇妙的事情發生了，用 Adroid 手機查看憑證中心網站的憑證是有效的。

由於二者的根憑證相同，所以問題並非根憑證不在信任清單。使用 What's My Chain Cert? 檢查，HiNet CA 網站的憑證被判定有效，而跟摩斯網站憑證信任鏈的一大差異是憑證中心網站的 CHAIN CERT1 為綠色有效狀態，判定是二者結果不同的關鍵：

使用 openssl s_client -showcerts 對照檢查，得到一個線索，摩斯網站的檢核結果 depth=1 "Public Certification Authority - G2" 出現 "unable to get local issuer certificate" 錯誤訊息；連接 HiNet CA 網站時則無此錯誤。

這樣看起來問題似乎出在摩斯網站的設定，參考中華電信憑證中心安裝手冊，提到 IIS 站台必須要同時安裝 eCA 根憑證(ePKI Root CA)、PublicCA 中繼憑證、SSL 伺服器憑證等三張憑證：

我過去對這段研究不深，針對這部分再做了些功課。得知非 IIS 網站有一種合併 Root CA 、中繼 CA 憑證、網站憑證 PEM 檔以提供完整信任鏈的技巧(範例、範例，在 IIS 則是要透過 MMC 憑證管理員匯入根 CA 憑證、中繼 CA 憑證與伺服器憑證，由 IIS 視需要提供給瀏覽器或 HTTP 客戶端以組合出完整信任鏈(根 CA 憑證除外)，在微軟官方文件 Configure intermediate certificates on a computer that is running IIS for server authentication 找到一段說明：

In the SSL negotiation, the server certificate is validated on the client. In this case, the server provides the certificates to the client computer together with the intermediate issuing certificates that the client computer can use to build the certificate path. The complete certificate chain, except for the root certificate, is sent to the client computer.
IIS determines the set of certificates that it sends to clients for TLS/SSL by building a certificate chain of a configured server authentication certificate in the local computer context. The intermediate certificates must be configured correctly by adding them to intermediate CA certificate store in the local computer account on the server.

另外，我找到一篇那些關於SSL/TLS的二三事(十二) — Chain of Trust也有相似的描述：

當一個網站請求一個憑證時, 其會得到葉憑證以及中介憑證. 這些基本上都是要被部署到網站上的, 以利瀏覽器對信任鍊進行驗證. 所以實際上在 SSL handshake 的 “server hello” 之回傳結果中, 可能都會有一大票的憑證出現, 當中若有任何一個中介憑證出錯或是不見了, 都會導致 SSL handshake fail.

綜合以上線索，我得到新結論。摩斯網站的憑證沒問題，問題出在 IIS 主機未匯入中繼 CA 憑證，Android 瀏覽器無法取得建立完整信任鏈，這也是 openssl 測試 unable to get local issuer certificate 錯誤訊息的由來。

本想做個實驗驗證這點，但憑證實驗做起來頗麻煩，就先請有相關經驗的網友幫忙補充證實好了。而我最好奇莫過於我對摩斯網站憑證問題的推測是否正確，如果有人有相似經驗，或剛好有環境能幫忙驗證，歡迎回饋分享給我。

Found a web site's SSL certificate is not trusted by Android Chrome, but fine in Windows Chrome, I learned how to use tools to diagnostic and try to find the cause.