部署全站HTTPS有哪些值得分享的經驗和教訓？

01-03

諸如前端遷移、CDN、SNI、證書配置及瀏覽器與操作系統兼容性等

謝邀，這個網站可以幫你檢查部署中的各種問題，比如安全測評、證書配置、瀏覽器兼容性等。

SSL Server Test (Powered by Qualys SSL Labs)

至於CDN，要麼用CDN服務商提供的證書，要麼就把你的證書也託管到CDN服務商上。

這個問題有點大和泛。我簡單回答幾條吧：

前端的最大工作量是為了適配和兼容多協議（HTTPS/HTTP)而進行的資源地址改造。因為主頁為HTTPS時，載入頁面所需要的資源都應該支持HTTPS（否則會出現安全風險），這就要求以前只支持HTTP協議的資源同時支持HTTPS，資源越多，改造的工作量越大，越複雜。假如資源只涉及到一兩個域名，改起來還比較方便，但考慮到有些資源可能是合作站點，甚至是政府部門時，這個改造可能就比較艱難。當然也會有一些比較奇葩的情況，比如有一些資源地址是寫死到HTML里的，有一些是寫死在資料庫里的，改起來會稍微麻煩點。這就提醒廣大前端，盡量考慮到協議兼容和適配，畢竟HTTPS是大勢所趨。
前端遇到的最大問題是域名收斂和連接復用。基本上大型網站在HTTP1.1/1.0協議時為了優化訪問速度都會做大量的的域名分片和資源合併（比如圖片和CSS），但域名分片技術在HTTPS時反而會降低速度，因為HTTPS的握手非常耗費時間。多一個域名意味著多幾個HTTPS握手。另外HTTP2和SPDY都有連接復用的特性，資源合併也顯得有些多餘，把簡單的工作複雜化。因此前端進行收斂域名既能減少HTTPS握手又能提升連接復用率，提升頁面載入速度。
可以參考但不要完全相信證書檢測機構的數據。比如qualys ssl lab。它對證書的檢測非常嚴格非常安全非常理想，導致它的數據有點不切實際。為什麼？因為客戶端和瀏覽器的更新趕不上安全技術的發展。比如IE6只支持SSLv3，比如一些客戶端只支持aes cbc和rc4。但這些協議和加密演算法事實上都不安全了，那網站應該怎麼辦？特別是在中國市場，你是升級使用最新的協議和加密演算法從而導致這些用戶不能訪問HTTPS呢？（相當於放棄這些客戶端和用戶，比如IE6，7），還是採取折中妥協的辦法，使用稍微弱一點的有安全風險的演算法，但能夠保證用戶訪問呢？比如SSL3用戶只能使用RC4演算法。有一些網站就會選擇後者，比如google，比如百度,他們在qualys ssl lab的評級都不高。
解決SNI的問題只能依靠多域名證書，也就是把所有需要支持到的域名綁定到一張證書上。由於所有系統都支持多域名和泛域名證書，所以里不存在系統兼容性問題，但這樣會存在證書申請和維護的問題，因為一旦域名有新增，就需要重新申請一張全新的多域名證書，並且進行全量部署，成本比較大。但要想從SNI的角度解決這個問題，沒有完美的解決方案。因為這依賴於客戶端的SSL庫是否支持SNI，作為網站或者內容提供方，即使是自有APP都控制不了是否使用SNI，更別提傳統瀏覽器了。不管怎麼樣，網站服務商肯定需要支持SNI。
查看瀏覽器是否支持某些特性可以使用這個網站：Can I use... Support tables for HTML5, CSS3, etc。比如SNI，SPDY等。

先寫這麼多吧。有具體問題可以在評論里提，有興趣的可以參考我之前的幾篇文章：

互聯網全站HTTPS的時代已經到來。
大型網站的 HTTPS 實踐（三）——基於協議和配置的優化

另外歡迎關注我的知乎專欄《HTTPS原理和實踐》http://zhuanlan.zhihu.com/https，PS：之前投入時間不多。。。今年會加大力度。

在國內建議把除了根證書之外的證書全部通過伺服器發送，別信瀏覽器的自動下載。（註：這會略微增加握手時間，自行權衡利弊。）

https://myssl.com/myssl.com