衆所周知，WEB服務存在http和https兩種通信方式，http默認採用80作爲通訊端口，對於傳輸採用不加密的方式，https默認採用443，對於傳輸的數據進行加密傳輸
目前主流的網站基本上開始默認採用HTTPS作爲通信方式，一切的考慮都基於對安全的要求，那麼如何對自己的網站配置HTTPS通信，是本文着重介紹的
本文的主要內容包括：https加密傳輸的原理、如何申請https所用的CA證書，如何配置WEB服務支持https
1、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要使客戶端與服務器端的通信過程得到安全保證，必須使用的對稱加密算法，但是協商對稱加密算法的過程，需要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與服務器不直接使用公鑰，而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協商出一個對稱加密算法，就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通信安全問題。