关于加密、证书的那些事
<
文章目錄
- 前言
- 一個典型的物聯網產品
- 數據加密
- 明文傳輸的缺點
- 加密傳輸
- 加密方式
- 可逆加密
- 不可逆加密
- 公鑰和私鑰
- 證書
- 如何申請證書
- 如何確認證書的合法性
- 單向認證和雙向認證
- 認證機構
- 證書鏈
- 證書文件的后綴名
- 證書文件的格式
- PEM格式(Privacy Enhanced Mail)
- DER格式(Distinguished Encoding Rules)
- X.509標準
- 證書格式
- OpenPGP協議/標準
- OpenPGP是什么？
- OpenPGP協議的實現
- OpenPGP的使用流程
- SSL/TLS
- 協議分層
- 握手過程
- HTTPS與SSL的關系
- OpenSSL
- OpenSSL是什么？
- 密碼算法庫
- 信息摘要算法
- 秘鑰和證書管理
- SSL協議庫
- 應用程序
- OpenSSH又是什么？
- SSH
- SSH中基于口令的安全驗證
- SSH中基于秘鑰的安全認證
- SSH協議的實現
- 總結
前言
在一個物聯網系統中，終端設備在連接云平臺(服務器)的時候，云平臺需要對設備的身份進行驗證，驗證這是一個合法的設備之后才允許接入。這看似很簡單的一句話，背后包含了很多相關的概念，例如：加密、證書、證書標準、簽名、認證機構、SSL/TLS、OpenSSL、握手等一堆容易混淆的概念。
之前我在做智能家居項目時，每次遇到證書以及加密的問題時，都是滿大街的查資料，但是由于每次都是解決問題之后就停止下來，沒有進行完整、系統的梳理，因此對這些概念始終感覺自己都理解了，但是又說不出所以然來。
這篇文章我們就把這些概念以及相關的使用步驟進行梳理，就像聯想記憶一樣，很多分散的東西總是記不住，但是如果把這些東西按照特定的關系組織在一起，那么記憶起來就非常容易了。
做個小游戲：在1分鐘內記下這十個東西：茶杯、猴子、玻璃、垃圾桶、魚竿、鳥窩、和尚、汽車、醫院、飲水機。這里可以暫停一下，看看自己的記憶力是不是不如以前了。
我們再換個記憶方法，把這十個東西以任意荒誕的邏輯聯系在一起，比如：一只猴子，左手拿著茶杯，右手拿著玻璃，往垃圾桶走去。在垃圾桶旁邊，看到一只魚竿，于是它就用魚竿去戳樹上的鳥窩。鳥窩里掉下來一個鳥蛋，正好砸在了和尚的頭上，流血了，趕緊攔下一輛汽車去醫院。到了醫院，和尚失血太多口渴了，正好看到一臺飲水機。
把這個荒誕的故事想幾遍，然后再試著把這十個東西說出來，這回是不是感覺很容易？而且連順序都不會記錯！這就是聯想記憶的魔力。
那么學習知識也是這個道理：分散的知識是記不住的，只有梳理成體系，把相互之間的聯系和脈絡掌握了，再去理解這些分散的點就很容易記住了。這里的關鍵就是把這些知識點相互之間的關系掌握了，就像一張網一樣，隨便把一個知識點拎出來，都可以根據這張網把其他的知識點聯想起來。
這篇文章的內容包括：
物聯網云平臺，是如何驗證設備端的合法性？
SSL/TLS是什么？有什么作用？在哪些場合下使用？
OpenSSL是什么？它與SSL是什么關系？
OpenSSH又是什么？它與OpenSSL又有什么區別？
HTTPS中是如何利用SSL來交換秘鑰的？握手步驟是什么？
證書是什么？有什么作用？在哪些場合下使用？
證書是如何得到的？它的標準格式是什么？包含哪些內容？
認證機構是什么？什么是鏈式證書？
證書與SSL有什么關系？
簽名是什么意思？與加密是什么關系?
什么是單向認證？雙向認證?
另外補充一點：這篇文章只描述“是什么”，而不會描述“為什么”。“為什么”的事情留給那些數學家、密碼學家來搞定就可以了。
一個典型的物聯網產品
在實際的項目中，如果用到云平臺，一般來說選擇性就那么幾個：國外就用亞馬遜，國內就用阿里云，最近也碰到一些項目使用華為云。這里就以之前做過的一個空氣凈化器項目來舉例：
首先，亞馬遜提供了一套SDK，這個SDK中包含了一組API函數供應用程序調用，向云平臺進行安全連接、收發數據。在調用API函數的時候，必須提供一些必要的設備信息，這其中最重要的就是設備證書文件，也就是說，證書必須要預先存儲在設備的文件系統中。
那么，證書是在什么時候被放到空氣凈化器設備中的？當然是生產階段，看一下這個流程：
以上這個流程是在設備生產環節完成的，這里的描述還是屬于粗線條的，其他一些重要的信息沒有列出來，比如：AWS后臺如何產生證書、在連接階段后臺是如何通過證書來驗證設備的合法性的、廠商的秘鑰是如何工作的等等，這些問題等到這邊文章的末尾就自然明白了。
下面，就按照這些概念之間的相互關系來一步一步的梳理，每一個概念是按照相互之間的關系來逐步引入的，因此建議按照順序來理解。
數據加密
明文傳輸的缺點
我們知道，client端與server端之間傳輸數據，要么是明文傳輸、要么是加密傳輸。明文傳輸的缺點顯而易見：
數據容易比第三方截獲；
第三方可以篡改數據；
第三方可能會冒充server與你進行通信。
總之一句話：明文通信就像裸奔一樣，任何東西都被別人看的一清二楚，惡意的第三方很容易利用明文通信來做一些違法的事情。
所以，最好還是穿上衣服，最好還是帶密碼鎖的，這樣別人就看不到了！這就是加密傳輸。
加密傳輸
client端對傳輸的信息進行加密，server端接收到密文后再進行解密。例如上圖中：
client想發送字符串"hello"，那么就先加密成"ifmmp"，然后發送出去;
server接收到"ifmmp"，進行解密，得到"hello"。
但是示例中的加密方式太弱智了，稍微研究下就會搞明白，這里的加密方式就是把明文字符串中的每一個字符變成ascII碼表中的下一個字。server在解密時操作相反：把每一個字符變成ascII碼表中的前一個字符即可，只要client和server事先商量好這樣的加密和解密算法就可以通信了。
但是，這樣的加密方式太簡單了，惡意的第三方不會吹灰之力就可以破解出來，因此client與server之間需要更加復雜的加密算法，這就是SSL要解決的問題，這部分內容稍后再表。
加密方式
根據是否可以把密文還原成明文，加密方式分為兩類：
可逆加密;
不可逆加密。
剛才描述的加密、解密過程(“hello”->“ifmmp”->“hello”)是屬于可逆加密，也就是說可以把密文還原成明文，主要應用在通信場景中。如果一個密文不能還原成明文，就稱為不可逆加密，不可逆加密也非常重要。
可逆加密
剛才已經說到，可逆加密就是可以把密文還原成明文，只要client端和server端商量好加密算法(例如剛才所說的利用ascII表的下一個字符)就可以達到目的，也就是說：client端的加密算法和server端的解密算法是一樣的，當然了這里的算法太簡單。
我們可以稍微復雜一點點，先定義一個固定的字符串“258”，然后把明文"hello"中的每一個字符，用固定的字符串進行計算：先加2，再減5，最后加8，得到加密后的字符串"mjqqt"，server接收到之后再執行相反操作就解密得到明文“hello”。從算法角度看，這兩個加密方式是一樣的，但是第二種算法利用了一個獨立的、固定的字符串“258”，這個字符串就叫做秘鑰，當然，實際通信中使用的秘鑰更復雜。通信雙方是通過算法+秘鑰的方式來進行加密和解密。而且，通信雙方使用的秘鑰是相同的，這就叫做對稱加密。
既然存在對稱加密，那肯定就存在非對稱加密，也就是說，根據通信雙方使用的秘鑰是否相同，可逆加密分為2種：
對稱加密常用算法有：DES、AES；非對稱加密常用算法有：RSA、DH、ECC。
對稱加密的特點：
非對稱加密的特點：
既然非對稱加密的缺點這么明顯，那么它有什么作用呢？
回到剛才的通信示例場景中：client與server需要使用同一個秘鑰“258”，那么它們雙方應該如何協商得到這個對稱秘鑰呢？難道是使用固定的秘鑰嗎？顯然這個答案不太可能，需要通信的設備那么多，不可能像網卡的MAC地址那樣預先分配，而且秘鑰很容易泄漏。因此，這個對稱秘鑰一般都是在通信的剛開始的握手階段，由client與server動態的協商得到的。在這個協商的過程中，為了防止協商內容被第三方截獲，就需要使用非對稱加密來保證握手階段的數據安全性。
因為握手數據只發生在通信的剛開始階段，即使效率低一點也沒關系，安全比效率更重要。
一句話：非對稱加密在通信初始階段的協商過程中使用，用來得到一個對稱秘鑰，這個協商過程就叫做握手，在后面的HTTPS通信過程中，我們再詳細看一下握手過程。
不可逆加密
顧名思義，不可逆加密就是說把明文加密之后得到密文，但是不能從密文還原得到明文。從術語上來說，一般不把這個加密結果稱作密文，而是稱作摘要或者指紋。
不可逆加密原理：把一個任意大小的數據，經過一定的算法，轉換成規定長度的輸出。如果數據的內容發生了一絲絲的變化，再次加密就得到另一個不同的結果，而且是大不相同。從這個角度看，是不是稱作指紋更形象一些？
不可逆加密最常用的算法就是：MD5、SHA1。
回想一下：我們在下載一些軟件的時候，在服務器上除了看到軟件的下載地址，一般還會看到該軟件的MD5碼。我們把軟件下載到本地之后，計算得到MD5，也就是文件的指紋，然后把這個MD5與服務器上公布的MD5進行比較，如果這兩個MD5不一致，就說明下載的文件被別人修改過。
這是glib庫的下載頁面：
補充：SHA相關知識
SHA安全哈希算法，由美國國家標準技術研究院發布的一組加密函數。它是一種常用的摘要算法，就是輸入一段數據，輸出合法的證書一個摘要信息，包括SHA0、SHA1、SHA2等不同的版本。
代表安全哈希算法1，接收輸入，輸出一個160位的哈希值，稱作信息摘要。在2005年之后，SHA1被認為不安全。
SHA2指的是具有兩個不同塊大小的相似哈希函數的族，其中包括：SHA256，SHA512。SHA256可以輸出一個256位的哈希值，安全級別更高。
一個實際的使用場景：OTA升級
再來了解一下不可逆加密的特點：
公鑰和私鑰
上面說到了非對稱加密，那么就必須再補充一下私鑰和公鑰。從字面上就可以看出：它倆是一對兄弟，都是秘鑰，必須成對使用，稱作：秘鑰對。我們可以通過一些軟件工具(例如：OpenSSL)生成自己的公鑰和私鑰。
公鑰：就是公開告訴別人的；私鑰：就是自己的，作為寶貝一樣自己私藏起來，千萬不要告訴別人。
公鑰和私鑰的作用有2個：
數據加密就是上面描述的非對稱加密，例如：
張三想發一個文件給我，為了防止文件被其他人看到，于是張三用我的公鑰對文件進行加密，然后把加密后的文件發給我。我拿到密文后，用我的私鑰就可以把密文還原成原始的文件，其他人即使拿到了密文，但是沒有我的私鑰，就解不開文件。 如下面這張圖：
數字簽名與我們日常生活中的借條上的簽名類似，一旦簽名了，就具有法律效力，不能耍賴說：這個不是我簽名，我不認。具體流程是：我寫了一個文件，然后用我的私鑰對文件進行加密，那么如果以后我耍賴說：這個文件不是我寫的，其他人就可以用我的公鑰來嘗試對加密后的文件進行解密。如果成功解密了，就說明這個文件一定是用我的私鑰進行加密的，而私鑰只有我才有，那就說明這個文件一定是我寫的。如下圖：
證書
前面談到了公鑰是公開給別人的，本質上就是一段數據，那么這段數據是以什么樣的形式或者說以什么樣的載體發送給別人的呢？答案就是：證書。
如何申請證書
我們以一個網站為例，瀏覽器在訪問網站的時候，在握手階段，網站會把自己的證書發送給瀏覽器。那么這個證書是如何產生的呢？
Step1
在網站上線之初，需要把自己的相關信息放在一個請求文件中(server.req)，把請求文件發送給一個權威的認證機構。請求文件的內容包括：
網站的域名
申請者信息
公鑰
以及其他一些相關信息
Step2
認證機構通過其他途徑來確定申請者是合法的。
Step3
認證機構使用某個算法，對請求文件server.req中的信息進行計算，得到一個數字摘要。
算法包括：
MD5
SHA-1
SHA-256
信息包括：
申請者的基本信息：網站使用的加密算法、網站使用的hash算法；
申請者的公鑰；
認證機構的信息：認證機構的名稱，證書到期時間。
Step4
認證機構用自己的私鑰，對Step3中得到的數字摘要進行加密，得到數字簽名(也就證書簽名)。
Step5
認證機構把以上這些信息進行匯總，得到最終的證書文件server.crt，然后發給申請者。
最終，證書server.crt中的內容包括這幾個大類：
如何確認證書的合法性
現在，客戶端拿到了服務器發來的證書文件，應該如何驗證這是一個合法的證書呢？
Step1
讀取證書中的明文信息，包括：申請者的基本信息，申請者的公鑰，認證機構的信息。
Step2
從瀏覽器或者操作系統中查找這個認證機構的相關信息，得到這個認證機構的公鑰。
補充：瀏覽器或者操作系統中，一般都會預裝一些可信任的權威認證機構的證書列表，所以能拿到認證機構的公鑰。
Step3
使用認證機構相同的算法，對Step1中的明文信息進行計算，得到摘要1。
Step4
使用認證機構的公鑰，對證書中認證機構的數字簽名進行解密，得到摘要2。
Step5
比較摘要1與摘要2是否相同，如果相同，說明這個證書是合法的，也就證明當前訪問的是一個合法的服務器。
單向認證和雙向認證
上面描述的認證過程，是瀏覽器用來確認所訪問的網站是否是一個合法的網站；文章開頭所舉的例子：一個物聯網產品在連接云平臺的時候，是云平臺來驗證這個想連接進來的設備是否為一個合法的設備。
這兩個場景中都是單向認證，也就是通信的一方來驗證另一方是否合法。那么雙向認證就很好理解了：通信的每一方都要認證對方是否合法。
至于如何選擇使用單向認證或者雙向認證，甚至是不使用證書(只使用用戶名和密碼來鑒權)，這就需要根據實際的使用場景、安全等級、操作的難易程度來決定了。比如：在物聯網產品中，每一個產品都需要在生產階段把動態生成的證書燒寫到設備中，增加了生產環節的流程和成本，為了安全性，萬萬不可偷懶。如果沒有證書來驗證，那么黑客就可以模擬無數個設備，頻繁的連接到云平臺，這就存在極大的安全隱患。
認證機構
證書本質上就是一個文件，只不過這個文件具有特殊的一個性質：可以被證明是合法的。那么應該如何來證明呢？這就要來說一下認證機構。
認證機構(CA: Certificate Authority)是一個權威的組織，是被國家、行業認可的權威結構，不是隨便一個機構都有資格頒發證書，不然也不叫做權威機構。只要能證明一個證書是由CA機構頒發的，我們就認為這個證書是合法的，也就是說：證書的可信任性基于信任機制。
就像銀行貸款給個人一樣，銀行在放款之前，會到征信系統中查詢這個人的信用報告，如果征信系統中表明這個人的信用沒有問題，銀行相信征信系統，所以銀行就相信這個人，可以貸款給他，這是一個信任鏈的傳遞。
CA認證機構就類似于征信系統，相當于CA結構給證書進行了背書，它保證從它手里頒發的證書都是合法有效的，那么我們只要能證明證書是從CA認證機構頒發的，就可以認為證書是有效的。
證書鏈
CA認證機構是一個樹狀的結構，最頂部的稱為根認證機構。往下層是：二級認證機構、三級認證機構…。
根認證機構給二級認證機構頒發證書，二級認證機構給三級認證結構頒發證書…。不同等級的認證機構對審核的要求也不一樣，于是證書也分為免費的、便宜的和貴的。
你可能會問：那么根認證機構的證書是由誰簽名的？答案是：根認證機構自己簽名的，這也叫做自簽名。因為根認證機構是由國家或者行業組織認可的，已經是一個可以信賴的權威機構，所以可以為自己簽名。
另外，我們在測試的過程中，也常常利用OpenSSL中提供的程序來產生自簽名的證書，當然，這個測試的自簽名證書只能你自己玩，因為別人不信任你。
證書文件的后綴名
剛接觸到證書概念的小伙伴，常常被眼花繚亂的后綴名所迷惑。
首先要明確一點：證書文件的后綴名只是為了見名識意，實際上可以取任意的名字。常見的后綴名包括：
.crt：per格式的證書
.der: der格式的證書
.key：pem格式的私鑰
.pub：pem格式的公鑰
.req：申請證書時發送給CA認證機構的請求文件
.csr：也表示請求文件
證書文件的格式
所有證書內容格式有兩種：pem格式和der格式，這兩種格式的證書文件可以相互轉換，利用OpenSSL中的程序就可以完成。
PEM格式(Privacy Enhanced Mail)
pem格式的證書內容是經過加密的文本文件，一般是base64格式，可以用記事本來打開一個base64格式的證書，例如下面這個證書文件的內容：
-----BEGIN CERTIFICATE----- MIIGbzCCBFegAwIBAgIICZftEJ0fB/wwDQYJKoZIhvcNApQELBQAwfDELMAkGA1UE BhMCVVMxDjAMBgNVBAgMBVRleGFzMRAwDgYDVQQHDAdIb3VzdG9uMRgwFgYDVQQK DA9TU0wgQ29ycG9yYXRpb24xMTAvBgNVBAMMKFNTTC5jb20gUm9vdCBDZXJ0aWZp ... Nztr2Isaaz4LpMEo4mGCiGxec5mKr1w8AE9n6D91CvxR5/zL1VU1JCVC7sAtkdki vnN1/6jEKFJvlUr5/FX04JXeomIjXTI8ciruZ6HIkbtJup1n9Zxvmr9JQcFTsP2c bRbjaT7JD6MBidAWRCJWClR/5etTZwWwWrRCrzvIHC7WO6rCzwu69a+l7ofCKlWs y702dmPTKEdEfwhgLx0LxJr/Aw== -----END CERTIFICATE-----補充：base64算法就是把原始數據中按照每3個字節進行拆分，3個字節是24bit，然后把24bit分成4組，每組6bit，最后在每個6bit的簽名添加2個0，這樣得到的4組字節碼就可以用ascII碼來表示了。
DER格式(Distinguished Encoding Rules)
der格式的證書文件內容是經過加密的二進制數據，也就是說文件內容打開后是亂碼。
X.509標準
上面說到證書中包含了必要的信息，那么這些信息在文件中并不是隨意擺放的，而是要根據固定的格式來存儲，只有這樣才能通過軟件生成或解析。
那么這個固定的格式是由誰來規定的呢？這就是X.509標準與公共秘鑰證書。
X.509是一個體系、標準，用來規定一個證書的格式標準，CA認證結構在生成證書的時候，就根據這個標準把每部分信息寫入到證書文件中。
X.509包括3個版本：V1, V2和V3。每一個版本中頒發證書時，必須包含下列信息：
版本號：用來區分版本；
系列號：由CA認證機構給每一個證書分配一個唯一的數字編號；
算法簽名標識符：用來指定CA認證機構在頒發證書時使用的簽名算法；
認證機構：頒發證書的機構唯一名稱；
有效期限：證書有效期(開始時間和結束時間)；
主題信息：證書持有人的基本信息；
公鑰信息：證書持有者的公鑰；
認證結構簽名：以確保這個證書在頒發之后沒有被篡改過；
證書格式
總之：證書的核心功能就是安全的傳遞公鑰！
OpenPGP協議/標準
加密和證書的概念介紹完了，再來了解一個行業標準：OpenPGP。
OpenPGP是什么？
OpenPGP是一種非專有協議，為加密消息、簽名、私鑰和用于交換公鑰的證書定義了統一標準。
OpenPGP協議的實現
OpenPGP協議有2個實現：
PGP是一個加密程序，為數據通信提供了加密和驗證功能，通常用于簽名、加密和解密文本、電子郵件和文件。
GPG是PGP的開源實現。
OpenPGP的使用流程
Step1: 公布自己的公鑰
每個人把自己的公鑰上傳到公鑰服務器上(subkeys.pgp.net)，然后通過交換機制，所有的公鑰服務器最終都會包含你的公鑰，就類似域名服務器同步域名解析信息一樣。
由于公鑰服務器沒有檢查機制，任何人都可以用我的名義上傳公鑰，所以沒有辦法來保證服務器上的公鑰一定是可靠性。通常，我可以在網站上公布一個公鑰指紋，讓其他人下載我的公鑰之后，計算一下公鑰指紋，然后與我公布的指紋進行比對，以此來確認證書的有效性。
Step2: 獲取別人的公鑰
為了獲得別人的公鑰，可以讓對方直接發給我，也可以從公鑰服務器上下載。為了安全起見，需要對下載的公鑰使用其他機制進行安全認證，例如剛才說的指紋。
Step3: 用于加密
用對方的公鑰加密文件，發送給對方，對方用他自己的私鑰進行解密。
Step4: 用于簽名
用我的私鑰進行加密，把加密后文件發送給對方，對方用我的公鑰進行解密，只要能正確解密，就證明這個文件的確是我加密的。
SSL/TLS
SSL全稱是Secure Socket Layer(安全套階層協議)，它是一個安全協議，目的是用來為互聯網提供安全的數據傳輸。
SSL在工作過程中，就利用了前面描述的概念：對稱加密、非對稱加密、證書等。如果前面的概念都梳理清楚了，那么理解SSL也就不成問題了。
SSL協議有1，2，3這個三個版本，TLS是SSL V3標準化之后的產物。事實上現在用的都是TLS，但是大家都習慣了SSL這個稱呼。
協議分層
SSL協議最大的優點就是與應用層無關，在SSL協議的上層，可以運行一些高層應用協議，例如：HTTP, FTP, TELNET…，也就是說這些高層協議可以透明的建立在SSL協議層之上。
握手過程
SSL使用X.509標準，握手就是指客戶端與服務端在通信的開始階段進行鑒權和協商，最終目的是：
我們來一步一步梳理握手過程:
Step1
Client向Server發送如下信息：
隨機數1；
Client端支持的SSL版本號；
Client端支持的加密算法列表。
Step2
Server分析接收到的信息，返回如下信息給Client:
隨機數2；
選擇的加密算法；
Server證書
Step3
Client端驗證Server發來的證書是否有效，具體過程上面已經描述過。
如果驗證失敗，通信結束；
如果驗證通過，就產生隨機數3，并使用剛才的隨機數1、隨機數2，然后用選擇的算法生成一個對稱加密秘鑰，這個秘鑰就用于后面正常的數據通信中。
然后發送如下信息給Server:
隨機數3，并且用server證書中的公鑰進行加密；
此時，Cliend端的握手流程結束，因為已經達到了握手的最終目的：確認Server合法，得到對稱加密秘鑰。
Step4
Server端在接收到加密后的隨機數3時，用自己的私鑰進行解密，然后和之前的隨機數1、隨機數2一起，使用相同的算法生成對稱加密秘鑰。
至此，Server端的握手過程也就結束，下面就可以用對稱加密秘鑰來對數據進行加密了。
注意：上面描述的握手過程中是單向認證，也就是Client端驗證Server是否合法的。
如果需要雙向認證，那么客戶端也應該把自己的證書發送給Server，然后Server來驗證這個證書是否合法，確認證書合法之后才繼續執行后面面的握手流程。
HTTPS與SSL的關系
HTTPS拆開來就是：HTTP+SSL，就是在HTTP的下面增加了SSL安全傳輸協議層，在瀏覽器連接到服務器之后，就執行上面描述的SSL握手過程。握手結束之后，雙方得到對稱加密秘鑰，在HTTP協議看來是明文傳輸數據，下面的SSL層對數據進行加密和解密。
OpenSSL
OpenSSL是什么？
上面描述的SSL中這么多的東西都是協議(或者稱為標準)，協議只是規定了應該怎么做，但是具體的代碼實現應該由誰來做呢？我們在寫相關的SSL程序時好像從來沒有實現過這個協議，都是直接調用第三方提供的庫就達到了加密傳輸的目的。當然了，如果你實現過SSL協議，請允許我對你表示佩服，給你一萬個贊！
在編程領域，永遠都存在熱心腸的人！OpenSSL就是一個免費的SSL/TLS實現，就是說：OpenSSL實現了SSL/TLS協議中定義的所有功能，包括：
SSL2
SSL3
TLSv1
TLSv1.1
TLSv1.2
而且，OpenSSL是用C語言開發的，具有優秀的跨平臺特性，在Linux、Windows、BSD、MAC等平臺上可以執行。
具體來說，OpenSSL實現中，包括下面幾個功能模塊：
密碼算法庫
密碼算法庫中包括：
對稱加密算法: AES、DES等。
非對稱加密算法: DH、RSA、DSA、EC等。
信息摘要算法
信息摘要算法包括：MD5、SHA等。
秘鑰和證書管理
OpenSSL提供的CA應用程序就是一個小型的證書管理中心，實現了證書簽發的整個流程和證書管理的大部分機制，我們在學習的時候一般都會用OpenSSL中提供的CA程序來生成秘鑰對、自簽名等等。具體的內容包括：
證書秘鑰產生、請求產生、證書簽發、吊銷和驗證功能；
對證書的X.509標準解碼、PKCS#12/PKCS#7格式的編解碼；
提供了產生各種秘鑰對的函數；
SSL協議庫
實現了SSLv2、SSLv3、TLSv1.0協議。
應用程序
OpenSSL的應用程序是基于密碼算法庫和SSL協議庫實現的，是非常好的OpenSSL的API函數使用范例，主要包括：秘鑰生成、證書管理、格式轉換、數據加密和簽名、SSL測試以及其他輔助配置功能。
OpenSSH又是什么？
SSH
首先說一下SSH：Secure Shell(安全外殼協議)，又是一個協議，用來實現遠程登錄系統，我們通常利用SSH來傳輸命令行界面和遠程執行命令。
比如：在調試一個ARM系統時，可以通過串口助手連接到ARM板子上；但是更常用的調試場景是在PC機上遠程登錄到ARM系統中，執行ARM中的任何指令，這就是利用SSH來實現的。
SSH提供2種級別的安全驗證：
基于密碼；
基于秘鑰。
SSH中基于口令的安全驗證
只需要知道賬號和密碼，就可以遠程登錄到系統，我們一般常用的就是這用方式。但是不能保證我正在連接的設備就是我想連接的那臺設備，可能會有別的服務器冒充真正的服務器，也就是受到“中間人”這種方式的攻擊。
當然還經常遇到另一種錯誤：在局域網中有多臺設備，本想遠程連接到設備A中，由于IP地址記錯了，結果遠程登錄到另外一臺設備B上了，如果你的同事也正在調試設備B，接下來就是悲劇發生的時刻！
SSH中基于秘鑰的安全認證
Step1
首先為自己創建一個秘鑰對，并提前把公鑰放在需要訪問的服務器上，例如：放在賬號的家目錄中。
Step2
通過客戶端遠程登錄到服務器，把自己的公鑰發給服務器，并請服務器進行安全驗證。
Step3
服務器接收到請求后，在登錄賬號的家目錄下查找公鑰，然后與接收到的公鑰進行比對。
Step4
如果比對不一致，通信結束；如果比對一致，服務器就用公鑰加密一段數據(challenge)，并發送給客戶端。
Step5
客戶端接收到challenge，用私鑰進行解密，然后把結果發給服務器。
Step6
服務器把接收到的結果與Step4中的數據進行比對，如果一致則驗證通過。
SSH協議的實現
既然SSH是一個協議，那么就一定存在對應的實現，這就是OpenSSH，它是一個免費開源的SSH實現。
OpenSSH實現中，利用了OpenSSL中的加密和算法庫函數，這就是它倆之間的關系。
總結
到這里，與加密、證書相關的基礎概念都介紹完畢了，不知道你是否有所收獲。
如果你是初次接觸到這些東西，敬請放心，即使現在明白了，一個星期之后肯定忘記一多半了。只有經歷過幾個項目的歷練之后，才會有更深刻的理解和記憶，最后，祝您好運！
如果覺得文章不錯，請轉發、分享給您的朋友。
我會把十多年嵌入式開發中的項目實戰經驗進行總結、分享，相信不會讓你失望的！
轉載：歡迎轉載，但未經作者同意，必須保留此段聲明，必須在文章中給出原文連接。
推薦閱讀
[1] 原來gdb的底層調試原理這么簡單
[2] 生產者和消費者模式中的雙緩沖技術
[3] 深入LUA腳本語言，讓你徹底明白調試原理
[4] 一步步分析-如何用C實現面向對象編程
總結
以上是生活随笔為你收集整理的关于加密、证书的那些事的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 大学四年，工作四年，我把私藏了 8 年的
- 下一篇： 对称加密和非对称加密、公钥和私钥、单向认