帶有 Windows 伺服器和 Android 客戶端的 CertPathValidatorException
我在 Windows Server 2008 R2 電腦上安裝了 Comodo 的新 PositiveSSL 證書。我從以下客戶端成功連接
- 適用於 Windows 的 Chrome
- 安卓版 Chrome
- 火狐瀏覽器
- IE瀏覽器
- 適用於 Windows 的維瓦爾第
- Opera for Windows（HTTPS 和 IMAP）
- Windows 遠端桌面連接
到以下伺服器
- 帶有 mod_ssl 的 Apache
- 遠端桌面服務
- 守護程序
但是，當我使用 K-9 Mail for Android 連接到 MDaemon 時，出現錯誤
java.security.cert.CertPathValidatorException: Trust Anchor for certificate path not found我假設 Chrome 和 K-9 在同一部手機上的行為不同，因為 Android 版 Chrome 提供了自己的根 CA 儲存，並且不依賴於 Android OS 根 CA 儲存，或者至少具有不同的信任驗證邏輯。
我安裝的證書直接來自 Comodo 通過電子郵件發送給我的 ZIP 文件：
AddTrustExternalCARoot.crt (this is the root CA) COMODORSAAddTrustCA.crt (this is a higher-level intermediate CA) COMODORSADomainValidationSecureServerCA.crt (this is a lower-level intermediate CA) www_myserver_com.crt (this is my server's cert)當我將這些安裝到 Windows 證書儲存中以供 RDP 和 MDaemon 使用時，我使用以下方法將這些證書轉換為 PKCS12 文件
cat "./www_myserver_com.crt" "./COMODORSADomainValidationSecureServerCA.crt" "./COMODORSAAddTrustCA.crt" "AddTrustExternalCARoot.crt" > "./fullchain.crt" openssl pkcs12 -in "./fullchain.crt" -inkey "./www_myserver_com.key" -out "./fullchain.pfx" -export然後使用自動儲存目標將 PFX 文件導入電腦帳戶的證書 MMC 管理單元。我在 SSL & TLS > MDaemon 下的 MDaemon 安全設置對話框中選擇了新證書，然後點擊重新啟動伺服器。使用 OpenSSL，我可以看到正確的證書與中間證書一起提供。
C:\>openssl s_client -connect myserver.com:993 CONNECTED(00000003) depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.myserver.com verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.myserver.com i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Dom ain Validation Secure Server CA 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Dom ain Validation Secure Server CA i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Cer tification Authority --- Server certificate -----BEGIN CERTIFICATE----- MII..8hg== -----END CERTIFICATE----- subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.myserver.com issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA D omain Validation Secure Server CA --- No client certificate CA names sent Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3401 bytes and written 450 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher : ECDHE-RSA-AES256-SHA Session-ID: F04A0000068E4DC91357783440DA44EEB39DA3C813C3C646EBCE29DDD3E8C139 Session-ID-ctx: Master-Key: FF3D72A03F1F93686AC6EAB38198036C7AF1780250ED3F510A83CE6DC166778F A726DBC2AA4ED6C5277A0969D175E419 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1495135778 Timeout : 300 (sec) Verify return code: 0 (ok) ---我查看了 Android 中的證書鏈以及根 CA 是否在 Android 的 CA 儲存中。
這是預期的完整證書鏈。以下名稱是通用名稱 (CN)。
AddTrust External CA Root └─COMODO RSA Certification Authority └─COMODO RSA Domain Validation Secure Server CA └─www.myserver.com我看到 Android 證書儲存中確實存在 AddTrust External CA Root 並具有正確的指紋。
為什麼 K-9 Mail 會拋出錯誤，指出沒有從我的伺服器的 TLS 證書到受信任的根 CA 的路徑？
答案來自 Comodo 知識庫文章：Untrusted Certificate Error on Android。
錯誤的原因是預設 Windows 證書儲存中的現有 Comodo 證書。預設情況下，中間證書之一
COMODO RSA Certification Authority作為自頒發的 CA 證書存在於 Trusted Root Certification Authorities 文件夾中。我沒有在那里安裝它，Windows 有它的庫存安裝。我不確定它為什麼存在，因為真正的 COMODO RSA 證書頒發機構是由 AddTrust 頒發的，而不是由 AddTrust 頒發的，而且指紋不匹配。此外，Android 4.4 的根儲存中不存在這個自發的虛假 Comodo 根 CA，儘管還有其他三個 Comodo CA 的 CN 相似到足以讓人混淆，除非您檢查指紋。Comodo 和 AddTrust 之間的 CA 重組可能有一些歷史原因。知識庫文章中的解決方案已修復 K-9 中的錯誤：從 Windows 受信任的根證書頒發機構中刪除自行頒發的 COMODO RSA 證書頒發機構（我實際上將其剪切並粘貼到不同的文件夾中，以防我需要恢復更改，而不是永久刪除它）。
這個偽造的證書導致 MDaemon 假設更高級別的中間 Comodo 證書實際上是根證書，並且它沒有在 SSL 握手中將其發送給 K-9。這在 s_client 輸出中已表明但對我來說不夠明顯。在修復之前，MDaemon 僅發送鏈中底部的兩個證書，而 Android 沒有從第三個證書（Comodo 域驗證）到 AddTrust 的信任路徑，因為響應中缺少第二個證書。修復後，MDaemon 發送了鏈中底部的三個證書，Android 能夠成功找到從 Comodo Certification CA 到 AddTrust 的路徑。
一個未解決的項目是 Windows 自動根 CA 更新。Comodo 警告說，這些更新會將不需要的證書恢復到受信任的根 CA 儲存，並建議您禁用所有根 CA 更新。我認為這不是最好的解決方案，因為我希望根 CA 列表在這個例外情況下保持最新。我正在考慮嘗試查找或編寫一個可以從電腦證書儲存中刪除給定證書並定期執行的程序。也許我可以編寫一個基於 PowerShell 或 certmgr.exe 的腳本。至少，也許我可以在更新根 CA 列表並恢復不需要的證書時添加一些自動監控，所以我知道是時候手動刪除它了。