在日常互聯網瀏覽網頁時，我們接觸到的大多都是 HTTP 協議，這種協議是未加密，即明文的。這使得 HTTP 協議在傳輸隱私數據時非常不安全。因此，用於對 HTTP 協議傳輸進行數據加密，即 HTTPS 。
那么我們再訪問https網站時，大家知道https是安全數據加密傳輸，但是如果讓大家仔細描述從訪問打開一個網站。到數據整個加解密的流程，估計有很多朋友(可能哈)很難清晰的表達出來吧。
包括我自己描述的也會模擬兩可。在此非常有必要詳解下整個流程。
要點： https協議對傳輸內容進行加密，具有更強的安全性，防止被抓包后解析出請求內容。 https是建立在ssl之上的http協議。 服務器支持https協議必須安裝一套數字證書，所謂數字證書就是一對公鑰和私鑰，公鑰用來加密，私鑰用來解密。為了與下文中的私鑰進行區分，這里的公鑰和私鑰稱為公鑰1和私鑰1。 數字證書可以自己制作或者向組織申請，自己制作的會在客戶端彈出提示框，手動驗證通過，而申請的就無需客戶端手動驗證了。 請求過程： 1.客戶端訪問 https開頭的url 2.服務端返回公鑰1，客戶端驗證通過（如果不通過，則訪問終斷）。 3.客戶端根據公鑰1生成一個私鑰2，這個私鑰2用來加密和解密請求信息。使用公鑰1對私鑰2進行加密，回傳給服務端。服務端用私鑰1對該信息解密，得到私鑰2。至此，客戶端和服務端都已經有了私鑰2。 4.客戶端和服務端之間使用私鑰2對信息進行加密后通信，這樣即使第三方抓包，也無法輕易獲取通信內容了。 https的服務端部署： 1.搞定公鑰1和私鑰1（申請或者自己造一個）。 2.在nginx配置文件的server域中，配置公鑰1和私鑰1。
在互聯網安全通信方式上，目前用的最多的就是https配合ssl和數字證書來保證傳輸和認證安全了。本文追本溯源圍繞這個模式談一談。
名詞解釋
首先解釋一下上面的幾個名詞：
- https：在http(超文本傳輸協議)基礎上提出的一種安全的http協議，因此可以稱為安全的超文本傳輸協議。http協議直接放置在TCP協議之上，而https提出在http和TCP中間加上一層加密層。從發送端看，這一層負責把http的內容加密后送到下層的TCP，從接收方看，這一層負責將TCP送來的數據解密還原成http的內容。
- SSL(Secure Socket Layer)：是Netscape公司設計的主要用於WEB的安全傳輸協議。從名字就可以看出它在https協議棧中負責實現上面提到的加密層。因此，一個https協議棧大致是這樣的：
- 數字證書：一種文件的名稱，好比一個機構或人的簽名，能夠證明這個機構或人的真實性。其中包含的信息，用於實現上述功能。
- 加密和認證：加密是指通信雙方為了防止敏感信息在信道上被第三方竊聽而泄漏，將明文通過加密變成密文，如果第三方無法解密的話，就算他獲得密文也無能為力；認證是指通信雙方為了確認對方是值得信任的消息發送或接受方，而不是使用假身份的騙子，采取的確認身份的方式。只有同時進行了加密和認真才能保證通信的安全，因此在SSL通信協議中這兩者都被應用。
因此，這三者的關系已經十分清楚了：https依賴一種實現方式，目前通用的是SSL，數字證書是支持這種安全通信的文件。另外有SSL衍生出TLS和WTLS，前者是IEFT將SSL標准化之后產生的（TSL1.0），與SSL差別很小，后者是用於無線環境下的TSL。
如何加密
常用的加密算法
- 對稱密碼算法：是指加密和解密使用相同的密鑰，典型的有DES、RC5、IDEA（分組加密），RC4（序列加密）；
- 非對稱密碼算法：又稱為公鑰加密算法，是指加密和解密使用不同的密鑰（公開的公鑰用於加密，私有的私鑰用於解密）。比如A發送，B接收，A想確保消息只有B看到，需要B生成一對公私鑰，並拿到B的公鑰。於是A用這個公鑰加密消息，B收到密文后用自己的與之匹配的私鑰解密即可。反過來也可以用私鑰加密/公鑰解密。也就是說對於給定的公鑰有且只有與之匹配的私鑰可以解密，對於給定的私鑰，有且只有與之匹配的公鑰可以解密。典型的算法有RSA，DSA，DH；
- 散列算法：散列變換是指把文件內容通過某種公開的算法，變成固定長度的值（散列值），這個過程可以使用密鑰也可以不使用。這種散列變換是不可逆的，也就是說不能從散列值變成原文。因此，散列變換通常用於驗證原文是否被篡改。典型的算法有：MD5，SHA，Base64，CRC等。
在散列算法（也稱摘要算法）中，有兩個概念，強無碰撞和弱無碰撞。弱無碰撞是對給定的消息x，就是對你想偽造的明文，進行運算得出相同的摘要信息。也就是說你可以控制明文的內容。強無碰撞是指能找到相同的摘要信息，但偽造的明文是什么並不知道。
SSL的加密過程
需要注意的是非對稱加解密算法的效率要比對稱加解密要低的多。所以SSL在握手過程中使用非對稱密碼算法來協商密鑰，實際使用對稱加解密的方法對http內容加密傳輸。下面是對這一過程的形象的比喻（摘自http://blog.chinaunix.net/u2/82806/showart_1341720.html）：
假設A與B通信，A是SSL客戶端，B是SSL服務器端，加密后的消息放在方括號[]里，以突出明文消息的區別。雙方的處理動作的說明用圓括號（）括起。
A：我想和你安全的通話，我這里的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。
B：我們用DES－RSA－SHA這對組合好了。
這是我的證書，里面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。
A：（查看證書上B的名字是否無誤，並通過手頭早已有的數字的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告並斷開連接，這一步保證了B的公鑰的真實性）
（產生一份秘密消息，這份秘密消息處理后將用作對稱加密密鑰，加密初始化向量和hmac的密鑰。將這份秘密消息-協議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由於用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，並用你的公鑰加密了，給你（把ClientKeyExchange發給B）
注意，下面我就要用加密的辦法給你發消息了！
（將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說完了]
B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然后將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了）
注意，我也要開始用加密的辦法給你發消息了！
[我說完了]
A: [我的秘密是...]
B: [其它人不會聽到的...]
從上面的過程可以看到，SSL協議是如何用非對稱密碼算法來協商密鑰，並使用密鑰加密明文並傳輸的。還有以下幾點補充：
1.B使用數字證書把自己的公鑰和其他信息包裝起來發送A，A驗證B的身份，下面會談到A是如何驗證的。
2.A生成了了加密密鑰、加密初始化向量和hmac密鑰是雙方用來將明文摘要和加密的。加密初始化向量和hmac密鑰首先被用來對明文摘要（防止明文被篡改），然后這個摘要和明文放在一起用加密密鑰加密后傳輸。
3.由於只有B有私鑰，所以只有B可以解密ClientKeyExchange消息，並獲得之后的通信密鑰。
4.事實上，上述過程B沒有驗證A的身份，如果需要的話，SSL也是支持的，此時A也需要提供自己的證書，這里就不展開了。在設置IIS的SSL Require的時候，通常默認都是igore client certification的。
數字證書
由上面的討論可以知道，數字證書在ssl傳輸過程中扮演身份認證和密鑰分發的功能。究竟什么是數字證書呢？
簡而言之數字證書是一種網絡上證明持有者身份的文件，同時還包含有公鑰。一方面，既然是文件那么就有可能“偽造”，因此，證書的真偽就需要一個驗證方式；另一方面，驗證方需要認同這種驗證方式。
對於第一個需求，目前的解決方案是，證書可以由國際上公認的證書機構頒發，這些機構是公認的信任機構，一些驗證證書的客戶端應用程序：比如瀏覽器，郵件客戶端等，對於這些機構頒發的證書完全信任。當然想要請這些機構頒發證書可是要付“到了斯”的，通常在windows部署系統的時候會讓客戶端安裝我們自己服務器的根證書，這樣客戶端同樣可以信任我們的證書。
對於第二個需求，客戶端程序通常通過維護一個“根受信任機構列表”，當收到一個證書時，查看這個證書是否是該列表中的機構頒發的，如果是則這個證書是可信任的，否則就不信任。
證書的信任
因此作為一個https的站點需要與一個證書綁定，無論如何，證書總是需要一個機構頒發的，這個機構可以是國際公認的證書機構，也可以是任何一台安裝有證書服務的計算機。客戶端是否能夠信任這個站點的證書，首先取決於客戶端程序是否導入了證書頒發者的根證書。下圖說明了這個流程：
有時一個證書機構可能授權另一個證書機構頒發證書，這樣就出現了證書鏈。
IE瀏覽器在驗證證書的時候主要從下面三個方面考察，只要有任何一個不滿足都將給出警告
- 證書的頒發者是否在“根受信任的證書頒發機構列表”中
- 證書是否過期
- 證書的持有者是否和訪問的網站一致
另外，瀏覽器還會定期查看證書頒發者公布的“證書吊銷列表”，如果某個證書雖然符合上述條件，但是被它的頒發者在“證書吊銷列表”中列出，那么也將給出警告。每個證書的CRL Distribution Point字段顯示了查看這個列表的url。盡管如此，windows對於這個列表是“不敏感”的，也就是說windows的api會緩存這個列表，直到設置的緩存過期才會再從CRL Distribution Point中下載新的列表。目前，只能通過在證書頒發服務端盡量小的設置這個有效期（最小1天），來盡量使windows的客戶端“敏感”些。具體設置方法為（winserver2003）：
進入管理員工具->證書機構->右擊某個證書服務下的“吊銷的證書”目錄->屬性：
按圖中的設置，將CRL發布周期改為1天。
IIS中部署基於數字證書的https網站
在IIS6中構建一個https網站需要如下幾個關鍵步驟：
- 安裝CA認證服務：此步驟不是必要的。如果網絡中還沒有那台主機安裝過CA認證服務，或者確實需要建個新的CA認證服務，那么就需要在某台主機上安裝CA認證服務。這是windows自帶的功能，默認不安裝。如果裝了，就意味這這台主機具有頒發證書的能力，只要安裝有這台主機的根證書的客戶端會信任這台主機頒發的證書。在windows server 2003中的安裝步驟，詳見http://jeffyyko.blog.51cto.com/28563/140518
- 向CA認證服務提交證書申請，並將獲得的證書跟網站綁定：詳見http://jeffyyko.blog.51cto.com/28563/141322
- 要求客戶端導入根證書，以使客戶端信任該證書：詳見http://jeffyyko.blog.51cto.com/28563/142280
證書與密鑰
在ssl的加密過程一節中，我們知道要實現ssl加密通信，必須要雙方協商密鑰，ssl采用的是非對稱加密來實現密鑰交換。在這個過程中，服務端向客戶端發送的公鑰就包含在證書中。客戶端將自己生成的密鑰用公鑰加密，服務端用於公鑰匹配的私鑰解密。因此，可以想到的是，服務端保存了一個私鑰，並且也與https的站點綁定了。
綁定私鑰和不綁定私鑰的證書
從證書持有者是否擁有證書的私鑰，可以把證書分為兩種：如下圖，當我們的本機擁有證書的私鑰時如左圖，否則如右圖：
可以看到，左圖標識了“你擁有與該證書相匹配的私鑰”，而右圖沒有。對於需要與https站點綁定的證書必須是左圖的形式，分發給客戶端安裝的應該是右圖的形式，而不該是左圖的形式。
對於左圖的證書可以將還有導出含有私鑰的.pfx格式，用於備份證書或者分發，步驟如下：
選擇同時導出私鑰
這里輸入的密碼在重新安裝的時候要輸入，所以要comfirm一下。
選擇一個文件存放，后綴自動為.pfx
對於普通的證書，不能導出含有私鑰的.pfx形式，只能導出下面三種格式：
總結
本文總結了https/ssl/數字證書的相關基本概念，闡述了ssl協議的實現原理，闡述了數字證書在其中扮演的角色。如果有面試中有被詢問到的。可以深入了解下，