一個HTTPS問題的排查，誰的鍋？
上週三臨下班的時候，收到一個使用者不能開啟企業郵箱頁面的投訴，最終發現是 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 版本是何時釋出
chrome 36 版本釋出時間
通過上圖看出 2014 年釋出的，也不算太舊。
（2）檢視該 Chrome 版本 https 支援的最高版本
通過 SSL Labs User Agent Capabilities 工具 檢測結果如下：
[圖片上傳失敗...(image-677f7c-1533520758958)]
通過上圖看出該版本最高支援 tls 1.2，不存在 https 版本配置過低的問題。
既然從理論上排除了 Chrome 相容性問題，我想使用 Chrome 開發者工具【Security】選單檢視具體的 https 報錯資訊，悲催的是 chrome 36 版本居然沒有【Security】選單。。。最好的排查工具無法使用了，該版本的開發者工具如下圖：
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 配置情況。
這個工具會掃描對應域名所有的 IP，然後顯示該 IP 下的證書、HTTPS 配置的具體情況，測試 www.sinaimg.cn 結果如下：
ssllabs analyze www.sinaimg.cn 檢測
通過上圖可見整個配置檢測沒有問題。接著測試 i0.sinaimg.cn，結果如下：
ssllabs analyze 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 配置情況（更輕量的工具）。
我最近寫了一本書 《深入淺出HTTPS：從原理到實戰》 ，歡迎去各大電商購買，也歡迎關注我的公眾號（yudadanwx，虞大膽的嘰嘰喳喳）。