HTTPS原理和CA證書申請（滿滿的乾貨）

衆所周知，WEB服務存在http和https兩種通訊方式，http默認採用80做爲通信端口，對於傳輸採用不加密的方式，https默認採用443，對於傳輸的數據進行加密傳輸

目前主流的網站基本上開始默認採用HTTPS做爲通訊方式，一切的考慮都基於對安全的要求，那麼如何對本身的網站配置HTTPS通訊，是本文着重介紹的

本文的主要內容包括：https加密傳輸的原理、如何申請https所用的CA證書，如何配置WEB服務支持https

一、https原理通俗講解

https=http+ssl，顧名思義，https是在http的基礎上加上了SSL保護殼，信息的加密過程就是在SSL中完成的

首先咱們先不談https，先從一個簡單的通信原理圖講起：

http通訊原理

客戶端發送一句client hello給服務器端，服務器端返回一句serverhello給客戶端，鑑於本文討論是https的加密主題，咱們只討論信息傳輸的加密問題

實現客戶端和服務端發送的信息client hello 和server hello，即便中間的包被竊取了，也沒法解密傳輸的內容

http：client hello和server hello在通信的過程當中，以明文的形式進行傳輸，採用wireshark抓包的效果以下圖：

有沒有感受這個的信息傳輸是徹底暴露在互聯網上面，你請求的全部信息均可以被窺測到，是否是感受心一涼，不過不用擔憂，咱們的安全信息如今都是採用https的傳輸，後面講到https的時候你們內心會頓時輕鬆。但這不是最關鍵的，http的傳輸最大的隱患是信息劫持和篡改，以下圖：

能夠看到，http的信息傳輸中，信息很容易被×××給劫持，更有甚者，×××能夠假裝服務器將篡改後的信息返回給用戶，試想一下，若是×××劫持的是你的銀行信息，是否是很可怕。因此對於http傳出存在的問題能夠總結以下：

（1）信息篡改：修改通訊的內容

（2）信息劫持：攔截到信息通訊的內容

這些是http不安全的體現，說完http，咱們回到本文的主題https，看下人家是怎麼保護信息的，全部的請求信息都採用了TLS加密，若是沒有祕鑰是沒法解析傳輸的是什麼信息

對於加密傳輸存在對稱加密和非對稱加密

 

對稱加密

對稱加密傳輸

當客戶端發送Hello字符串的時候，在進行信息傳輸前，採用加密算法（上圖中的祕鑰S）將hello加密程JDuEW8&*21!@#進行傳輸，即便中間被×××劫持了，若是沒有對應的祕鑰S也沒法知道傳出的信息爲什麼物，在上圖中信息的加密和解密都是經過同一個祕鑰進行的，對於這種加密咱們稱之爲對稱加密，只要A和B之間知道加解密的祕鑰，任何第三方都沒法獲取祕鑰S，則在必定條件下，基本上解決了信息通訊的安全問題。但在現實的狀況下（www），實際的通信模型遠比上圖複雜，下圖爲實際的通訊模型

server和全部的client都採用同一個祕鑰S進行加解密，但你們思考下，若是這樣的話，無異於沒有加密，請作下思考

因爲server和全部的client都採用同一個祕鑰S，則×××們做爲一個client也能夠獲取到祕鑰S，欲蓋彌彰。因此在實際的通信中，通常不會採用同一個祕鑰，而是採用不一樣的祕鑰加解密，以下圖

經過協商的方式獲取不一樣的祕鑰

如上圖，A和server通訊採用對稱加密A算法，B和server通訊採用對稱祕鑰B算法，所以能夠很好的解決了不一樣的客戶端採用相同的祕鑰進行通信的問題

那如今又存在問題了，A經過明文傳輸和server協商採用了加密算法A，但這條信息自己是沒有加密的，所以×××們仍是能夠竊取到祕鑰的，整個的通信仍然存在風險。那該如何處理呢？有人說，把這條信息（協調祕鑰的過程）再次加密，那是否是還要協商加密祕鑰，如此反覆，永無止境。從根本上沒法解決信息通信的安全問題

 

 

如何對協商過程進行加密

非對稱加密原理圖

在密碼學跟對稱加密一塊兒出現的，應用最廣的加密機制「非對稱加密」，如上圖，特色是私鑰加密後的密文，只要是公鑰，均可以解密，可是反過來公鑰加密後的密文，只有私鑰能夠解密。私鑰只有一我的有，而公鑰能夠發給全部的人。

基於上述的特色，咱們能夠得出以下結論：

（1）公鑰是開放給全部人的，但私鑰是須要保密的，存在於服務端

（2）服務器端server向client端（A、B.....）的信息傳輸是不安全的：由於全部人均可以獲取公鑰

（3）但client端（A、B.....）向server端的信息傳輸確實安全的：由於私鑰只有server端存在

所以，如何協商加密算法的問題，咱們解決了，非對稱加密算法進行對稱加密算法協商過程。

 

在這裏咱們作個小結：
信息通訊採用http是不安全的，存在信息劫持、篡改的風險，https是加密傳輸，是安全的通訊，對於https加密的過程，咱們首先介紹的對稱加密，採用對稱加密進行通訊存在祕鑰協商過程的不安全性，所以咱們採用了非對稱加密算法解決了對協商過程的加密，所以https是集對稱加密和非對稱加密爲一體的加密過程

 

 

安全的獲取公鑰

 

細心的人可能已經注意到了若是使用非對稱加密算法，咱們的客戶端A，B須要一開始就持有公鑰，要不無法開展加密行爲啊。

這下，咱們又遇到新問題了，如何讓A、B客戶端安全地獲得公鑰？

client獲取公鑰最最直接的方法是服務器端server將公鑰發送給每個client用戶，但這個時候就出現了公鑰被劫持的問題，如上圖，client請求公鑰，在請求返回的過程當中被×××劫持，那麼咱們將採用劫持後的假祕鑰進行通訊，則後續的通信過程都是採用假祕鑰進行，數據庫的風險仍然存在。在獲取公鑰的過程當中，咱們又引出了一個新的話題：如何安全的獲取公鑰，並確保公鑰的獲取是安全的， 那就須要用到終極武器了：SSL 證書（須要購買）和CA機構

如上圖所示，在第 ② 步時服務器發送了一個SSL證書給客戶端，SSL 證書中包含的具體內容有證書的頒發機構、有效期、公鑰、證書持有者、簽名，經過第三方的校驗保證了身份的合法，解決了公鑰獲取的安全性

以瀏覽器爲例說明以下整個的校驗過程：

（1）首先瀏覽器讀取證書中的證書全部者、有效期等信息進行一一校驗

（2）瀏覽器開始查找操做系統中已內置的受信任的證書發佈機構CA，與服務器發來的證書中的頒發者CA比對，用於校驗證書是否爲合法機構頒發 

（3）若是找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。

（4）若是找到，那麼瀏覽器就會從操做系統中取出  頒發者CA  的公鑰，而後對服務器發來的證書裏面的簽名進行解密

（5）瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值，將這個計算的hash值與證書中籤名作對比

（6）對比結果一致，則證實服務器發來的證書合法，沒有被冒充

（7）此時瀏覽器就能夠讀取證書中的公鑰，用於後續加密了

 

 

至此第一部分關於HTTPS的原理介紹已經結束了，總結一下：

HTTPS要使客戶端與服務器端的通訊過程獲得安全保證，必須使用的對稱加密算法，可是協商對稱加密算法的過程，須要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程自己也不安全，會有中間人篡改公鑰的可能性，因此客戶端與服務器不直接使用公鑰，而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程自己的安全。這樣經過這些機制協商出一個對稱加密算法，就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通訊安全問題。