一．公鑰和私鑰介紹
- 公鑰和私鑰成對出現(xiàn)
- 公開的密鑰叫公鑰，只有自己知道的叫私鑰
- 用公鑰加密的數(shù)據(jù)只有對應(yīng)的私鑰可以解密
- 用私鑰加密的數(shù)據(jù)只有對應(yīng)的公鑰可以解密, (
用私鑰加密數(shù)據(jù)（數(shù)字簽名），用公鑰來驗證數(shù)字簽名)
二．證書的幾種文件擴展名
對于 X.509 標準的證書有兩種不同編碼格式,一般采用 PEM 編碼就以 .pem 作為文件擴展名,若采用 DER 編碼，就應(yīng)以 .der 作為擴展名。但常見的證書擴展名還包括 .crt、.cer、.p12 等，他們采用的編碼格式可能不同，內(nèi)容也有所差別，但大多數(shù)都能互相轉(zhuǎn)換，總結(jié)如下：
- .pem: 采用 PEM 編碼格式的 X.509 證書的文件擴展名；
- .der : 采用 DER 編碼格式的 X.509 證書的文件擴展名；
-
.crt : 即 certificate 的縮寫，
常見于類 UNIX 系統(tǒng)，有可能是 PEM 編碼，也有可能是 DER 編碼，但絕大多數(shù)情況下此格式證書都是采用 PEM 編碼； -
.cer: 也是 certificate 的縮寫，
常見于 Windows 系統(tǒng)，同樣地，可能是 PEM 編碼，也可能是 DER 編碼，但絕大多數(shù)情況下此格式證書都是采用 DER 編碼 - .p12: 也寫作 .pfx，全稱：PKCS #12，是公鑰加密標準（Public Key Cryptography Standards，PKCS）系列的一種，它定義了描述個人信息交換語法（Personal Information Exchange Syntax）的標準，可以用來將包含了公鑰的 X.509 證書和證書對應(yīng)的私鑰以及其他相關(guān)信息打包，進行交換。簡單理解：一份 .p12 文件 = X.509 證書+私鑰；
- .csr: Certificate Signing Request 的縮寫，即證書簽名請求，它并不是證書的格式，而是用于向權(quán)威證書頒發(fā)機構(gòu)（Certificate Authority, CA）獲得簽名證書的申請，其核心內(nèi)容包含一個 RSA 公鑰和其他附帶信息，在生成這個 .csr 申請的時候，同時也會生成一個配對 RSA 私鑰，私鑰通常需要嚴格保存于服務(wù)端，不能外泄。
- .key: 通常用來存放一個 RSA 公鑰或者私鑰，它并非 X.509 證書格式，編碼同樣可能是 PEM，也可能是 DER，查看方式如下：
PEM 編碼格式：openssl rsa -in xxx.key -text -noout
DER 編碼格式：openssl rsa -in xxx.key -text -noout -inform der
三．什么是HTTPS，TLS，SSL
- http是超文本傳輸協(xié)議，信息是明文傳輸(
80端口)，https 則是具有安全性的ssl加密傳輸協(xié)議(443端口) - HTTPS，也稱作HTTP over TLS。TLS的前身是SSL，TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。下圖描述了在TCP/IP協(xié)議棧中TLS(各子協(xié)議）和HTTP的關(guān)系。
Paste_Image.png - HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議．
四．https握手過程
- 客戶端發(fā)起HTTPS請求
- 服務(wù)端的配置
- 傳送證書
這個證書其實就是服務(wù)器的公鑰，只是包含了很多信息，如證書的頒發(fā)機構(gòu)，過期時間等等，該公鑰的目的是為了和服務(wù)器端之間協(xié)商對稱秘鑰對使用，也就是服務(wù)器用子自己的私鑰加密數(shù)據(jù)，客戶端要用該公鑰進行解密； - 客戶端解析證書
這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨機值。然后用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。 - 傳送加密信息
這部分傳送的是用證書加密后的隨機值，目的就是讓服務(wù)端得到這個隨機值，以后客戶端和服務(wù)端的通信就可以通過這個隨機值來進行加密解密了。服務(wù)器與客戶端之間的數(shù)據(jù)傳輸過程是采用對稱加密方式加密的；
四．什么是CA和證書
以上三步驟中的第3步驟中提到的服務(wù)器的公鑰，在網(wǎng)絡(luò)中客戶被人所冒充，所以這里就引入了CA的概念，也就是上門面第４步驟說的驗證公鑰的權(quán)威機構(gòu)；
CA，Catificate Authority，它的作用就是提供證書（即服務(wù)器證書，由域名、公司信息、序列號和簽名信息組成）加強服務(wù)端和客戶端之間信息交互的安全性，以及證書運維相關(guān)服務(wù)。任何個體/組織都可以扮演 CA 的角色，只不過難以得到客戶端的信任，能夠受瀏覽器默認信任的 CA 大廠商有很多，其中 TOP5 是 Symantec、Comodo、Godaddy、GolbalSign 和 Digicer
扮演 CA 角色，就意味著要管理大量的 pair 對，而原始的一對 pair 對叫做 root pair，它包含了 root key（ca.key根證書秘鑰）和 root certificate（ca.cert.pem根證書）。通常情況下，root CA (根證書)不會直接為服務(wù)器或者客戶端簽證，它們會先為自己生成幾個中間 CA（intermediate CAs），這幾個中間 CA 作為 root CA 的代表為服務(wù)器和客戶端簽證。
也就是說這幾個中間CA可以簽發(fā)客戶端證書和服務(wù)器端證書；
引用：http://www.barretlee.com/blog/2016/04/24/detail-about-ca-and-certs/
- 證書包含信息：
- 證書信息：過期時間和序列號
- 所有者信息：姓名，公司地址，域名等等
- 所有者公鑰
我們需要自己制作申請CA證書的.csr文件(該文件包含申請者的身份,公司,所在省份，域名等等信息),然后將csr申請文件提交給權(quán)威的CA機構(gòu)，CA機構(gòu)經(jīng)過審核申請者身份后，通過認證，下發(fā)認證后的證書；
將經(jīng)CA過認證的過的證書配置到自己服務(wù)器中，當用戶訪問我們https服務(wù)器的時候，服務(wù)器會將該證書傳遞給瀏覽器，瀏覽器廠商會默認存有各大權(quán)威CA機構(gòu)的根證書（包含對應(yīng)證書的公鑰），根據(jù)CA根證書驗證服務(wù)器的證書是否是該機構(gòu)認證；具體申請和認證流程如下：
圖片來源（http://www.lxweimin.com/u/e50343300b96）
當然CA機構(gòu)可以自己搭建，也就是自己通過openssl工具創(chuàng)建CA秘鑰和CA根證書，利用CA根證書對服務(wù)器證書或客戶端證書進行簽名認證；
五．CA認證，簽名，數(shù)據(jù)加密等算法分類
消息摘要算法：MD5、和SHA（對數(shù)字證書本省做摘要處理，用于驗證數(shù)據(jù)完整性服務(wù)器）
對稱加密算法：RC2、RC4、IDEA、DES、AES（對數(shù)據(jù)進行加密/解密操作，用于保證數(shù)據(jù)保密性服務(wù)）
非對稱加密算法：RSA、DH（對數(shù)據(jù)進行加密/解密操作，用于保證數(shù)據(jù)保密性服務(wù)）
數(shù)字簽名算法：RSA、DSA(對數(shù)據(jù)進行簽名/驗證操作，保證數(shù)據(jù)的完整性和抗否認性)。
參考站點：
數(shù)字簽名是什么
身份認證和訪問控制實現(xiàn)原理
細說 CA 和證書
關(guān)于啟用 HTTPS 的一些經(jīng)驗分享（二）
