記一次證書更換姿勢不正確導致的曲折經歷

寫在Forefront Threat Management Gateway 2010 行將就木之際。

週六突然接到老闆電話,集團大佬移動郵件又不能使用了(爲什麼是又,那是另外一個故事了,有機會再講)

根據預案我們做了幾件事情:

  1. 測了一下自己手上的Apple訪問移動郵件都正常,大佬是一臺HUAWEI榮耀Note8
  2. 找另一個使用華爲的用戶也測了一下都正常
  3. 查了一下TMG日誌,按該用戶名搜訪問日誌,在週五晚上9:38是最後一條訪問。也就是說客戶端後面再也沒有連TMG,所以當然也不會同步郵件

Failed Connection Attempt TMGServer01 6/28/2019 9:38:06 PM
Log type: Web Proxy (Reverse)
Status: 10054 An existing connection was forcibly closed by the remote host.
Rule: ActiveSync Rules 1
Source: External (114.11.111.222:40953)
Destination: Local Host (172.0.0.11:443)
Request: POST http://mail.domain.com.cn/Microsoft-Server-ActiveSync?Cmd=Ping&User=domainname%5Cusername1&DeviceId=androidc1003508868&DeviceType=Android
Filter information: Req ID: 0e8c098b; Compression: client=No, server=No, compress rate=0% decompress rate=0%
Protocol: https
User: paicdom\username1
Additional information
Client agent: Android/8.0.0-EAS-2.0
Object source: Internet (Source is the Internet. Object was added to the cache.)
Cache info: 0x8 (Request includes the AUTHORIZATION header.)
Processing time: 480093 MIME type: application/vnd.ms-sync.wbxml

  1. 查了一下IIS日誌,按該用戶名搜訪問日誌,只找到EWS的訪問記錄,沒有ActiveSync,也是週五9點半後就沒有記錄了。

懷疑是這個用戶郵箱損壞,遂New-Moverequest遷移到其他數據庫。然而並沒有什麼。。

和老闆溝通,在故障前做的唯一變更就是另一個同事週五晚上替換了偵聽器上綁定的公網證書,但是我們自己測了Apple移動郵件還能訪問,說明證書沒什麼問題。感覺這個懷疑點不成立。

又懷疑是否客戶端真的沒有連過來呢,是不是有可能被服務器拒絕了呢,所以在TMG上開啓日誌debug模式,手動在瀏覽器裏輸錯密碼,模擬被服務器拒絕的場景,是能看到Access Denied的記錄。所以服務器拒絕論也不成立。

接下來懷疑是否客戶端只是7層不通,還沒有到達TMG的第一條規則就被拒絕了所以查不到記錄呢,所以按照客戶端最後一次連過來的IP,用Client IP作爲篩選條件,還真的查到了客戶端一直在反覆和TMG服務器建立連接又正常釋放掉的記錄。嚴重懷疑是證書變更引起的故障。

遂安裝Network Monitor,通過抓包,看到TCP三次握手正常,TMG把SSL證書發送給客戶端後,客戶端返回Fin關閉該連接,果斷回滾了證書的變更,過了一會,可以看到客戶端正常連過來了。

雖然故障解決了,但是老證書還有一週就要過期了,還是得替換。

週一去到用戶現場,通過訪問一臺換了新證書的TMG,重現了這個問題,嘗試配置一個新Profile時,客戶端上看到明顯報錯——由於證書無效或不可信,無法連接到服務器。

老闆說可以申請了一臺同款設備來重現這個問題,找遍各大電商,唯獨蘇寧還有貨而且可以×××,趕緊下單擼了一臺。

爲什麼一個iOS信任的證書到了HUAWEI設備上就不信任了呢。我讓替換證書的同事演示了一下證書導入的操作給我看,打開證書MMC,在Personal下右鍵導入一個pfx,然後SSL證書,中級CA證書,根CA證書全部放個人目錄下了,我直接一口老血吐了出來,再去檢查中級CA和根CA目錄,果斷中級CA目錄下沒有新證書的中級CA證書,看來原因就出在這裏了。導入中級CA後,過了一段時間後,偵聽器再應用這張新的證書。證書驗證不通過的報錯沒有了。

另外還有一個插曲,HUAWEI的設備對證書校驗是有緩存的,所以服務器導入中級CA後沒有辦法馬上生效,可能要等好幾個小時,客戶端纔會重新請求服務器提供新的證書鏈,如果已經是證書無效狀態,即使服務器端已經配置好了證書,客戶端仍需要傻等,而重啓手機能夠釋放掉這個緩存。Just 重啓 it。

度娘搜了一下中級證書頒發機構,找到一篇blog(https://xz.aliyun.com/t/2531 )還講的蠻詳細的,裏面有一句講到服務器按信任鏈的順序發送完整的證書列表。該鏈中的第一個是服務器證書,接着是頒發服務器證書的intermediate CA 的證書,然後是下一個intermediate CA 的證書......直到Root CA的證書。服務器可以不發送Root CA證書,因爲在大多數情況下,瀏覽器可以從任何intermediate CA 識別Root CA。像HUAWEI這個郵件客戶端在整個SSL/TLS握手過程中執行了較爲嚴格的證書鏈校驗,需要拿到服務器證書和中級CA後,才認爲服務器證書是有效的,而Apple只需要信任該證書的根CA就認爲證書有效了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章