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

 

---

二、證書獲取的方式

因爲HTTPS涉及到中間機構的校驗，且這個校驗的過程不是無償的，須要收費，由於須要像第三方機構申請CA證書，用來完成身份的驗證過程，這個過程也就是證書申請的過程，本章節爲實戰，具備實際的指導意義。

CA證書獲取的渠道

現現在不比之前了，雲服務的概念不只從理論上深刻到了互聯網應用，並且變成了一個社會的基礎設施工做，世界雲服務3A：亞馬遜AWS、微軟Azure、阿里雲，阿里雲做爲國人的驕傲躋身世界三大雲服務廠商，且在國內，阿里雲的市場份過半，且阿里雲的操做系統「飛天系統」爲自主研發，而不是採用開源的OpenStack。所以這些雲服務廠商都提供了友好的CA證書申請流程，本文只以阿里雲、騰訊雲、AlphaSSL進行說明申請的流程

（1）、阿里雲

登陸阿里雲控制檯（https://www.aliyun.com/）在安全找到SSL證書，以下圖：

找到購買證書，進入以下流程：

阿里雲現提供4家主流的國際認證機構，其實經過阿里雲進行證書的申請，能夠理解爲由阿里雲代理，幫你申請證書。對於證書有單一域名和通配符域名證書，顧名思義，單一域名的證書，獲取的證書只能驗證指定的一個域名的安全性，但通配符域名（如*.aa.com）全部的以*.aa.com開始的域名均可以識別，固然這裏面涉及到DV SSL 、 OV SSL 、EV SSL的概念，由於在買以前必定要知道這個概念的意義，不然錢花的會不知所然。

DV SSL

DV SSL證書是隻驗證網站域名全部權的簡易型（Class 1級）SSL證書，可10分鐘快速頒發，能起到加密傳輸的做用，但沒法向用戶證實網站的真實身份。

目前市面上的免費證書都是這個類型的，只是提供了對數據的加密，可是對提供證書的我的和機構的身份不作驗證。

OV SSL

OV SSL,提供加密功能,對申請者作嚴格的身份審覈驗證,提供可信×××明。

和DV SSL的區別在於，OV SSL 提供了對我的或者機構的審覈，能確認對方的身份，安全性更高。

因此這部分的證書申請是收費的~

EV SSL

超安=EV=最安全、最嚴格 超安EV SSL證書遵循全球統一的嚴格身份驗證標準，是目前業界安全級別最高的頂級 (Class 4級)SSL證書。

金融證券、銀行、第三方支付、網上商城等，重點強調網站安全、企業可信形象的網站，涉及交易支付、客戶隱私信息和帳號密碼的傳輸。

這部分的驗證要求最高，申請費用也是最貴的。

 

根據保護域名的數量需求，SSL證書又分爲：

單域名版：只保護一個域名，例如 www.abc.com 或者 login.abc.com 之類的單個域名

多域名版：一張證書能夠保護多個域名，例如同時保護 www.abc.com , www.bcd.com, pay.efg.com 等

通配符版：一張證書保護同一個主域名下同一級的全部子域名，不限個數，形如 *.abc.com 。注意，通配符版只有 DVSSL 和 OVSSL 具備， EVSSL 不具備通配符版本。

 

 

阿里雲目前已經不提供免費的SSL證書，即DV SSL，但目前國內能夠提供免費的SSL證書的雲廠商有騰訊雲，至於何時收費，筆者暫時不太清楚，但至少這個時期是OK的

 

騰訊雲

登陸騰訊雲控制檯（https://cloud.tencent.com），找到SSL證書，以下圖：

進入購買頁面，找到域名型免費性（DV），點擊「免費申請」

進入域名驗證環節，須要注意：通用域名必須是指定的一個明確的域名地址，不能是通配域名，其次私鑰密碼在申請的過程當中是選填，但在國外網站申請的時候確實必填

選在驗證方式，筆者通常會經過文件的方式，直接經過nginx建立一個文件目錄，進行通訊就能夠完成身份的驗證，具體的驗證過程能夠參考騰訊雲的詳細說明。

等待審覈經過，通常在1-3小時的時間

筆者在申請的過程當中是採用的國外的網站，提及來就是一把辛酸淚，由於國外的操做習慣和國人的習慣有很大的差別，且直接走國外申請須要填寫的信息不少，但也有好處，便宜。具筆者計算，一個統配域名在國外買在1800人民幣的樣子，但在國內購買須要2500以上。接下來重點介紹AlphaSSL購買流程

 

 

AlphaSSL

申請網址：https://www.alphassl.com/ssl-certificates/select-region/

（1）：選擇所在區域，此處選擇other（國外沒有將Asia做爲一個明確的區域標識氣憤，但誰讓咱們技不如人呢）

（2）產品詳情：此處注意購買統配的域名，這個買起來更划算。

（3）基本信息的填寫，沒有什麼須要注意的

（4）CSR這個步驟是最容易出錯，且不太能讓人理解的地方，筆者在這裏作個簡單的普及。

CSR(證書請求文件) 包含申請證書所須要的相關信息，其中最重要的是域名，填寫的域名必須是你要https方式訪問的那個域名。如abc.com 或 web.abc.com，其中CSR生成的方式不少，筆者直接用了網上的一個生成網站：https://myssl.com/csr_create.html

填寫好相關的信息，尤爲是域名信息必定要正確，能夠根據生成的方式進行生成，生成以後產生了2個文件，一個爲CSR文件，用來向CA機構申請的文件，通常以CSR結尾，一個是KEY文件，這個文件必定要保存好，這個文件就是對應第一章節將的server端的私鑰，這個信息首先是重要，若是這個KEY文件沒有保存好，是沒法找回的，由於KEY生成的過程不可逆，即便填寫的過程都同樣，生成的KEY是不通的，具備隨機性

https://support.globalsign.com/customer/portal/articles/1223116

將生成的CRS粘貼進入第四步點擊下一步就進入了付款環節，因爲是國外購買，因此必須使用VISA的信用卡。通常付款以後，6小時左右證書就能夠下來。固然筆者在申請的過程當中就把KEY文件給丟了，致使找客服（英文對話，覈實身份），其實若是申請存在問題，7天內是能夠申請退款，其次若是你把KEY文件丟失了，能夠經過找客服進行更新，詳細能夠參考：https://support.globalsign.com/customer/portal/articles/1223116

 

至此，對於第二章節的SSL申請過程就講解 完畢，是否是很詳細，筆者但是走了不少的坑，但對於SSL的申請是深刻了解

 

---

 

 

 

三、配置WEB服務支持https

經過第一章節HTTPS的原理講解和第二章節對申請的介紹，到了咱們在WEB服務器端配置支持HTTPS，因爲筆者是採用的nginx+tomcat的架構方式，所以配置的方式以nginx+tomcat的方式進行講解

在nginx的配置文件中，新增以下配置項，在這個地方有一個參數：ssl on，若是這個參數開啓，http和https將不能共存。裏面對應的信息均可以經過CA機構獲取到

listen 443 ssl;
        ssl_certificate     /iyunwen/server/ssl/20180731.cer;
        ssl_certificate_key /iyunwen/server/ssl/20180731.key;
        ssl_prefer_server_ciphers on;
        ssl_session_timeout 10m;
        ssl_session_cache shared:SSL:10m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4";

 

這裏給出了阿里雲SSL在主流apache、nginx的配置文檔：https://help.aliyun.com/video_detail/54216.html?spm=a2c4g.11186623.4.1.WbwjQN

騰訊雲SSL配置文檔：https://cloud.tencent.com/document/product/400/4143

 

但配置nginx以後，對於tomcat須要在配置文件conf/server.xml文件中新增以下內容

<Valve className="org.apache.catalina.valves.RemoteIpValve"  
            remoteIpHeader="X-Forwarded-For"  
            protocolHeader="X-Forwarded-Proto"  
            protocolHeaderHttpsValue="https"/>

 

至此關於HTTPS的全部內容已經結束。