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

vnxy001 2019-02-28

展開全文

眾所周知，WEB服務存在http和https兩種通信方式，http默認采用80作為通訊端口，對于傳輸采用不加密的方式，https默認采用443，對于傳輸?shù)臄?shù)據(jù)進行加密傳輸

目前主流的網站基本上開始默認采用HTTPS作為通信方式，一切的考慮都基于對安全的要求，那么如何對自己的網站配置HTTPS通信，是本文著重介紹的

本文的主要內容包括：https加密傳輸?shù)脑怼⑷绾紊暾坔ttps所用的CA證書，如何配置WEB服務支持https

1、https原理通俗講解

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

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

圖片.png

http通信原理

客戶端發(fā)送一句client hello給服務器端，服務器端返回一句serverhello給客戶端，鑒于本文討論是https的加密主題，我們只討論信息傳輸?shù)募用軉栴}

實現(xiàn)客戶端和服務端發(fā)送的信息client hello 和server hello，即使中間的包被竊取了，也無法解密傳輸?shù)膬热?/span>

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

圖片.png

有沒有感覺這個的信息傳輸是完全暴露在互聯(lián)網上面，你請求的所有信息都可以被窺測到，是不是感覺心一涼，不過不用擔心，我們的安全信息現(xiàn)在都是采用https的傳輸，后面講到https的時候大家心里會頓時輕松。但這不是最關鍵的，http的傳輸最大的隱患是信息劫持和篡改，如下圖：

可以看到，http的信息傳輸中，信息很容易被×××給劫持，更有甚者，×××可以偽裝服務器將篡改后的信息返回給用戶，試想一下，如果×××劫持的是你的銀行信息，是不是很可怕。所以對于http傳出存在的問題可以總結如下：

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

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

這些是http不安全的體現(xiàn)，說完http，我們回到本文的主題https，看下人家是怎么保護信息的，所有的請求信息都采用了TLS加密，如果沒有秘鑰是無法解析傳輸?shù)氖鞘裁葱畔?br>

圖片.png

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

對稱加密

圖片.png

對稱加密傳輸

當客戶端發(fā)送Hello字符串的時候，在進行信息傳輸前，采用加密算法（上圖中的秘鑰S）將hello加密程JDuEW8&*21!@#進行傳輸，即使中間被×××劫持了，如果沒有對應的秘鑰S也無法知道傳出的信息為何物，在上圖中信息的加密和解密都是通過同一個秘鑰進行的，對于這種加密我們稱之為對稱加密，只要A和B之間知道加解密的秘鑰，任何第三方都無法獲取秘鑰S，則在一定條件下，基本上解決了信息通信的安全問題。但在現(xiàn)實的情況下（www），實際的通訊模型遠比上圖復雜，下圖為實際的通信模型

圖片.png

server和所有的client都采用同一個秘鑰S進行加解密，但大家思考下，如果這樣的話，無異于沒有加密，請做下思考

由于server和所有的client都采用同一個秘鑰S，則×××們作為一個client也可以獲取到秘鑰S，此地無銀三百兩。所以在實際的通訊中，一般不會采用同一個秘鑰，而是采用不同的秘鑰加解密，如下圖

通過協(xié)商的方式獲取不同的秘鑰

如上圖，A和server通信采用對稱加密A算法，B和server通信采用對稱秘鑰B算法，因此可以很好的解決了不同的客戶端采用相同的秘鑰進行通訊的問題

那現(xiàn)在又存在問題了，A通過明文傳輸和server協(xié)商采用了加密算法A，但這條信息本身是沒有加密的，因此×××們還是可以竊取到秘鑰的，整個的通訊仍然存在風險。那該如何處理呢？有人說，把這條信息（協(xié)調秘鑰的過程）再次加密，那是不是還要協(xié)商加密秘鑰，如此反復，永無止境。從根本上無法解決信息通訊的安全問題

如何對協(xié)商過程進行加密

非對稱加密原理圖

在密碼學跟對稱加密一起出現(xiàn)的，應用最廣的加密機制“非對稱加密”，如上圖，特點是私鑰加密后的密文，只要是公鑰，都可以解密，但是反過來公鑰加密后的密文，只有私鑰可以解密。私鑰只有一個人有，而公鑰可以發(fā)給所有的人。

基于上述的特點，我們可以得出如下結論：

（1）公鑰是開放給所有人的，但私鑰是需要保密的，存在于服務端

（2）服務器端server向client端（A、B.....）的信息傳輸是不安全的：因為所有人都可以獲取公鑰

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

因此，如何協(xié)商加密算法的問題，我們解決了，非對稱加密算法進行對稱加密算法協(xié)商過程。

在這里我們做個小結：
信息通信采用http是不安全的，存在信息劫持、篡改的風險，https是加密傳輸，是安全的通信，對于https加密的過程，我們首先介紹的對稱加密，采用對稱加密進行通信存在秘鑰協(xié)商過程的不安全性，因此我們采用了非對稱加密算法解決了對協(xié)商過程的加密，因此https是集對稱加密和非對稱加密為一體的加密過程

安全的獲取公鑰

細心的人可能已經注意到了如果使用非對稱加密算法，我們的客戶端A，B需要一開始就持有公鑰，要不沒法開展加密行為啊。

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

client獲取公鑰最最直接的方法是服務器端server將公鑰發(fā)送給每一個client用戶，但這個時候就出現(xiàn)了公鑰被劫持的問題，如上圖，client請求公鑰，在請求返回的過程中被×××劫持，那么我們將采用劫持后的假秘鑰進行通信，則后續(xù)的通訊過程都是采用假秘鑰進行，數(shù)據(jù)庫的風險仍然存在。在獲取公鑰的過程中，我們又引出了一個新的話題：如何安全的獲取公鑰，并確保公鑰的獲取是安全的，那就需要用到終極武器了：SSL 證書（需要購買）和CA機構

SSL證書.png

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

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

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

（2）瀏覽器開始查找操作系統(tǒng)中已內置的受信任的證書發(fā)布機構CA，與服務器發(fā)來的證書中的頒發(fā)者CA比對，用于校驗證書是否為合法機構頒發(fā)

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

（4）如果找到，那么瀏覽器就會從操作系統(tǒng)中取出頒發(fā)者CA 的公鑰，然后對服務器發(fā)來的證書里面的簽名進行解密

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

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

（7）此時瀏覽器就可以讀取證書中的公鑰，用于后續(xù)加密了

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

HTTPS要使客戶端與服務器端的通信過程得到安全保證，必須使用的對稱加密算法，但是協(xié)商對稱加密算法的過程，需要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與服務器不直接使用公鑰，而是使用數(shù)字證書簽發(fā)機構頒發(fā)的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協(xié)商出一個對稱加密算法，就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通信安全問題。

2、證書獲取的方式

由于HTTPS涉及到中間機構的校驗，且這個校驗的過程不是無償?shù)模枰召M，因為需要像第三方機構申請CA證書，用來完成身份的驗證過程，這個過程也就是證書申請的過程，本章節(jié)為實戰(zhàn)，具有實際的指導意義。

CA證書獲取的渠道

現(xiàn)如今不比以前了，云服務的概念不僅從理論上深入到了互聯(lián)網應用，而且變成了一個社會的基礎設施工作，世界云服務3A：亞馬遜AWS、微軟Azure、阿里云，阿里云作為國人的驕傲躋身世界三大云服務廠商，且在國內，阿里云的市場份過半，且阿里云的操作系統(tǒng)“飛天系統(tǒng)”為自主研發(fā)，而不是采用開源的OpenStack。因此這些云服務廠商都提供了友好的CA證書申請流程，本文只以阿里云、騰訊云、AlphaSSL進行說明申請的流程

（1）、阿里云

登錄阿里云控制臺（https://www.aliyun.com/）在安全找到SSL證書，如下圖：

圖片.png

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

圖片.png

阿里云現(xiàn)提供4家主流的國際認證機構，其實通過阿里云進行證書的申請，可以理解為由阿里云代理，幫你申請證書。對于證書有單一域名和通配符域名證書，顧名思義，單一域名的證書，獲取的證書只能驗證指定的一個域名的安全性，但通配符域名（如*.aa.com）所有的以*.aa.com開始的域名都可以識別，當然這里面涉及到DV SSL 、 OV SSL 、EV SSL的概念，因為在買之前一定要知道這個概念的意義，否則錢花的會不知所然。

DV SSL

DV SSL證書是只驗證網站域名所有權的簡易型（Class 1級）SSL證書，可10分鐘快速頒發(fā)，能起到加密傳輸?shù)淖饔?，但無法向用戶證明網站的真實身份。

目前市面上的免費證書都是這個類型的，只是提供了對數(shù)據(jù)的加密，但是對提供證書的個人和機構的身份不做驗證。

OV SSL

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

和DV SSL的區(qū)別在于，OV SSL 提供了對個人或者機構的審核，能確認對方的身份，安全性更高。

所以這部分的證書申請是收費的~

EV SSL

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

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

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

圖片.png

根據(jù)保護域名的數(shù)量需求，SSL證書又分為：

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

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

通配符版：一張證書保護同一個主域名下同一級的所有子域名，不限個數(shù)，形如 *. 。注意，通配符版只有 DVSSL 和 OVSSL 具有， EVSSL 不具有通配符版本。

阿里云目前已經不提供免費的SSL證書，即DV SSL，但目前國內可以提供免費的SSL證書的云廠商有騰訊云，至于什么時候收費，筆者暫時不太清楚，但至少這個時期是OK的

騰訊云

登錄騰訊云控制臺（https://cloud.tencent.com），找到SSL證書，如下圖：

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

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

選在驗證方式，筆者一般會通過文件的方式，直接通過nginx創(chuàng)建一個文件目錄，進行通信就可以完成身份的驗證，具體的驗證過程可以參考騰訊云的詳細說明。

等待審核通過，一般在1-3小時的時間

筆者在申請的過程中是采用的國外的網站，說起來就是一把辛酸淚，因為國外的操作習慣和國人的習慣有很大的差異，且直接走國外申請需要填寫的信息很多，但也有好處，便宜。具筆者計算，一個統(tǒng)配域名在國外買在1800人民幣的樣子，但在國內購買需要2500以上。接下來重點介紹AlphaSSL購買流程

AlphaSSL

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

（1）：選擇所在區(qū)域，此處選擇other（國外沒有將Asia作為一個明確的區(qū)域標識氣憤，但誰讓我們技不如人呢）

圖片.png

（2）產品詳情：此處注意購買統(tǒng)配的域名，這個買起來更劃算。

圖片.png

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

圖片.png

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

圖片.png

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

填寫好相關的信息，尤其是域名信息一定要正確，可以根據(jù)生成的方式進行生成，生成之后產生了2個文件，一個為CSR文件，用來向CA機構申請的文件，一般以CSR結尾，一個是KEY文件，這個文件一定要保存好，這個文件就是對應第一章節(jié)將的server端的私鑰，這個信息首先是重要，如果這個KEY文件沒有保存好，是無法找回的，因為KEY生成的過程不可逆，即使填寫的過程都一樣，生成的KEY是不通的，具有隨機性

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

將生成的CRS粘貼進入第四步點擊下一步就進入了付款環(huán)節(jié)，由于是國外購買，所以必須使用VISA的信用卡。一般付款之后，6小時左右證書就可以下來。當然筆者在申請的過程中就把KEY文件給丟了，導致找客服（英文對話，核實身份），其實如果申請存在問題，7天內是可以申請退款，其次如果你把KEY文件丟失了，可以通過找客服進行更新，詳細可以參考：https://support./customer/portal/articles/1223116

至此，對于第二章節(jié)的SSL申請過程就講解完畢，是不是很詳細，筆者可是走了很多的坑，但對于SSL的申請是深入了解

3、配置WEB服務支持https

通過第一章節(jié)HTTPS的原理講解和第二章節(jié)對申請的介紹，到了我們在WEB服務器端配置支持HTTPS，由于筆者是采用的nginx+tomcat的架構方式，因此配置的方式以nginx+tomcat的方式進行講解

在nginx的配置文件中，新增如下配置項，在這個地方有一個參數(shù)：ssl on，如果這個參數(shù)開啟，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"/>

圖片.png

至此關于HTTPS的所有內容已經結束。