背景介紹：2017年1月份，Google將Chrome 56中所有的 http站點標記為不安全，並對所有使用http方式的登錄交互頁發出醒目的“不安全”提示。
Apple自2015年WWDC大會開始，就在計劃逐步推進實施ATS(App與後臺服務器通訊強制使用https通訊)的實施，並在2017年WWDC大會上發佈明確的時間節點，使https服務成為所有iOS及MAC上App的標配。
隨著一些國際主流CA機構免費型DV SSL證書產品的出現，SSL/TLS證書的應用越來越廣泛。SSL證書與域名一樣，很快會成為每一個互聯網站點不可或缺的基礎服務要素。SSL/TLS證書的應用逐漸普及，越來越多的站點正在加速啟用全站https服務。而在瀏覽器方面，Chrome及Firefox在所有新發布的瀏覽器版本中支持HSTS。已經有相當一部分站點啟用了HSTS服務，徹底將http服務從支持的選項列表中移除。
如何保障SSL/TLS證書的安全及可靠？
全面的推廣和應用SSL/TLS，會給站點安全性帶來質的提升，徹底杜絕中間人攻擊、網絡劫持等攻擊行為。但於此同時，考慮全站https之後的高可用保障時，SSL/TLS證書的安全性問題就逐步凸顯出來。
如何確保https服務能夠7*24不間斷服務，不僅是企業內部IT運營團隊需要考慮的問題，同時也對第三方CA服務商提出了更高的要求。
一旦第三方CA服務商出現運營或安全事故，將導致CA服務商的認證服務不可用。這將直接影響到使用企業IT服務的最終用戶。無論是PC客戶端、移動終端，還是API接口程序，都將有可能因此受到衝擊，導致服務不可用。
因此在進行站點高保障安全運營維護工作的同時，要求SSL/TLS服務供應商也必須確保提供7*24不間斷的高可用性服務，才能保障服務的可靠性。
SSL/TLS證書服務需注意這三點：
比起單純的採用一張SSL/TLS證書，要確保高可用性保障的服務站點不受一家第三方CA認證機構的安全或運營事故牽連，同時使用兩家不同的CA機構提供的高可用性SSL/TLS證書服務就顯得尤為必要了。
無論是選擇一張SSL/TLS證書服務，還是採用雙證書方案同時使用兩張SSL/TLS證書，都需要首先考察CA服務機構在服務保障上的工作是否有做足功課。
首先，CA機構在體量上，當然是越大越好。選擇全球排名靠前的幾家大型老牌CA機構的產品，能夠確保CA機構的產品有更深厚的技術積累和安全保障。不會因為黑客組織或個人的攻擊行為、系統安全系統漏洞、認證不規範等各種原因導致服務中斷或被其他機構列入信任黑名單。
其次，CA服務商在此之前是否發生過大的安全或運營事故，是否遭受過嚴厲懲罰措施也是需要預先考察的。在事故發生後，CA服務商能否協調各方快速及時處理，並保障最小限度的影響客戶的這種能力，也會給客戶的證書應用保障加分。
最後，CA服務商在國內是否有服務加速。
證書籤發後，在證書的使用過程中，通常還需要客戶端請求CA系統獲取證書有效性驗證信息。證書的有效性驗證，主要採用兩種方式：OCSP及CRL。
OCSP的驗證數據包體積較小，但對應答的及時性有要求。服務器延時越小，客戶端驗證速度越快。
CRL的驗證數據包體積較大，但支持CRL支持緩存。可通過CA服務商的CDN加速服務網絡分發。因此要求CA服務商在國內使用CDN加速服務也是很有必要的。
以下方案，主證書採用Digicert（原Symantec）品牌，備份證書採用Entrust或GlobalSign品牌。
如何部署實施高可用性雙證書？
1.單證書在線
單證書在線方案實施起來非常簡單，也很好理解其運行模式。主證書部署在服務器上，備份證書在主證書正常運行期間並不需要安裝部署。一旦發生CA服務商安全或運營事故的情況，可通過手動更新配置啟用備份證書並下線主證書，或通過自動化部署腳本自動切換到備份證書服務上。
主證書可按照應用需求，購買單域名、增強驗證型帶綠色地址欄的EV型、多域名或通配符等類型的證書。主證書的註冊申請、維護和安裝仍然使用原有的模式，不改變部署安裝習慣。
備份證書推薦採用多域名，或通配符證書。只需要確保備份證書能夠快速覆蓋主證書的服務範圍，通常不需要頻繁的變更或重新註冊申請。並且在需要應急啟用時，能夠快速變更替換主證書對應的服務。
2.源站服務器使用主證書，CDN、高防、WAF等服務使用備份證書
使用CDN、高防或WAF服務的用戶，可在源站服務器上安裝使用主證書，在CDN、高防、WAF等服務中使用備證書。
通常這類服務還可能委託給第三方CDN服務商來部署實施，所以這種模式下使用雙證書方案時，選擇兩個不同的CA服務商提供的產品不僅能夠規避CA運營或安全封信問題，同時源站與CDN、高防、WAF服務上配置的證書使用的證書密鑰對也是不同的。任何一個證書出現的運營安全故障（如祕鑰丟失、祕鑰洩密）都可以快速定位責任主體。第三方CDN服務商的祕鑰洩露也不會影響到源站的數據傳輸安全。
3.主備證書同時在線
成功案例解析
由於Chrome的bug導致所有2016年6月1號之後簽發的證書，在Chrome 53、54下報證書透明度日誌不可用錯誤（CT Log），某互聯網頭部企業啟用了
Digicert（原Symantec）+ GlobalSign 雙證書方案。針對IE、Firefox等瀏覽器，自動使用Digicert（原Symantec）證書，所有版本的Chrome瀏覽器訪問，則自動啟用GlobalSign證書。
一些超大型網站或應用，往往對SSL/TLS證書的兼容性有著非常嚴苛的要求，部分通過API接口對接的服務型產品，更對CA服務商的產品有著更高的兼容性要求。主證書使用大牌CA廠商的證書產品，往往能夠獲得最優的兼容性支持。但當遇到特定應用場景下的不兼容時，使用雙證書應用解決方案，可以有效的規避超大型站點在客戶端出現的SSL/TLS證書兼容性故障，同時確保API接入用戶不會受到證書變更造成的不良影響。
通常，使用雙證書同時在線的方案，需要使用到前端代理服務器通過http代理，UserAgent的識別，Proxy的https重定向來實現這一目標。
以下以Nginx的代理配置來簡單介紹：
要實現根據用戶 UA，自動重定向到策略指定的SSL/TLS證書服務站點上，首先要求後端必須有多臺服務器負責處理https請求，並且在這些站點中分別部署主備兩張不同的證書。其次，站點必須關閉HSTS，以避免客戶端瀏覽器直接通過https方式訪問服務器。用戶必須是以默認的http服務訪問服務器，然後由服務端的Proxy代理進行策略負載。
其配置原理如下：
if ( condition ){
do_something
}
if ( $http_user_agent = "wget" ){
do_something
}
if ( $http_user_agent ~ MSIE ){
do_something else;
}首先，配置好後端服務器策略，為不同的服務器群集配置其專用的證書
######配置IE瀏覽器後臺服務器群集，並在群集服務器上配置Symantec證書
upstream msiebackend {
server 192.168.1.1;
server 192.168.1.2;
server 192.168.1.3;
}
######配置Chrome瀏覽器後臺服務器群集，並在群集服務器上配置GlobalSign證書
upstream chromebackend {
server 192.168.1.4;
server 192.168.1.5;
server 192.168.1.6;
}
######配置Firefox瀏覽器後臺服務器群集，並在群集服務器上配置Symantec或其他證書
upstream mozillabackend {
server 192.168.1.7;
server 192.168.1.8;
server 192.168.1.9;
}最後，配置Porxy策略，將不同User Agent標識的客戶端瀏覽器導向到特定的後臺服務器上。示例如下：
server {
access_log logs/access.log;
error_log logs/error.log;
listen 80 default;
server_name baidu.com www.baidu.com; ## 代理轉發站點的域名
location / {
proxy_pass https://msiebackend; ## 默認使用Symantec證書
if ($http_user_agent ~ Chrome ) {
proxy_pass https://chromebackend; ## 為Chrome瀏覽器啟用GlobalSign證書
}
if ($http_user_agent ~ Mozilla ) {
proxy_pass https://mozillabackend; ## 為Firefox 瀏覽器啟用Symantec或其他證書
}
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
...s
}完成以上配置後，重啟Nginx，用不同瀏覽器客戶端嘗試訪問您的站點，測試證書的部署策略是否生效。
如果再深入細緻的對User Agent進行策略定製，將可以更細緻的控制客戶端的訪問代理。
END