HTTPS原理和CA證書申請（轉）
原文地址：http://blog.51cto.com/11883699/2160032
眾所周知，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&*
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要使客戶端與伺服器端的通訊過程得到安全保證，必須使用的對稱加密演算法，但是協商對稱加密演算法的過程，需要使用非對稱加密演算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與伺服器不直接使用公鑰，而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協商出一個對稱加密演算法，就此雙方使用該演算法進行加密解密。從而解決了客戶端與伺服器端之間的通訊安全問題。
2、證書獲取的方式
由於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的申請是深入瞭解
3、配置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"/>