證書頒發機構（CA, Certificate Authority）是負責發放和管理數字證書的權威機構，並作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。

如何向 CA 申請證書

（當然不是所有的申請流程都如下所述，但原理都是一樣的）
我們需要使用一個 openssl 軟體，在這個軟體中填寫你申請所需的基本資訊，如國家、公司、域名、郵箱、非對稱演算法等等。讓後我們會得到兩個文字檔案。(xxx表示你申請的域名)

xxx.csr 這是需要發給CA機構申請證書用的檔案

xxx.key 這是伺服器非對稱用的私鑰

• .csr 檔案包含什麼？

  該檔案解碼後可以看到包含三部分資訊：

  1. 域名基本資訊
  2. 公鑰，和上面的私鑰是一對
  3. 簽名

• 解釋 簽名

  簽名的過程：將1、2兩部分資訊進行 sha256 雜湊得到 hash 值，然後通過RSA演算法對hash值進行加密，金鑰為上面提到的私鑰。

  簽名的作用：提供給CA校驗該csr檔案的有效性。CA收到csr後，使用公鑰解密，然後也將1、2部分資訊進行hash，與解密的資料對比，相同則說明資料沒有被篡改過。

  • 為什麼要先hash再加密，直接加密不行嗎？

    hash是一種摘要演算法，元資料可能很大，直接對非常大的資料加密效率太低，密文也會很大，因此先對要加密的資料進行hash獲取它的摘要資訊，有效性是一樣的。

CA 收到申請者的CSR檔案後，進行稽核，通過後就會下發證書檔案。

證書檔案

發回的證書可能包含兩個檔案：

1. 申請域名的證書

2. 證書鏈（包含多個節點，每個節點都是一份證書）

   通常是.pem或.crt字尾的文字檔案。

每個證書的內容主要也包含三部分：

1. 基本資訊，如證書頒發機構、有效期、證書申請資訊
2. 公鑰，即伺服器非對稱用的公鑰
3. 簽名，對上面部分進行hash再用 CA 的私鑰加密簽名（也是用於客戶端驗證證書的有效性）

客戶端如何驗證證書？

通常一個證書鏈有多個證書節點，這裡我們拿有3個節點的鏈舉例：

• DST Root CA X3 根證書節點
  • Let's Encrypt Authority X3 中間證書節點
    • xxx.com 申請者自己的證書

證書鏈是環環相扣，由根節點簽發中間節點，中間節點簽發域名證書。

• 驗證流程：

1. 客戶端訪問 xxx.com 時，伺服器會返回證書鏈；
2. 客戶端首先判斷 xxx.com 證書是否可信，主要是通過驗證簽名，這裡就需要加密這個證書的公鑰。即中間節點的CA公鑰。
3. 因此去中間節點尋找公鑰，中間節點證書第二部分就是CA的公鑰，但我們還不能保證中間節點證書的有效性，因此還需先對中間節點進行簽名驗證，這時就需要去根節點找公鑰。
4. 根節點CA包括一些非常權威的CA機構，他們的證書庫通常被內建在作業系統中或瀏覽器中。我們找到根節點的CA公鑰，然後一步步回去驗證下面節點的有效性。都驗證通過了，則該證書有效。客戶端獲得了伺服器的公鑰可以進行非對稱加密了。

HTTPS通訊大致過程

1. 建立tcp連線
2. 開始TSL握手
   1. client hello
   2. server hello
   3. server傳送證書、非對稱公鑰
   4. client回傳PreMaster Key
   5. 生成對稱加密金鑰Master Key，結束
3. 開始對稱加密傳輸

具體流程可看我的部落格《抓包觀察TSL1.2握手過程》