Overview
OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is also a general-purpose cryptography library.
OpenSSL is licensed under an Apache-style license, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions.
SSL(Secure Sockets Layer 安全套接字協議),及其繼任者傳輸層安全（Transport Layer Security，TLS）是爲網絡通信提供安全及數據完整性的一種安全協議。TLS與SSL在傳輸層與應用層之間對網絡連接進行加密。
工作原理
這裏，我們舉一個例子，假設小紅希望小明通過https方式與自己通信。
數字證書生成
通信前，小紅通過如下步驟爲自己生成數字證書。
- 步驟1 生成身份申請（certificate signing request,CSR）
CSR中包含了證書證書申請人相關信息，如對象名稱、有效期、證書發佈者、證書算法等信息，爲了方便，我們將其簡寫爲C。
- 步驟2 讓CA爲CSR簽名
小紅怕自己資歷不夠，所以請德高望重的小王爲自己的CSR簽名。我們稱小王爲證書籤署人，即CA（Certificate Authority）。
小王拿到小紅提交的CSR以後，先對它做摘要處理，我們記爲digest。然後用自己的私鑰對digest做加密，進而爲小紅生成簽名Signature。
- 步驟3 生成數字證書
小紅將自己先前生成的CSR與德高望重的小王爲自己簽署的簽名打包在一起就成爲了自己的數字證書，我們將其記爲CRT。
爲了幫助大家有一個更深刻的認識，我用json對其數據結構做一個示意性解釋。
{
"data": [
{
"id": "xiaohong",
"name": "小紅",
"namespace": "provider",
"description": "crt",
"csr": {
"public_key": "~/.tmp/ssl/xiaohong/id.pub",
"dns": "xiaohong.qwfys.com",
"country_name": "China",
"province_name":"Hongkong",
"company_name":"www.qwfys.com Inc.",
"unit_name":"IT",
"server_name": "jenkins.qwfys.com",
"mail:": "[email protected]"
},
"signature": {
"digest": {
"csr": {
"type": "object",
"ref": "csr",
"id": "xiaohong",
"namespace": "provider"
}
},
"private_key": "~/.tmp/ssl/xiaohong/id"
}
},
{
"id": "xiaoliang",
"name": "小亮",
"namespace": "ca",
"description": "crt",
"csr": {
"public_key": "~/.tmp/ssl/xiaoliang/id.pub",
"dns": "xiaoliang.cloud.google.com",
"country_name": "China",
"province_name":"Hongkong",
"company_name":"www.dffxs.com Inc.",
"unit_name":"IT",
"server_name": "www.dffxs.com",
"mail:": "[email protected]"
},
"signature": {
"digest": {
"csr": {
"type": "object",
"ref": "csr",
"id": "xiaoliang",
"namespace": "ca"
}
},
"private_key": "~/.tmp/ssl/xiaoliang/id"
}
}
]
}
數字證書檢驗
接下來，在通信中，小紅將自己的數字證書（即CSR + Signature）發給小明，小明怕小王的數字證書不是小紅的，或者對小紅不信任，那麼小明如何才能與小紅建立信任關係並完成通信呢？我們通過以下步驟來分析。
- 步驟 1 對發行者的身份申請做摘要處理
小明拿到小紅的數字證書以後，先提取其中的CSR，對CSR做摘要處理，因爲摘要算法是通用的，所以其結果也是digest。
- 步驟 2 對簽名做解密處理
小明拿發現小紅的數字證書是小王簽名過的，這個時候，小明找到小王的簽名證書存根，取出其中的公鑰，用這個公鑰對小紅的數字證書CRT做解密處理，得到一個摘要信息結果，我們將其記爲digest-new。
- 步驟3 比較digest-new與digest是否相同
我們知道小紅的數字證書是小王用自己的私鑰簽署過的，那麼這個時候，我們用小王的公鑰對小紅的數字證書做解密，應該就可以得到簽署前的小王的身份申請CSR的摘要信息digest。這只是理論，實踐中是不是這樣呢，我們需要檢驗，如果我們對digest-new與digest做比較，發現確實是一樣的，那麼，小明就認爲小紅的數字證書是沒有問題的。
上面的討論，我們假定小明是信任小王的，而且他持有小王的自籤數字證書。假如小明不信任小王，那麼會發生什麼事呢？這裏有如下幾種辦法。
1、小紅與小明商量，找到一個小明信任的CA爲自己簽署證書。
2、小紅找不到其他人，他只認識小王，小王又認識小張，小張認識小李，而小明是信任小李的，這個時候，如果小李已經爲小張簽署過證書，而小張又爲小王簽署過證書，那麼小王爲小紅簽署證書以後，小明用小李自簽署的證書逐步去驗證小五，只要驗證通過，那麼小明就認爲小紅的數字證書沒有問題。
Reference