上週的 SSL 憑證茶包還有下集。

經手動匯入 TWCA 憑證,IE/Chrome 連上目標 HTTPS 網頁已正常,但呼叫廠商 API 的 .NET 服務程式仍冒出 Could not establish trust relationship for SSL/TLS secure channel 錯誤(明顯為憑證無效問題),改跑廠商提供的 API 範例,該程式使用 ALT COM+ ,在開發機執行正常,在問題主機執行卻久久無回應。詭異的是,將有錯程式片段複製到 LINQPad 執行或包進 Console Application 測試卻是正常。

實測加上ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };可鋸箭解決,但沒挖到真相不甘心,也擔心沒找出問題根源不知其所以然,未來會被同一來源的變種茶包咬到不知所措,帶上裝備繼續搜索。

使用 Wireshark 側錄廠商 API 範例封包找到一條線索,網站傳回 SSL 憑證後,客戶端回傳 Unknown CA 錯誤,而除此之外範例程式並未嘗試連線任何外部主機,而是直接判定憑證無效,推測與 CRL/OCSP 無關。

此時同事也傳來另一則重要情資 - 程式碼放在 Windows Service 裡執行才會出錯,解釋了相同程式碼改用 Console Application 跑就沒問題的原因。

綜合兩項線索,我心中浮現嫌犯 - 是執行身分!

手動匯入 CA 憑證時,UI 有兩個選項:目前使用者、本機電腦,先前依直覺選了目前使用者,所以根憑證被安裝到目前登入使用者的憑證儲存區,而該 .NET 寫的 Windows Service 執行身分為 LOCAL SYSTEM,找不到根憑證很合理,因此判定 SSL/TLS 憑證無效拒絕連線。API 範例程式連線時出現 Unknown CA,推測也是找不到根憑證造成。

改將憑證安裝到本機電腦,問題果然就解決了。

另外補充一點,經驗中「自動根據憑證類型來選取憑證存放區」有時會放錯地方,手動選取「受信任的根憑證授權單位」較保險。

而過程還多學到一些冷知識:使用 MMC 新增憑證嵌入式管理單元時,除了「我的使用者帳戶」及「電腦帳號」外,還有一個「服務帳戶」選項:

會列出機器上所有服務清單供你挑選:

意味著 Windows 允許為每個服務個別安裝設定憑證:

不過,如無特別考量,裝在本機電腦(電腦帳號)全機適用是較省事的做法。

最後補充一點,本次案例需安裝的 TWCA 憑證有兩張:TWCA Root Certification Authority、TWCA Global Root CA,兩張都要匯入。參考:保哥文章- 如何正確安裝政府簽發的憑證到正式主機

Experience of installing CA root certification in the right store to make sure .NET program or Windows service to find it.


Comments

Be the first to post a comment

Post a comment