隨着網絡安全形勢越來越嚴峻，整個互聯網界似乎已經達成了共識：那就是盡一切可能提高網站的安全性。安全技術有很多，其中SSL/TLS非對稱加密技術及對應的PKI公鑰架構體系又是最重要的技術之一。由於其技術分支較爲複雜，這裏僅就幾個知識點做一下展開，以期幫助讀者更好的理解SSL。
術語：SSL、TLS、HTTPS三者，儘管確切含義各不相同，但它們作爲非對稱加密技術的代表術語，很多語境下都可以互相替換。
給網站申請https證書的過程是怎樣的？
在展開這個題目之前，先回顧一下PKI架構。user, server, CA，這三者是PKI中的三個角色。user方接收到server發出的證書，並通過user自身客戶端（瀏覽器或者其他APP等程序）內含的已信任CA（根證書）列表來做校驗，只有證實該server提供的https證書是已信任CA簽發的，https通信纔可以繼續。
所以我們的https證書必須是主流CA簽發的才行。爲什麼強調“主流”？因爲不同瀏覽器使用的已信任CA列表可能是不盡相同的。IE，firefox，chrome，都帶有自己的根證書集合。大型電子商務網站必然使用最爲知名的CA機構，例如verisign (已被symantec收購）、enTrust等等。
申請證書時候，需要給CA機構提供證書籤發申請CSR文件(certificate sigining request)。大部分支持https的web服務程序都可以生成CSR文件。步驟如下：
1. 根據RSA算法生成公鑰私鑰對。私鑰即需要機密保管的以.key爲後綴名的文件，公鑰則在.csr文件中。csr文件中還包括生成CSR過程中輸入的組織名、域名、聯繫人郵箱等信息。
2. 發送CSR文件給證書供應商，比如verisign。供應商對CSR文件做處理，設置有效期限等，並做最爲關鍵的動作：用供應商自己的私鑰對證書進行簽名。這樣就生成了一張有效的SSL證書。
3. 用戶收到證書後，在web服務器（或負載均衡等設備）上，以此前的私鑰文件和收到的公鑰證書爲密鑰對，生成SSL配置文件，並綁定到對應的web站點上。
客戶端是怎麼驗證https證書並確保加密通信是安全的呢？
以web訪問爲例：
1. 客戶啓動瀏覽器程序，訪問某個https加密站點。
2. 瀏覽器嘗試SSL握手，發送自身支持的各類加密算法的列表，同時從站點獲得對方的支持算法列表及該站點的證書。
3. 瀏覽器讀取證書的數字簽名部分，用自身根證書列表中對應的公鑰證書對其進行解密。如果解密成功，並且證書哈希值與簽名內的哈希值匹配一致，可證明站點提供的證書確實是該CA根證書籤發的。此所謂“不可抵賴性”（non-repudiation)。
由於瀏覽器自身的根證書是隨着瀏覽器程序安裝而默認獲得的，所以其安全性就取決於瀏覽器提供商的安全監管機制。難怪google等公司會嚴格監控internet上可能出現的CA舞弊行爲。具體案例請見下一小節。
中級(intermediate)證書是怎麼回事？
SSL支持證書鏈，所以可以從一張根證書籤發一張中級證書（可能繼續簽發第二、第三級中級證書），最後到終端證書。這主要有以下幾個方面的考慮：
1. 擴展性：根據不同的服務級別，使用不同的中級證書的私鑰簽發終端證書。
2. 風險隔離：任一張中級證書的私鑰被盜，可以立即吊銷(revoke)這張中級證書，而其他中級證書可以保持安全性不受影響。
3. 商業授權：根證書廠商簽發中級證書給二級證書廠商（即授權），二級廠商可以簽發終端證書給自己的客戶。這裏面存在安全監管的問題。去年和今年陸續出現了法國信息系統安全局（ANSSI）和中國CNNIC授權的中級證書廠商惡意（自稱“無意”）簽發了google域名的證書的重大安全事件。
ANSSI的事件，據其自稱是“使用不當，用自己運營的公網CA根證書對內部私網環境簽發了google域名的證書給內部測試使用”。但顯然這種辯解是站不住腳的。這張證書是否能用在公網上，完全只取決於用哪張CA根證書籤發。用了公網CA根證書（即屬於瀏覽器默認配置的根證書集）做簽發，則必定可以在公網上使用。只要建立一個釣魚站點綁定這張舞弊證書，再加上DNS劫持（這個很容易做到），用戶的google加密信息全部可以被盜取。真的很怕怕。怪不得微軟、谷歌等公司迅速通過各種途徑吊銷（revoke）了這張舞弊證書。
CNNIC事件也是類似。其簽發了一張中級證書給埃及一家公司，後者違規簽發了google.com域名的證書。由於SSL證書鏈的設計，只要信任了CNNIC根證書的用戶，也隨之會信任這張埃及公司的舞弊證書。當然了，CNNIC也隨之被chrome等瀏覽器開除了。
小夥伴們，中級證書的重要性不亞於根證書啊。
中級證書示例：
此外，還要提一下EV(extended validation)證書。這也是一種中級證書，並且從瀏覽器表現上顯得更”安全“一些。以chrome瀏覽器爲例，使用EV證書的站點，它的站點名左側的安全圖標是綠色帶框的，跟普通的中級證書籤發的站點（綠色不帶框）略有不同。算法上EV跟其他中級證書完全一致。能否體現“更安全”的圖標，也取決於瀏覽器的支持。可以理解爲網站購買了CA供應商的VIP服務，並不表示證書一定在算法上更安全。算法安全性方面的問題，客官請往下看。
爲什麼我升級了SSL證書到SHA256算法，但瀏覽器裏還是顯示SHA1？
-- 證書算法安全性與站點的SSL/TLS算法安全性的區別
加密算法流派衆多，確實很容易混淆。即使有一定經驗的IT工程師依然會分不清哪些算法是證書提供的，哪些是站點本身提供的。
RSA：證書提供。非對稱加密算法。SSL證書大部分使用此算法生成公鑰私鑰對。用於對SSL/TLS會話中的對稱祕鑰進行加密/解密。RSA2048bit算法很安全，目前不需要升級或替換。
MD5/SHA1/SHA2：證書提供。散列/哈希/摘要算法。用於驗證簽名真實性。按安全性來排序，MD5<SHA1<SHA2。由於SHA1可能近年內就被破解（或者已經破解但未有公開報告），各大瀏覽器廠商已經要求CA機構和互聯網公司儘快升級到SHA2簽名證書。此外還有一個很接近的fingerprint指紋算法（一般使用SHA1），這個是客戶端瀏覽器對證書整體做的摘要算法，用於瀏覽器內部證書管理，跟簽名算法無關。
DES/AES：站點提供。對稱加密算法。用於實際的數據加密傳輸。對稱算法的祕鑰一般稱爲cipher，以顯示跟口令(password)、私鑰(private key)的區別。展開來說，對稱加密算法在SSL/TLS裏實現的時候還是很複雜的，一般可能的cipher算法有（僅舉幾例）：
SSL3-DES-CBC3-SHA #SSL3協議，DES對稱加密使用CBC3塊加密模式（另一種是流加密），SHA摘要算法
TLS1-AES-128-CBC-SHA #TLS1協議，AES對稱加密使用CBC塊加密模式，SHA摘要算法
具體使用何種對稱加密算法，取決於SSL握手時候的協商結果。
SSL加密傳輸過程中，非對稱祕鑰用於對“對稱祕鑰”的加密，而信息本身用對稱祕鑰進行加密。這是因爲：
對稱加密：計算資源消耗低，但祕鑰無法安全傳輸
非對稱加密：計算資源消耗高，但祕鑰可以安全傳輸
所以爲了折中這對矛盾，SSL/TLS採用了現在的方案：用非對稱加密來傳輸對稱祕鑰，用對稱祕鑰對數據進行加密。這就平衡了安全性和計算資源消耗性的這對蹺蹺板。
怎樣查看SSL證書的詳細信息？
除了用瀏覽器本身的圖形化界面方式查看信息，還可以用openssl命令工具查看更多內容。以雅虎網站爲例。查看其證書信息的命令：
openssl s_client -connect www.yahoo.com:443 | openssl x509 -text
在上面的輸出中，我們看到其簽名算法是SHA1，公鑰加密算法是RSA。公鑰長度是2048位，這個也是目前推薦的祕鑰長度。託摩爾定律的福，計算機性能不斷飛速發展，以前（當然也包括現在）在用的1024位的RSA祕鑰已經不太安全了。各大瀏覽器即將在2015年停止支持1024位RSA證書。而CA廠商方面，這兩年已經停止簽發RSA1024位的證書。
查看SSL握手信息（比如cipher協商結果），可以直接運行：
openssl s_client -connect www.yahoo.com:443 
也可以看到，此次SSL握手協商好的cipher算法是ECDHE-RSA-AES128-GCM-SHA256。好長的名字，一看就安全感倍增啊。
搞清楚了這些，在當前簽名算法從SHA1向SHA2升級的日子裏，看到瀏覽器信息裏顯示證書的“指紋算法爲SHA1”也不用感到疑惑了！
