轉自：https://www.cnblogs.com/Presley-lpc/p/9776463.html

1.什麼是CA證書。

◇ 普通的介紹信

想必大夥兒都聽說過介紹信的例子吧？假設 A 公司的張三先生要到 B 公司去拜訪，但是 B 公司的所有人都不認識他，他咋辦捏？常用的辦法是帶公司開的一張介紹信，在信中說：茲有張三先生前往貴公司辦理業務，請給予接洽......云云。然後在信上敲上A公司的公章。

張三先生到了 B 公司後，把介紹信遞給 B 公司的前臺李四小姐。李小姐一看介紹信上有 A 公司的公章，而且 A 公司是經常和 B 公司有業務往來的，這位李小姐就相信張先生不是歹人了。

這裡，A公司就是CA證書

◇ 引入中介機構的介紹信

好，回到剛才的話題。如果和 B 公司有業務往來的公司很多，每個公司的公章都不同，那前臺就要懂得分辨各種公章，非常滴麻煩。所以，有某個中介公司 C，發現了這個商機。C公司專門開設了一項“代理公章”的業務。

今後，A 公司的業務員去 B 公司，需要帶2個介紹信：

介紹信1

含有 C 公司的公章及 A 公司的公章。並且特地註明：C 公司信任 A 公司。

介紹信2

僅含有 A 公司的公章，然後寫上：茲有張三先生前往貴公司辦理業務，請給予接洽......云云。

某些不開竅的同學會問了，這樣不是增加麻煩了嗎？有啥好處捏？

主要的好處在於，對於接待公司的前臺，就不需要記住各個公司的公章分別是啥樣子的；他/她只要記住中介公司 C 的公章即可。當他/她拿到兩份介紹信之後，先對介紹信1的 C 公章，驗明正身；確認無誤之後，再比對介紹信1和介紹信2的兩個 A 公章是否一致。如果是一樣的，那就可以證明介紹信2是可以信任的了。

◇ 什麼是證書？

“證書”洋文也叫“digital certificate”或“public key certificate”（專業的解釋看“這裡”）。

它是用來證明某某東西確實是某某東西的東西（是不是像繞口令？）。通俗地說，證書就好比例子裡面的公章。通過公章，可以證明該介紹信確實是對應的公司發出的。

理論上，人人都可以找個證書工具，自己做一個證書。那如何防止壞人自己製作證書出來騙人捏？請看後續 CA 的介紹。

◇ 什麼是CA？

CA是Certificate Authority的縮寫，也叫“證書授權中心”。（專業的解釋看“這裡”）

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

◇ 什麼是CA證書？

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

前面已經說了，人人都可以找工具製作證書。但是你一個小破孩製作出來的證書是沒啥用處的。因為你不是權威的CA機關，你自己搞的證書不具有權威性。

這就好比上述的例子裡，某個壞人自己刻了一個公章，蓋到介紹信上。但是別人一看，不是受信任的中介公司的公章，就不予理睬。壞蛋的陰謀就不能得逞啦。

文字後續提及的證書，若無特殊說明，均指 CA 證書。

2.證書的簽發過程：

• a.服務方 S 向第三方機構CA提交公鑰、組織資訊、個人資訊(域名)等資訊並申請認證；

• b.CA 通過線上、線下等多種手段驗證申請者提供資訊的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等；

• c.如資訊稽核通過，CA 會向申請者簽發認證檔案-證書。

證書包含以下資訊：申請者公鑰、申請者的組織資訊和個人資訊、簽發機構 CA 的資訊、有效時間、證書序列號等資訊的明文，同時包含一個簽名；

簽名的產生演算法：首先，使用雜湊函式計算公開的明文資訊的資訊摘要，然後，採用 CA 的私鑰對資訊摘要進行加密，密文即簽名；

• d.客戶端 C 向伺服器 S 發出請求時，S 返回證書檔案；

• e.客戶端 C 讀取證書中的相關的明文資訊，採用相同的雜湊函式計算得到資訊摘要，然後，利用對應 CA 的公鑰解密簽名資料，對比證書的資訊摘要，如果一致，則可以確認證書的合法性，即公鑰合法；

• f.客戶端然後驗證證書相關的域名資訊、有效時間等資訊；

• g.客戶端會內建信任 CA 的證書資訊(包含公鑰)，如果CA不被信任，則找不到對應 CA 的證書，證書也會被判定非法。

在這個過程注意幾點：

1.申請證書不需要提供私鑰，確保私鑰永遠只能伺服器掌握；

2.證書的合法性仍然依賴於非對稱加密演算法，證書主要是增加了伺服器資訊以及簽名；

3.內建 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書；

4.證書=公鑰+申請者與頒發者資訊+簽名；

http通訊存在的問題

• 容易被監聽

  • http通訊都是明文，資料在客戶端與伺服器通訊過程中，任何一點都可能被劫持。比如，傳送了銀行卡號和密碼，hacker劫取到資料，就能看到卡號和密碼，這是很危險的

• 被偽裝

  • http通訊時，無法保證通行雙方是合法的，通訊方可能是偽裝的。比如你請求www.taobao.com,你怎麼知道返回的資料就是來自淘寶，中間人可能返回資料偽裝成淘寶。

• 被篡改

  • hacker中間篡改資料後，接收方並不知道資料已經被更改

共享金鑰加密和公開金鑰加密

後續內容的需要，這裡插播一段共享金鑰加密和公開金鑰加密

• 共享金鑰加密

  • 共享金鑰的加密金鑰和解密金鑰是相同的，所以又稱為對稱金鑰

• 公開金鑰加密

  • 加密演算法是公開的，金鑰是保密的。公開金鑰分為私有金鑰和公有金鑰，公有金鑰是公開的，任何人(客戶端)都可以獲取，客戶端使用公有金鑰加密資料，服務端用私有金鑰解密資料。

• 異同

  • 共享金鑰加密與公開金鑰加密相比，加解密處理速度快，但公開金鑰更適應網際網路下使用

https解決的問題

https很好的解決了http的三個缺點（被監聽、被篡改、被偽裝），https不是一種新的協議，它是http+SSL(TLS)的結合體，SSL是一種獨立協議，所以其它協議比如smtp等也可以跟ssl結合。https改變了通訊方式，它由以前的http—–>tcp，改為http——>SSL—–>tcp；https採用了共享金鑰加密+公開金鑰加密的方式

• 防監聽

  • 資料是加密的，所以監聽得到的資料是密文，hacker看不懂。

• 防偽裝

  • 偽裝分為客戶端偽裝和伺服器偽裝，通訊雙方攜帶證書，證書相當於身份證，有證書就認為合法，沒有證書就認為非法，證書由第三方頒佈，很難偽造

• 防篡改

  • https對資料做了摘要，篡改資料會被感知到。hacker即使從中改了資料也白搭。

https連線過程

• 客戶端傳送請求到伺服器端

• 伺服器端返回證書和公開金鑰，公開金鑰作為證書的一部分而存在

• 客戶端驗證證書和公開金鑰的有效性，如果有效，則生成共享金鑰並使用公開金鑰加密傳送到伺服器端

• 伺服器端使用私有金鑰解密資料，並使用收到的共享金鑰加密資料，傳送到客戶端

• 客戶端使用共享金鑰解密資料

• SSL加密建立………

客戶端認證的通訊的過程

• 客戶端需要認證的過程跟伺服器端需要認證的過程基本相同，並且少了最開始的兩步。這種情況都是證書儲存在客戶端，並且應用場景比較少，一般金融才使用，比如支付寶、銀行客戶端都需要安裝證書

後續的問題

• 怎樣保證公開金鑰的有效性

  • 你也許會想到，怎麼保證客戶端收到的公開金鑰是合法的，不是偽造的，證書很好的完成了這個任務。證書由權威的第三方機構頒發，並且對公開金鑰做了簽名。

• https的缺點

  • https保證了通訊的安全，但帶來了加密解密消耗計算機cpu資源的問題 ，不過，有專門的https加解密硬體伺服器

• 各大網際網路公司，百度、淘寶、支付寶、知乎都使用https協議，為什麼？

  • 支付寶涉及到金融，所以出於安全考慮採用https這個，可以理解，為什麼百度、知乎等也採用這種方式？為了防止運營商劫持！http通訊時，運營商在資料中插入各種廣告，使用者看到後，怒火發到網際網路公司，其實這些壞事都是運營商(移動、聯通、電信)乾的,用了https，運營商就沒法插播廣告篡改資料了。

4.比較完整的過程：

1. 客戶端發起HTTPS請求

這個沒什麼好說的，就是使用者在瀏覽器裡輸入一個https網址，然後連線到server的443埠。

2. 服務端的配置

採用HTTPS協議的伺服器必須要有一套數字證書，可以自己製作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然後發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

3. 傳送證書

這個證書其實就是公鑰，只是包含了很多資訊，如證書的頒發機構，過期時間等等。

4. 客戶端解析證書

這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨機值。然後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。

5. 傳送加密資訊

這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通訊就可以通過這個隨機值來進行加密解密了。

6. 服務段解密資訊

服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將資訊和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠複雜，資料就夠安全。

7. 傳輸加密後的資訊

這部分資訊是服務段用私鑰加密後的資訊，可以在客戶端被還原。

8. 客戶端解密資訊

客戶端用之前生成的私鑰解密服務段傳過來的資訊，於是獲取瞭解密後的內容。整個過程第三方即使監聽到了資料，也束手無策。

5.總結整個過程：

1.伺服器向CA機構獲取證書（假設這個證書偽造不了），當瀏覽器首次請求伺服器的時候，伺服器返回證書給瀏覽器。（證書包含：公鑰+申請者與頒發者的相關資訊+簽名）

2.瀏覽器得到證書後，開始驗證證書的相關資訊，證書有效（沒過期等）。（驗證過程，比較複雜，詳見上文）。

3.驗證完證書後，如果證書有效，客戶端是生成一個隨機數，然後用證書中的公鑰進行加密，加密後，傳送給伺服器，伺服器用私鑰進行解密，得到隨機數。之後雙方便開始用該隨機數作為鑰匙，對要傳遞的資料進行加密、解密。

關於https：http://blog.csdn.net/wangjun5159/article/details/51510594

引用參考部落格：http://kb.cnblogs.com/page/194742/

關於https的誤解：http://www.admin5.com/article/20150523/600106.shtml

6.https 正式測試

準備cfssl環境

生成ca證書

• 準備配置檔案

  cd /root/ssl_test;mkdir keys;cd keys cat > ca-config.json <<EOF {   "signing": {     "default": {       "expiry": "8760h"     },     "profiles": {       "app": {         "usages": [             "signing",             "key encipherment",             "server auth",             "client auth"         ],         "expiry": "8760h"       }     }   } } EOF   cat > ca-csr.json <<EOF {   "CN": "k8s",   "key": {     "algo": "rsa",     "size": 2048   },   "names": [     {       "C": "CN",       "ST": "BeiJing",       "L": "BeiJing",       "O": "k8s",       "OU": "System"     }   ] } EOF

• 執行命令生成ca檔案

  ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca

生成server證書

進行驗證

• 匯入證書

  ca.pem改名為ca.crt。將正式匯入瀏覽器。

• 構建https服務

  cd /root/ssl_test cat > http-server.js <<EOF var https = require('https'); var fs = require('fs');   var options = {     key: fs.readFileSync('./keys/app-key.pem'),     cert: fs.readFileSync('./keys/app.pem') };   https.createServer(options, function (req, res) {     res.writeHead(200);     res.end('hello world'); }).listen(8000); EOF   yum install nodejs -y npm install https -g node http-server.js

• 修改hosts檔案新增

  192.168.0.158 *.ma.com
  

  在瀏覽器訪問https://www.ma.com:8000 發現網站顯示為安全

   

7. 證書各個欄位的含義

數字證書中主題(Subject)中欄位的含義

• 一般的數字證書產品的主題通常含有如下欄位：

• 證書申請單位所在地

• 其他一些欄位

8.單向認證雙向認證

何為SSL/TLS單向認證，雙向認證？
單向認證指的是隻有一個物件校驗對端的證書合法性。
通常都是client來校驗伺服器的合法性。那麼client需要一個ca.crt,伺服器需要server.crt,server.key
雙向認證指的是相互校驗，伺服器需要校驗每個client,client也需要校驗伺服器。
server 需要 server.key 、server.crt 、ca.crt
client 需要 client.key 、client.crt 、ca.crt