某日臨近下班的時候，收到一個用戶不能打開企業郵箱頁面的投訴，最終發現是 HTTPS 的問題，這篇文章完整記錄了處理過程，解決投訴后，我也在思考問題產生的原因。

收到投訴后，我們的運維同事使用 QQ 遠程連接用戶桌面(最有效、最快速的問題排查手段)的功能了解具體的情況，初步情況如下：

• Chrome 打開企業郵箱官網(https://mail.sina.net)沒有問題。
• 登錄 webmail(https://webmail.sina.net)后頁面空白。

運維同事使用 Chrome 開發者工具發現 webmail 頁面(該頁面能夠正常輸出數據)引入的靜態元素(js、css)無法加載，將某一個 js 文件(i0.sinaimg.cn 域名)單獨在 Chrome 中打開，頁面出現 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 錯誤。

可能有些同學奇怪，為什么 js 文件打不開就出現空白頁面?這和我們的前端開發架構有關，頁面的渲染極度依賴 js，如果 js 無法加載整個頁面就無法呈現。

看到 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 錯誤，我***反應是服務器 https 配置兼容性不好或者客戶端(Chrome)https 配置支持不夠。考慮到只有個別用戶投訴，再加上我本來就知道郵箱 https 配置兼容性非常廣(支持 tls 1.0、tls 1.1、tls 1.2)，所以重點懷疑客戶端 https 的問題。

進一步排查發現用戶的 Chrome 版本是 36，潛意識認為是用戶瀏覽器版本過低的問題，做了兩個檢查：

(1)查看該 Chrome 版本是何時發布

(2)查看該 Chrome 版本 https 支持的***版本

通過 SSL Labs User Agent Capabilities 工具(https://www.ssllabs.com/ssltest/clients.html)檢測結果如下：

通過上圖看出該版本***支持 tls 1.2，不存在 https 版本配置過低的問題。

既然從理論上排除了 Chrome 兼容性問題，我想使用 Chrome 開發者工具【Security】菜單查看具體的 https 報錯信息，悲催的是 chrome 36 版本居然沒有【Security】菜單。。。***的排查工具無法使用了，該版本的開發者工具如下圖： 

此時我抓瞎了，繼續思考，有兩個新的現象進入腦子：

(1)webmail 360 瀏覽器能夠正常訪問，IE、Chrome 無法訪問，其實這一條信息干擾性極大，讓我懷疑還是客戶端兼容性的問題。

由于不是我遠程連接用戶桌面，所以當時也沒有查看(也沒想到) 360 開發者工具的調試信息，這是非常可惜的一點。

(2)Chrome 訪問企業郵箱官網沒有問題，這其實是非常重要的一條信息，如果是客戶端(IE、Chrome)問題，為啥官網 https 訪問沒有問題，我打開開發者工具看了一下，發現官網引入的 js 元素域名是 www.sinaimg.cn。

問題逐步清晰了，官網和 webmail 引入的 js 元素域名是不一樣的，我們公司所有的靜態元素都部署在自有 CDN 上(事后才知道也引入了阿里云 CDN)，是否這兩個域名配置的證書以及 HTTPS 配置不一樣?雖然本就知道公司證書都是 SAN 泛域名證書，所有的域名以及子域名都使用同一張證書，但從嚴謹的角度考慮，我還是使用SSL Labs SSL Server Test 工具(https://www.ssllabs.com/ssltest/analyze.html)測試 https 配置情況。

這個工具會掃描對應域名所有的 IP，然后顯示該 IP 下的證書、HTTPS 配置的具體情況，測試 www.sinaimg.cn 結果如下： 

通過上圖可見整個配置檢測沒有問題。接著測試 i0.sinaimg.cn，結果如下： 

出現上圖的的原因就是 CDN 的某個點的 https 配置(443端口)無法獲取到，工具中止了檢測。

此時問題逐步清晰了，公司靜態池(靜態元素)CDN 部署了很多點，是否是某個點 https 配置有問題?CDN 由公司專門團隊維護，立刻向他們反饋，五分鐘后問題解決。

得到的反饋就是靜態池也使用了阿里云的 CDN(最近剛加的點，投訴用戶正好訪問了這個 CDN 點)，而這個 CDN 點居然沒有配置支持 https。。。

CDN 同事在阿里云開啟 443 https 服務(主要工作是上傳 i0.sinaimg.cn 證書)后就解決了問題，我們不禁要追問為這個點什么沒有 https 部署，他們的解釋是沒有接到這個點要支持 https 的需求。。。

對于這個理由，要是我還是當年年少輕狂的我，估計要噴他們了(現在也只能心里噴了)，靜態池服務早就宣稱全站支持 HTTPS 了，為啥還有這問題?CDN 配置是開發人員無法也無需知道的(完全透明)，既然全站 HTTPS 了，新增加一個點是不是應該也要支持?怎么能說沒有接收到需求呢?我渣浪的甩鍋作風還是一如既往。

有些同學不禁要問，這么大的故障，為啥別的產品不受影響呢?原因就在于 i0.sinaimg.cn 這個域名下的服務使用者可能很少，下一階段我們要盡快將靜態元素遷移到 www.sinaimg.cn 域名上。

解決該問題后，我冷靜下來思考，為啥 360 瀏覽器沒有問題?同一臺機器 DNS 解析難道不是一樣的嗎?360 連接的 443 服務器難道和 Chrome 連接的 443 服務器不一致?如果不一致，那么 360 瀏覽器顯示正常是可以理解的，如果一致，那就很難解釋了。

由于當時沒有看到 360 瀏覽器訪問的具體情況，所以我做了一個測試：

• (1)登錄阿里云 CDN 控制臺，默認 443 端口是關閉的，也就是說故障發生的時候，443 肯定沒有開啟。
• (2)由于我沒有阿里云 CDN 服務，所以做了個模擬，用自己的服務器測試 https://www.simplehttps.com(80 打開，443 關閉)，看看 360 瀏覽器是如何運行的

最終使用 360 瀏覽器訪問該網址，不能成功打開，所以這成了一個懸案了。

通過這件事情，得到的一些體會和想法：

• 排查問題是需要經驗的，經驗基于技能的掌握程度，冷靜的頭腦，熟練借助工具。
• 很多問題看上去很復雜，但最終的原因是如此無厘頭，這說明整個技術體系是混亂的，是割裂的。
• 實際排查順序并不是本文描述的那樣，也走了很多彎路，如此整理是為了讓讀者更好的了解排查問題的思路。
• SSL Labs 工具 SSL Server Test 非常好，它是如何檢測出一個域名對應的所有 IP 呢?如果有現成解決方案，我打算基于此，寫一個簡單的小工具，快速診斷出 https 配置情況(更輕量的工具)。