ssl原理及ssl配置

先來掃盲
CA證書 https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/ca.md

先來一個例子

A公司的小華被派到B公司辦事情。B公司如何信任小華是A公司派來的呢？

普通介紹信

為了讓B公司信任小華，A公司特意給小華開了一封介紹信，在信件中詳細說明了小華的特征以及小華過來的目的，
并且聲明這個小華確實是A公司派來的，除此之外還要有一個A公司的公章。
這樣B公司前臺姐拿到介紹信后，通過信件內容和A公司公章就能判斷出小華確實是A公司派來的員工。

那萬一A公司公章是假的呢？畢竟公章偽造太容易了，這樣豈不是會存在問題。咱們就暫且認為公章這種東西很難偽造，
否則故事無法繼續嘍。

引入第三方中介公司

好，回到剛才的話題。如果和B公司有業務往來的公司很多，每個公司的公章都不同，那B公司的前臺姐就要懂得分辨各種公章，
非常滴麻煩。所以，有某個中介公司C，發現了這個商機。C公司專門開設了一項“代理公章”的業務。
　　
于是今后，A公司的業務員去B公司，需要帶2個介紹信：
介紹信1（含有C公司的公章及A公司的公章。并且特地注明：C公司信任A公司。）
介紹信2（僅含有A公司的公章，然后寫上：茲有xxx先生/女士前往貴公司辦理業務，請給予接洽......。）

這樣不是增加麻煩了嗎？有啥好處呢？
主要的好處在于，對于接待公司的前臺，就不需要記住各個公司的公章分別是啥樣子的，她只要記住中介公司C的公章即可。
當她拿到兩份介紹信之后，先對介紹信1的C公章驗明正身，確認無誤之后，再比對“介紹信1”和“介紹信2”的兩個A公章是否一致。
如果是一樣的，那就可以證明“介紹信2”是可以信任的了。

相關專業術語的解釋

下面就著上面的例子，把相關的名詞，作一些解釋。

什么是證書？

證書，洋文也叫“digital certificate”或“public key certificate”。
它是用來證明某某東西確實是某某的東西，通俗地說，證書就好比例子里面的公章。通過公章，
可以證明該介紹信確實是對應的公司發出的。
理論上，人人都可以找個證書工具，自己做一個證書。那如何防止壞人自己制作證書出來呢？

什么是CA？

CA 是“Certificate Authority”的縮寫，也叫“證書授權中心”。它是負責管理和簽發證書的第三方機構，
就好比例子里面的中介C公司。
一般來說，CA必須是所有行業和所有公眾都信任的、認可的。因此它必須具有足夠的權威性。
就好比A、B兩公司都必須信任C公司，才會找C公司作為公章的中介。

什么是CA證書？

CA證書，顧名思義，就是CA頒發的證書。

前面已經說了，人人都可以找工具制作證書。但是你一個小破孩制作出來的證書是沒啥用處的。
因為你不是權威的CA機關，你自己搞的證書不具有權威性。
這就好比上述的例子里，某個壞人自己刻了一個公章，蓋到介紹信上。但是別人一看，
不是受信任的中介公司的公章，就不予理睬。

什么是證書之間的信任關系？

在開篇的例子里談到，引入中介后，業務員要同時帶兩個介紹信。第一個介紹信包含了兩個公章，并注明，公章C信任公章A。
證書間的信任關系，就和這個類似。就是用一個證書來證明另一個證書是真實可信滴。

什么是證書信任鏈？

實際上，證書之間的信任關系，是可以嵌套的。
比如，C信任A1，A1信任A2，A2信任A3......這個叫做證書的信任鏈。
只要你信任鏈上的頭一個證書，那后續的證書，都是可以信任滴。

什么是根證書？

根證書的洋文叫“root certificate”，為了說清楚根證書是咋回事，再來看個稍微復雜點的例子。
假設C證書信任A和B；然后A信任A1和A2；B信任B1和B2。則它們之間，構成如下的一個樹形關系（一個倒立的樹）。

處于最頂上的樹根位置的那個證書，就是“根證書”。除了根證書，其它證書都要依靠上一級的證書，來證明自己。
那誰來證明“根證書”可靠呢？
實際上，根證書自己證明自己是可靠滴（或者換句話說，根證書是不需要被證明滴）。
聰明的同學此刻應該意識到了：根證書是整個證書體系安全的根本。
所以，如果某個證書體系中，根證書出了問題（不再可信了），那么所有被根證書所信任的其它證書，也就不再可信了。

證書有啥用？

CA證書的作用有很多，只列出常用的幾個。

驗證網站是否可信（針對HTTPS）

通常，我們如果訪問某些敏感的網頁（比如用戶登錄的頁面），其協議都會使用HTTPS而不是HTTP,因為HTTP協議是明文的，
一旦有壞人在偷窺你的網絡通訊，他/她就可以看到網絡通訊的內容（比如你的密碼、銀行帳號、等）。
而 HTTPS 是加密的協議，可以保證你的傳輸過程中，壞蛋無法偷窺。
但是，千萬不要以為，HTTPS協議有了加密，就可高枕無憂了。
假設有一個壞人，搞了一個假的網銀的站點，然后誘騙你上這個站點。
假設你又比較單純，一不留神，就把你的帳號，口令都輸入進去了。那這個壞蛋的陰謀就得逞了。
為了防止壞人這么干，HTTPS 協議除了有加密的機制，還有一套證書的機制。通過證書來確保，某個站點確實就是某個站點。
有了證書之后，當你的瀏覽器在訪問某個HTTPS網站時，會驗證該站點上的CA證書（類似于驗證介紹信的公章）。
如果瀏覽器發現該證書沒有問題（證書被某個根證書信任、證書上綁定的域名和該網站的域名一致、證書沒有過期），
那么頁面就直接打開，否則的話，瀏覽器會給出一個警告，告訴你該網站的證書存在某某問題，是否繼續訪問該站點。

驗證文件是否可信

SSL原理
https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/ssl.md

SSL原理

要想弄明白SSL認證原理，首先要對CA有有所了解，它在SSL認證過程中有非常重要的作用。
說白了，CA就是一個組織，專門為網絡服務器頒發證書的，國際知名的CA機構有VeriSign、Symantec，國內的有GlobalSign。
每一家CA都有自己的根證書，用來對它所簽發過的服務器端證書進行驗證。

如果服務器提供方想為自己的服務器申請證書，它就需要向CA機構提出申請。
服務器提供方向CA提供自己的身份信息，CA判明申請者的身份后，就為它分配一個公鑰，
并且CA將該公鑰和服務器身份綁定在一起，并為之簽字，這就形成了一個服務器端證書。

如果一個用戶想鑒別另一個證書的真偽，他就用CA的公鑰對那個證書上的簽字進行驗證，一旦驗證通過，該證書就被認為是有效的。
證書實際是由證書簽證機關（CA）簽發的對用戶的公鑰的認證。

證書的內容包括：電子簽證機關的信息、公鑰用戶信息、公鑰、權威機構的簽字和有效期等等。
目前，證書的格式和驗證方法普遍遵循X.509國際標準。

申請證書過程

首先要有一個CA根證書，然后用CA根證書來簽發用戶證書。
用戶進行證書申請：

1. 先生成一個私鑰
2. 用私鑰生成證書請求(證書請求里應含有公鑰信息)
3. 利用證書服務器的CA根證書來簽發證書

這樣最終拿到一個由CA根證書簽發的證書，其實證書里僅有公鑰，而私鑰是在用戶手里的。

SSL工作流程（單向）

1.客戶端say hello 服務端
2.服務端將證書、公鑰等發給客戶端
3.客戶端CA驗證證書，成功繼續、不成功彈出選擇頁面
4.客戶端告知服務端所支持的加密算法
5.服務端選擇最高級別加密算法明文通知客戶端
6.客戶端生成隨機對稱密鑰key，使用服務端公鑰加密發送給服務端
7.服務端使用私鑰解密，獲取對稱密鑰key
8.后續客戶端與服務端使用該密鑰key進行加密通信

SSL工作流程（雙向）

單向認證，僅僅是客戶端需要檢驗服務端證書是否是正確的，而服務端不會檢驗客戶端證書是否是正確的。 雙向認證，指客戶端驗證服務器端證書，而服務器也需要通過CA的公鑰證書來驗證客戶端證書。

雙向驗證的過程：

1.客戶端say hello 服務端
2.服務端將證書、公鑰等發給客戶端
3.客戶端CA驗證證書，成功繼續、不成功彈出選擇頁面
4.客戶端將自己的證書和公鑰發送給服務端
5.服務端驗證客戶端證書，如不通過直接斷開連接
6.客戶端告知服務端所支持的加密算法
7.服務端選擇最高級別加密算法使用客戶端公鑰加密后發送給客戶端
8.客戶端收到后使用私鑰解密并生成隨機對稱密鑰key，使用服務端公鑰加密發送給服務端
9.服務端使用私鑰解密，獲取對稱密鑰key
10.后續客戶端與服務端使用該密鑰key進行加密通信

在Linux機器上生成SSL密鑰對
https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/key.md

生成CA根證書

mkdir /etc/pki/ca_test //創建CA更證書的目錄

cd /etc/pki/ca_test

mkdir root server client newcerts //創建幾個相關的目錄

echo 01 > serial //定義序列號為01

echo 01 > crlnumber //定義crl號為01

touch index.txt //創建index.txt

cd ..

vi tls/openssl.cnf //改配置文件

default_ca = CA_default 改為 default_ca = CA_test
[ CA_default ] 改為 [ CA_test ]
dir = /etc/pki/CA 改為 dir = /etc/pki/ca_test
certificate = $dir/cacert.pem 改為 certificate = $dir/root/ca.crt
private_key = $dir/private/cakey.pe 改為 private_key = $dir/root/ca.key

openssl genrsa -out /etc/pki/ca_test/root/ca.key //生成私鑰

openssl req -new -key /etc/pki/ca_test/root/ca.key -out /etc/pki/ca_test/root/ca.csr

//生成請求文件，會讓我們填寫一些指標,這里要注意：如果在這一步填寫了相應的指標，
比如Country Name、State or Province Name、hostname。

openssl x509 -req -days 3650 -in /etc/pki/ca_test/root/ca.csr -signkey /etc/pki/ca_test/root/ca.key -out /etc/pki/ca_test/root/ca.crt

生成crt文件

生成server端證書

cd /etc/pki/ca_test/server

openssl genrsa -out server.key //生成私鑰文件

openssl req -new -key server.key -out server.csr//生成證書請求文件，填寫信息需要和ca.csr中的Organization Name保持一致

openssl ca -in server.csr -cert /etc/pki/ca_test/root/ca.crt -keyfile /etc/pki/ca_test/root/ca.key -out server.crt -days 3650

//用根證書簽名server.csr，最后生成公鑰文件server.crt，此步驟會有兩個地方需要輸入y
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

生成客戶端證書

如果做ssl的雙向認證，還需要給客戶端生成一個證書，步驟和上面的基本一致

cd /etc/pki/ca_test/client

openssl genrsa -out client.key //生成私鑰文件

openssl req -new -key client.key -out client.csr //生成請求文件，填寫信息需要和ca.csr中的Organization Name保持一致

openssl ca -in client.csr -cert /etc/pki/ca_test/root/ca.crt -keyfile /etc/pki/ca_test/root/ca.key -out client.crt -days 3650

//簽名client.csr, 生成client.crt，此步如果出現
failed to update database
TXT_DB error number 2

需執行：

sed -i 's/unique_subject = yes/unique_subject = no/' /etc/pki/ca_test/index.txt.attr

執行完，再次重復執行簽名client.csr那個操作

如上操作如下結果