最近做CA證書這塊功能管理的時候，與PKI證書機構的交互，NGINX單向雙向服務配置，從APP端到NGINX到後臺已經可以正常的進行安全認證以及數據交互，也基本能理解單向認證和雙向認證原理。看了好多遍，但是隔幾天又忘了，感覺還是沒有喫透的樣子。讓人很難受，我這裏再借助一下其他大佬對單向認證和雙向認證原理的理解，幫自己鞏固一下對單向認證和雙向認證原理的認識。
原理基礎
數字證書爲發佈公鑰提供了一種簡便的途徑，其數字證書則成爲加密算法以及公鑰的載體，依靠數字證書，我們可以構建一個簡單的加密網絡應用平臺，數字證書就好比我們生活中的身份證，現實中，身份證由公安機關簽發，而網絡用戶的身份憑證由數字證書頒發認證機構—CA簽發，只有經過CA簽發的證書在網絡中才具備可認證性，CA並不是一個單純的防禦手段，它集合了多種密碼學算法：
消息摘要算法：MD5、和SHA（對數字證書本省做摘要處理，用於驗證數據完整性服務器）
對稱加密算法：RC2、RC4、IDEA、DES、AES（對數據進行加密/解密操作，用於保證數據保密性服務）
非對稱加密算法：RSA、DH（對數據進行加密/解密操作，用於保證數據保密性服務）
數字簽名算法：RSA、DSA(對數據進行簽名/驗證操作，保證數據的完整性和抗否認性)。
證書的簽發過程實際上是對申請數字證書的公鑰做數字簽名，證書的驗證過程實際上是對數字證書的公鑰做驗證簽名，其中還包含證書有效期驗證，通過CA數字證書，我們對網絡上傳輸的數據進行加密/解密和簽名/驗證操作，確保數據機密性、完整性、抗否認性、認證性，保證交易實體身份的真實性，保證網絡安全性。
編碼格式
所有證書有多種文件編碼格式，主要包括:
CER編碼(規範編碼格式)：是數字證書的一種編碼格式，它是BER(基本編碼格式)的一個變種，比BER規定得更嚴格
DER(卓越編碼格式)：同樣是BER的一個變種，與CER的不同在於，DER使用定長模式，而CER使用變長模式。
所有證書都符合公鑰基礎設施(PKI)制定的ITU-T X509國際標準，PKCS(公鑰加密標準)由RSA實驗室和其他安全系統開發商爲促進公鑰密碼的發展而制定的一系列標準，比如:PKCS#7(密碼消息語法標準----文件後綴名:.p7b、.p7c、.spc)、PKCS#10(證書請求語法標準----文件後綴名:.p10、.csr)、PKCS#12(個人信息交換語法標準----文件後綴名:.p12、.pfx)等
在獲得數字證書後，可以將其保存在電腦中，也可以保存在USB Key等相應的設備中。
傳輸協議
- HTTP
簡介：
HyperText Transfer Protocol，超文本傳輸協議，是互聯網上使用最廣泛的一種協議，所有WWW文件必須遵循的標準。HTTP協議傳輸的數據都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私信息非常不安全。
使用TCP端口爲：80 - HTTPS
Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本傳輸協議，網景公式設計了SSL(Secure Sockets Layer)協議用於對Http協議傳輸的數據進行加密，保證會話過程中的安全性。
使用TCP端口默認爲443 -
SSL協議加密方式
SSL協議即用到了對稱加密也用到了非對稱加密(公鑰加密)，在建立傳輸鏈路時，SSL首先對對稱加密的密鑰使用公鑰進行非對稱加密，鏈路建立好之後，SSL對傳輸內容使用對稱加密。
1.對稱加密
速度高，可加密內容較大，用來加密會話過程中的消息。
2.公鑰加密
加密速度較慢，但能提供更好的身份認證技術，用來加密對稱加密的密鑰。 -
單向認證
Https在建立Socket連接之前，需要進行握手，具體過程如下：
- 客戶端向服務端發送SSL協議版本號、加密算法種類、隨機數等信息。
- 服務端給客戶端返回SSL協議版本號、加密算法種類、隨機數等信息，同時也返回服務器端的證書，即公鑰證書
- 客戶端使用服務端返回的信息驗證服務器的合法性，包括：證書是否過期、髮型服務器證書的CA是否可靠、返回的公鑰是否能正確解開返回證書中的數字簽名、服務器證書上的域名是否和服務器的實際域名相匹配等，驗證通過後，將繼續進行通信，否則，終止通信。
- 客戶端向服務端發送自己所能支持的對稱加密方案，供服務器端進行選擇
- 服務器端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
- 服務器將選擇好的加密方案通過明文方式返回給客戶端
- 客戶端接收到服務端返回的加密方式後，使用該加密方式生成產生隨機碼，用作通信過程中對稱加密的密鑰，使用服務端返回的公鑰進行加密，將加密後的隨機碼發送至服務器
- 服務器收到客戶端返回的加密信息後，使用自己的私鑰進行解密，獲取對稱加密密鑰。 在接下來的會話中，服務器和客戶端將會使用該密碼進行對稱加密，保證通信過程中信息的安全。
- 雙向認證
雙向認證和單向認證原理基本差不多，只是除了客戶端需要認證服務端以外，增加了服務端對客戶端的認證，具體過程如下：
- 客戶端向服務端發送SSL協議版本號、加密算法種類、隨機數等信息。
- 服務端給客戶端返回SSL協議版本號、加密算法種類、隨機數等信息，同時也返回服務器端的證書，即公鑰證書
- 客戶端使用服務端返回的信息驗證服務器的合法性，包括：證書是否過期、髮型服務器證書的CA是否可靠、返回的公鑰是否能正確解開返回證書中的數字簽名、服務器證書上的域名是否和服務器的實際域名相匹配等，驗證通過後，將繼續進行通信，否則，終止通信。
- 服務端要求客戶端發送客戶端的證書，客戶端會將自己的證書發送至服務端
- 驗證客戶端的證書，通過驗證後，會獲得客戶端的公鑰
- 客戶端向服務端發送自己所能支持的對稱加密方案，供服務器端進行選擇
- 服務器端在客戶端提供的加密方案中選擇加密程度最高的加密方式
- 將加密方案通過使用之前獲取到的公鑰進行加密，返回給客戶端
- 客戶端收到服務端返回的加密方案密文後，使用自己的私鑰進行解密，獲取具體加密方式，而後，產生該加密方式的隨機碼，用作加密過程中的密鑰，使用之前從服務端證書中獲取到的公鑰進行加密後，發送給服務端
- 服務端收到客戶端發送的消息後，使用自己的私鑰進行解密，獲取對稱加密的密鑰，在接下來的會話中，服務器和客戶端將會使用該密碼進行對稱加密，保證通信過程中信息的安全。
疑問：
1、客戶端是怎麼校驗服務端證書合法性的、什麼標準？一般客戶端也會裝上證書管理機構頒發的臨時證書，通信嘛，肯定是要有身份的還是要客戶端拿服務端證書去PKI機構驗證？覺得是，我這邊有PKI頒發的臨時證書，可以當做令牌向PKI申請驗證。
2、單向認證、雙向認證的區別是，雙向認證會校驗客戶端的證書並獲取客戶端的公鑰，後面服務端向客戶端發送加密方案時要拿客戶端的公鑰進行加密，返回給客戶端。
後續還針對疑問進行再次補充
參考資料：