1、基礎知識
這部分內容主要解釋一些概念和術語，最好是先理解這部分內容。
1.1、公鑰密碼體制(public-key cryptography)
公鑰密碼體制分爲三個部分，公鑰、私鑰、加密解密算法，它的加密解密過程如下：
加密：通過加密算法和公鑰對內容(或者說明文)進行加密，得到密文。加密過程需要用到公鑰。
解密：通過解密算法和私鑰對密文進行解密，得到明文。解密過程需要用到解密算法和私鑰。
注意，由公鑰加密的內容，只能由私鑰進行解密，也就是說，由公鑰加密的內容，如果不知道私鑰，是無法解密的。
公鑰密碼體制的公鑰和算法都是公開的(這是爲什麼叫公鑰密碼體制的原因)，私鑰是保密的。大家都以使用公鑰進行加密，但是隻有私鑰的持有者才能解密。在實際的使用中，有需要的人會生成一對公鑰和私鑰，把公鑰發佈出去給別人使用，自己保留私鑰。
1.2、對稱加密算法(symmetric key algorithms)
在對稱加密算法中，加密使用的密鑰和解密使用的密鑰是相同的。也就是說，加密和解密都是使用的同一個密鑰。因此對稱加密算法要保證安全性的話，密鑰要做好保密，只能讓使用的人知道，不能對外公開。這個和上面的公鑰密碼體制有所不同，公鑰密碼體制中加密是用公鑰，解密使用私鑰，而對稱加密算法中，加密和解密都是使用同一個密鑰，不區分公鑰和私鑰。
密鑰，一般就是一個字符串或數字，在加密或者解密時傳遞給加密/解密算法。前面在公鑰密碼體制中說到的公鑰、私鑰就是密鑰，公鑰是加密使用的密鑰，私鑰是解密使用的密鑰。
1.3、非對稱加密算法(asymmetric key algorithms)
在非對稱加密算法中，加密使用的密鑰和解密使用的密鑰是不相同的。前面所說的公鑰密碼體制就是一種非對稱加密算法，他的公鑰和是私鑰是不能相同的，也就是說加密使用的密鑰和解密使用的密鑰不同，因此它是一個非對稱加密算法。
1.4、RSA簡介
RSA是一種公鑰密碼體制，現在使用得很廣泛。
RSA密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密算法是公開的。
由公鑰加密的內容只能由私鑰進行解密，由私鑰加密的內容只能由公鑰進行解密。也就是說，RSA的這一對公鑰、私鑰都可以用來加密和解密，並且一方加密的內容可以由並且只能由對方進行解密。
1.5、簽名和加密
我們說加密，是指對某個內容加密，加密後的內容還可以通過解密進行還原。
比如我們把一封郵件進行加密，加密後的內容在網絡上進行傳輸，接收者在收到後，通過解密可以還原郵件的真實內容。
這裏主要解釋一下簽名，簽名就是在信息的後面再加上一段內容，可以證明信息沒有被修改過，怎麼樣可以達到這個效果呢？一般是對信息做一個hash計算得到一個hash值，注意，這個過程是不可逆的，也就是說無法通過hash值得出原來的信息內容。在把信息發送出去時，把這個hash值加密後做爲一個簽名和信息一起發出去。
接收方在收到信息後，會重新計算信息的hash值，並和信息所附帶的hash值(解密後)進行對比，如果一致，就說明信息的內容沒有被修改過，因爲這裏hash計算可以保證不同的內容一定會得到不同的hash值，所以只要內容一被修改，根據信息內容計算的hash值就會變化。當然，不懷好意的人也可以修改信息內容的同時也修改hash值，從而讓它們可以相匹配，爲了防止這種情況，hash值一般都會加密後(也就是簽名)再和信息一起發送，以保證這個hash值不被修改。至於如何讓別人可以解密這個簽名，這個過程涉及到數字證書等概念，我們後面在說到數字證書時再詳細說明，這裏先理解簽名的這個概念。
2、一個加密通信過程的演化
我們來看一個例子，現在假設“服務器”和“客戶”要在網絡上通信，並且他們打算使用RSA來對通信進行加密以保證談話內容的安全。由於是使用RSA這種公鑰密碼體制，“服務器”需要對外發布公鑰(算法不需要公佈，RSA的算法大家都知道)，自己留着私鑰。“客戶”通過某些途徑拿到了“服務器”發佈的公鑰，客戶並不知道私鑰。“客戶”具體是通過什麼途徑獲取公鑰的，我們後面再來說明，下面看一下雙方如何進行保密的通信：
2.1 第一回合：
“客戶”->“服務器”：你好
“服務器”->“客戶”：你好，我是服務器
“客戶”->“服務器”：？？？？
因爲消息是在網絡上傳輸的，有人可以冒充自己是“服務器”來向客戶發送信息。例如上面的消息可以被黑客截獲如下：
“客戶”->“服務器”：你好
“服務器”->“客戶”：你好，我是服務器
“客戶”->“黑客”：你好 // 黑客在“客戶”和“服務器”之間的某個路由器上截獲“客戶”發給服務器的信息，然後自己冒充“服務器”
“黑客”->“客戶”：你好，我是服務器
因此“客戶”在接到消息後，並不能肯定這個消息就是由“服務器”發出的，某些“黑客”也可以冒充“服務器”發出這個消息。如何確定信息是由“服務器”發過來的呢？有一個解決方法，因爲只有服務器有私鑰，所以如果只要能夠確認對方有私鑰，那麼對方就是“服務器”。因此通信過程可以改進爲如下：
2.2 第二回合：
“客戶”->“服務器”：你好
“服務器”->“客戶”：你好，我是服務器
“客戶”->“服務器”：向我證明你就是服務器
“服務器”->“客戶”：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
// 注意這裏約定一下，{}表示RSA加密後的內容，[ | ]表示用什麼密鑰和算法進行加密，後面的示例中都用這種表示方式，例 如上面的 {你好，我是服務器}[私鑰|RSA]
就表示用私鑰對“你好，我是服務器”進行加密後的結果。
爲了向“客戶”證明自己是“服務器”， “服務器”把一個字符串用自己的私鑰加密，把明文和加密後的密文一起發給“客戶”。對於這裏的例子來說，就是把字符串 “你好，我是服務器”和這個字符串用私鑰加密後的內容 {你好，我是服務器}[私鑰|RSA] 發給客戶。
“客戶”收到信息後，它用自己持有的公鑰解密密文，和明文進行對比，如果一致，說明信息的確是由服務器發過來的。也就是說“客戶”把 {你好，我是服務器}[私鑰|RSA] 這個內容用公鑰進行解密，然後和“你好，我是服務器”對比。因爲由“服務器”用私鑰加密後的內容，只能由公鑰進行解密，私鑰只有“服務器”持有，所以如果解密出來的內容是能夠對得上的，那說明信息一定是從“服務器”發過來的。
假設“黑客”想冒充“服務器”：
“黑客”->“客戶”：你好，我是服務器
“客戶”->“黑客”：向我證明你就是服務器
“黑客”->“客戶”：你好，我是服務器 {你好，我是服務器}[？？？|RSA] //這裏黑客無法冒充，因爲它不知道私鑰，無法用私鑰加密某個字符串後發送給客戶去驗證。
“客戶”->“黑客”：？？？？
由於“黑客”沒有“服務器”的私鑰，因此它發送過去的內容，“客戶”是無法通過服務器的公鑰解密的，因此可以認定對方是個冒牌貨！
到這裏爲止，“客戶”就可以確認“服務器”的身份了，可以放心和“服務器”進行通信，但是這裏有一個問題，通信的內容在網絡上還是無法保密。爲什麼無法保密呢？通信過程不是可以用公鑰、私鑰加密嗎？其實用RSA的私鑰和公鑰是不行的，我們來具體分析下過程，看下面的演示：
2.3 第三回合：
“客戶”->“服務器”：你好
“服務器”->“客戶”：你好，我是服務器
“客戶”->“服務器”：向我證明你就是服務器
“服務器”->“客戶”：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
“客戶”->“服務器”：{我的帳號是aaa，密碼是123，把我的餘額的信息發給我看看}[公鑰|RSA]
“服務器”->“客戶”：{你的餘額是100元}[私鑰|RSA]
注意上面的的信息 {你的餘額是100元}[私鑰]，這個是“服務器”用私鑰加密後的內容，但是我們之前說了，公鑰是發佈出去的，因此所有的人都知道公鑰，所以除了“客戶”，其它的人也可以用公鑰對{你的餘額是100元}[私鑰]進行解密。所以如果“服務器”用私鑰加密發給“客戶”，這個信息是無法保密的，因爲只要有公鑰就可以解密這內容。然而“服務器”也不能用公鑰對發送的內容進行加密，因爲“客戶”沒有私鑰，發送個“客戶”也解密不了。
這樣問題就又來了，那又如何解決呢？在實際的應用過程，一般是通過引入對稱加密來解決這個問題，看下面的演示：
2.4 第四回合：
“客戶”->“服務器”：你好
“服務器”->“客戶”：你好，我是服務器
“客戶”->“服務器”：向我證明你就是服務器
“服務器”->“客戶”：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
“客戶”->“服務器”：{我們後面的通信過程，用對稱加密來進行，這裏是對稱加密算法和密鑰}[公鑰|RSA] //藍色字體的部分是對稱加密的算法和密鑰的具體內容，客戶把它們發送給服務器。
“服務器”->“客戶”：{OK，收到！}[密鑰|對稱加密算法]
“客戶”->“服務器”：{我的帳號是aaa，密碼是123，把我的餘額的信息發給我看看}[密鑰|對稱加密算法]
“服務器”->“客戶”：{你的餘額是100元}[密鑰|對稱加密算法]
在上面的通信過程中，“客戶”在確認了“服務器”的身份後，“客戶”自己選擇一個對稱加密算法和一個密鑰，把這個對稱加密算法和密鑰一起用公鑰加密後發送給“服務器”。注意，由於對稱加密算法和密鑰是用公鑰加密的，就算這個加密後的內容被“黑客”截獲了，由於沒有私鑰，“黑客”也無從知道對稱加密算法和密鑰的內容。
由於是用公鑰加密的，只有私鑰能夠解密，這樣就可以保證只有服務器可以知道對稱加密算法和密鑰，而其它人不可能知道(這個對稱加密算法和密鑰是“客戶”自己選擇的，所以“客戶”自己當然知道如何解密加密)。這樣“服務器”和“客戶”就可以用對稱加密算法和密鑰來加密通信的內容了。
總結一下，RSA加密算法在這個通信過程中所起到的作用主要有兩個：
因爲私鑰只有“服務器”擁有，因此“客戶”可以通過判斷對方是否有私鑰來判斷對方是否是“服務器”。
客戶端通過RSA的掩護，安全地和服務器商量好一個對稱加密算法和密鑰來保證後面通信過程內容的安全。
如果這裏您理解了爲什麼不用RSA去加密通信過程，而是要再確定一個對稱加密算法來保證通信過程的安全，那麼就說明前面的內容您已經理解了。
到這裏，“客戶”就可以確認“服務器”的身份，並且雙方的通信內容可以進行加密，其他人就算截獲了通信內容，也無法解密。的確，好像通信的過程是比較安全了。
但是這裏還留有一個問題，在最開始我們就說過，“服務器”要對外發布公鑰，那“服務器”如何把公鑰發送給“客戶”呢？我們第一反應可能會想到以下的兩個方法：
a)把公鑰放到互聯網的某個地方的一個下載地址，事先給“客戶”去下載。
b)每次和“客戶”開始通信時，“服務器”把公鑰發給“客戶”。
但是這個兩個方法都有一定的問題，
對於a)方法，“客戶”無法確定這個下載地址是不是“服務器”發佈的，你憑什麼就相信這個地址下載的東西就是“服務器”發佈的而不是別人僞造的呢，萬一下載到一個假的怎麼辦？另外要所有的“客戶”都在通信前事先去下載公鑰也很不現實。
對於b)方法，也有問題，因爲任何人都可以自己生成一對公鑰和私鑰，他只要向“客戶”發送他自己的公鑰就可以冒充“服務器”了。示意如下：
“客戶”->“黑客”：你好 //黑客截獲“客戶”發給“服務器”的消息
“黑客”->“客戶”：你好，我是服務器，這個是我的公鑰 //黑客自己生成一對公鑰和私鑰，把公鑰發給“客戶”，自己保留私鑰
“客戶”->“黑客”：向我證明你就是服務器
“黑客”->“客戶”：你好，我是服務器
{你好，我是服務器}[黑客自己的私鑰|RSA] //客戶收到“黑客”用私鑰加密的信息後，是可以用“黑客”發給自己的公鑰解密的，從而會誤認爲“黑客”是“服務器”
因此“黑客”只需要自己生成一對公鑰和私鑰，然後把公鑰發送給“客戶”，自己保留私鑰，這樣由於“客戶”可以用黑客的公鑰解密黑客的私鑰加密的內容，“客戶”就會相信“黑客”是“服務器”，從而導致了安全問題。這裏問題的根源就在於，大家都可以生成公鑰、私鑰對，無法確認公鑰對到底是誰的。 如果能夠確定公鑰到底是誰的，就不會有這個問題了。例如，如果收到“黑客”冒充“服務器”發過來的公鑰，經過某種檢查，如果能夠發現這個公鑰不是“服務器”的就好了。
爲了解決這個問題，數字證書出現了，它可以解決我們上面的問題。先大概看下什麼是數字證書，一個證書包含下面的具體內容：
證書的發佈機構
證書的有效期
公鑰
證書所有者（Subject）
簽名所使用的算法
指紋以及指紋算法
證書的內容的詳細解釋會在後面詳細解釋，這裏先只需要搞清楚一點，數字證書可以保證數字證書裏的公鑰確實是這個證書的所有者(Subject)的，或者證書可以用來確認對方的身份。也就是說，我們拿到一個數字證書，我們可以判斷出這個數字證書到底是誰的。至於是如何判斷的，後面會在詳細討論數字證書時詳細解釋。現在把前面的通信過程使用數字證書修改爲如下：
2.5 第五回合：
“客戶”->“服務器”：你好
“服務器”->“客戶”：你好，我是服務器，這裏是我的數字證書 //這裏用證書代替了公鑰
“客戶”->“服務器”：向我證明你就是服務器
“服務器”->“客戶”：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
注意，上面第二次通信，“服務器”把自己的證書發給了“客戶”，而不是發送公鑰。“客戶”可以根據證書校驗這個證書到底是不是“服務器”的，也就是能校驗這個證書的所有者是不是“服務器”，從而確認這個證書中的公鑰的確是“服務器”的。後面的過程和以前是一樣，“客戶”讓“服務器”證明自己的身份，“服務器”用私鑰加密一段內容連同明文一起發給“客戶”，“客戶”把加密內容用數字證書中的公鑰解密後和明文對比，如果一致，那麼對方就確實是“服務器”，然後雙方協商一個對稱加密來保證通信過程的安全。到這裏，整個過程就完整了，我們回顧一下：
2.6 完整過程：
step1： “客戶”向服務端發送一個通信請求
“客戶”->“服務器”：你好
step2： “服務器”向客戶發送自己的數字證書。證書中有一個公鑰用來加密信息，私鑰由“服務器”持有
“服務器”->“客戶”：你好，我是服務器，這裏是我的數字證書
step3： “客戶”收到“服務器”的證書後，它會去驗證這個數字證書到底是不是“服務器”的，數字證書有沒有什麼問題，數字證書如果檢查沒有問題，就說明數字證書中的公鑰確實是“服務器”的。檢查數字證書後，“客戶”會發送一個隨機的字符串給“服務器”用私鑰去加密，服務器把加密的結果返回給“客戶”，“客戶”用公鑰解密這個返回結果，如果解密結果與之前生成的隨機字符串一致，那說明對方確實是私鑰的持有者，或者說對方確實是“服務器”。
“客戶”->“服務器”：向我證明你就是服務器，這是一個隨機字符串 //前面的例子中爲了方便解釋，用的是“你好”等內容，實際情況下一般是隨機生成的一個字符串。
“服務器”->“客戶”：{一個隨機字符串}[私鑰|RSA]
step4： 驗證“服務器”的身份後，“客戶”生成一個對稱加密算法和密鑰，用於後面的通信的加密和解密。這個對稱加密算法和密鑰，“客戶”會用公鑰加密後發送給“服務器”，別人截獲了也沒用，因爲只有“服務器”手中有可以解密的私鑰。這樣，後面“服務器”和“客戶”就都可以用對稱加密算法來加密和解密通信內容了。
“服務器”->“客戶”：{OK，已經收到你發來的對稱加密算法和密鑰！有什麼可以幫到你的？}[密鑰|對稱加密算法]
“客戶”->“服務器”：{我的帳號是aaa，密碼是123，把我的餘額的信息發給我看看}[密鑰|對稱加密算法]
“服務器”->“客戶”：{你好，你的餘額是100元}[密鑰|對稱加密算法]
…… //繼續其它的通信
2.7 其它問題：
上面的過程已經十分接近HTTPS的真實通信過程了，完全可以按照這個過程去理解HTTPS的工作原理。
【問題1】
上面的通信過程中說到，在檢查完證書後，“客戶”發送一個隨機的字符串給“服務器”去用私鑰加密，以便判斷對方是否真的持有私鑰。但是有一個問題，“黑客”也可以發送一個字符串給“服務器”去加密並且得到加密後的內容，這樣對於“服務器”來說是不安全的，因爲黑客可以發送一些簡單的有規律的字符串給“服務器”加密，從而尋找加密的規律，有可能威脅到私鑰的安全。所以說，“服務器”隨隨便便用私鑰去加密一個來路不明的字符串並把結果發送給對方是不安全的。
〖解決方法〗
每次收到“客戶”發來的要加密的的字符串時，“服務器”並不是真正的加密這個字符串本身，而是把這個字符串進行一個hash計算，加密這個字符串的hash值(不加密原來的字符串)後發送給“客戶”，“客戶”收到後解密這個hash值並自己計算字符串的hash值然後進行對比是否一致。也就是說，“服務器”不直接加密收到的字符串，而是加密這個字符串的一個hash值，這樣就避免了加密那些有規律的字符串，從而降低被破解的機率。“客戶”自己發送的字符串，因此它自己可以計算字符串的hash值，然後再把“服務器”發送過來的加密的hash值和自己計算的進行對比，同樣也能確定對方是否是“服務器”。
【問題2】
在雙方的通信過程中，“黑客”可以截獲發送的加密了的內容，雖然他無法解密這個內容，但是他可以搗亂，例如把信息原封不動的發送多次，擾亂通信過程。
〖解決方法〗
可以給通信的內容加上一個序號或者一個隨機的值，如果“客戶”或者“服務器”接收到的信息中有之前出現過的序號或者隨機值，那麼說明有人在通信過程中重發信息內容進行搗亂，雙方會立刻停止通信。有人可能會問，如果有人一直這麼搗亂怎麼辦？那不是無法通信了？ 答案是的確是這樣的，例如有人控制了你連接互聯網的路由器，他的確可以針對你。但是一些重要的應用，例如軍隊或者政府的內部網絡，它們都不使用我們平時使用的公網，因此一般人不會破壞到他們的通信。
【問題3】
在雙方的通信過程中，“黑客”除了簡單的重複發送截獲的消息之外，還可以修改截獲後的密文修改後再發送，因爲修改的是密文，雖然不能完全控制消息解密後的內容，但是仍然會破壞解密後的密文。因此發送過程如果黑客對密文進行了修改，“客戶”和“服務器”是無法判斷密文是否被修改的。雖然不一定能達到目的，但是“黑客”可以一直這樣碰碰運氣。
〖解決方法〗
在每次發送信息時，先對信息的內容進行一個hash計算得出一個hash值，將信息的內容和這個hash值一起加密後發送。接收方在收到後進行解密得到明文的內容和hash值，然後接收方再自己對收到信息內容做一次hash計算，與收到的hash值進行對比看是否匹配，如果匹配就說明信息在傳輸過程中沒有被修改過。如果不匹配說明中途有人故意對加密數據進行了修改，立刻中斷通話過程後做其它處理。
3. 證書的構成和原理
3.1 證書的構成和原理
之前已經大概說了一個證書由什麼構成，但是沒有仔細進行介紹，這裏對證書的內容做一個詳細的介紹。先看下一個證書到底是個什麼東西，在windows下查看一個證書時，裏面的內容比較多——Version、Serial number、Signature algorithm 等等，挑幾個重要的解釋一下。
◆Issuer (證書的發佈機構)
指出是什麼機構發佈的這個證書，也就是指明這個證書是哪個公司創建的(只是創建證書，不是指證書的使用者)。
◆Valid from , Valid to (證書的有效期)
也就是證書的有效時間，或者說證書的使用期限。 過了有效期限，證書就會作廢，不能使用了。
◆Public key (公鑰)
公鑰是用來對消息進行加密的。是很長的一串數字或者字符串。
◆Subject (主題)
這個證書是發佈給誰的，或者說證書的所有者，一般是某個人或者某個公司名稱、機構的名稱、公司網站的網址等。
◆Signature algorithm (簽名所使用的算法)
就是指的這個數字證書的數字簽名所使用的加密算法，這樣就可以使用證書發佈機構的證書裏面的公鑰，根據這個算法對指紋進行解密。指紋的加密結果就是數字簽名。
◆Thumbprint, Thumbprint algorithm (指紋以及指紋算法)
這個是用來保證證書的完整性的，也就是說確保證書沒有被修改過，這東西的作用和2.7中說到的第3個問題類似。 其原理就是在發佈證書時，發佈者根據指紋算法(一個hash算法)計算整個證書的hash值(指紋)並和證書放在一起，使用者在打開證書時，自己也根據指紋算法計算一下證書的hash值(指紋)，如果和剛開始的值對得上，就說明證書沒有被修改過，因爲證書的內容被修改後，根據證書的內容計算的出的hash值(指紋)是會變化的。
注意，這個指紋會使用"SecureTrust CA"這個證書機構的私鑰用簽名算法(Signature algorithm)加密後和證書放在一起。
注意，爲了保證安全，在證書的發佈機構發佈證書時，證書的指紋和指紋算法，都會加密後再和證書放到一起發佈，以防有人修改指紋後僞造相應的數字證書。這裏問題又來了，證書的指紋和指紋算法用什麼加密呢？他們是用證書發佈機構的私鑰進行加密的。可以用證書發佈機構的公鑰對指紋和指紋算法解密，也就是說證書發佈機構除了給別人發佈證書外，他自己本身也有自己的證書。證書發佈機構的證書是哪裏來的呢？？？這個證書發佈機構的數字證書(一般由他自己生成)在我們的操作系統剛安裝好時(例如windowsxp等操作系統)，這些證書發佈機構的數字證書就已經被微軟(或者其它操作系統的開發機構)安裝在操作系統中了，微軟等公司會根據一些權威安全機構的評估選取一些信譽很好並且通過一定的安全認證的證書發佈機構，把這些證書發佈機構的證書默認就安裝在操作系統裏面了，並且設置爲操作系統信任的數字證書。這些證書發佈機構自己持有與他自己的數字證書對應的私鑰，他會用這個私鑰加密所有他發佈的證書的指紋作爲數字簽名。
3.2 如何向證書的發佈機構去申請證書
舉個例子方便大家理解，假設我們公司"ABC Company"花了1000塊錢，向一個證書發佈機構"SecureTrust CA"爲我們自己的公司"ABC Company"申請了一張證書，注意，這個證書發佈機構"SecureTrust CA"是一個大家公認並被一些權威機構接受的證書發佈機構，我們的操作系統裏面已經安裝了"SecureTrust CA"的證書。"SecureTrust CA"在給我們發佈證書時，把Issuer,Public
key,Subject,Valid from,Valid to等信息以明文的形式寫到證書裏面，然後用一個指紋算法計算出這些數字證書內容的一個指紋，並把指紋和指紋算法用自己的私鑰進行加密，然後和證書的內容一起發佈，同時"SecureTrust
CA"還會給一個我們公司"ABC Company"的私鑰給到我們。我們花了1000塊錢買的這個證書的內容如下：
×××××××××××××××證書內容開始×××××××××××××××××
Issuer : SecureTrust CA
Subject : ABC Company
Valid from ： 某個日期
Valid to： 某個日期
Public Key : 一串很長的數字
其它的一些證書內容
{證書的指紋和計算指紋所使用的指紋算法}[SecureTrust CA的私鑰|RSA] //這個就是"SecureTrust
CA"對這個證書的一個數字簽名，表示這個證書確實是他發佈的，有什麼問題他會負責(收了我們1000塊，出了問題肯定要負責任的)
×××××××××××××××證書內容結束×××××××××××××××××
我們"ABC Company"申請到這個證書後，我們把證書投入使用，我們在通信過程開始時會把證書發給對方，對方如何檢查這個證書的確是合法的並且是我們"ABC Company"公司的證書呢？首先應用程序(對方通信用的程序，例如IE、OUTLook等)讀取證書中的Issuer(發佈機構)爲"SecureTrust
CA" ，然後會在操作系統中受信任的發佈機構的證書中去找"SecureTrust CA"的證書，如果找不到，那說明證書的發佈機構是個水貨發佈機構，證書可能有問題，程序會給出一個錯誤信息。 如果在系統中找到了"SecureTrust CA"的證書，那麼應用程序就會從證書中取出"SecureTrust CA"的公鑰，然後對我們"ABC
Company"公司的證書裏面的指紋和指紋算法用這個公鑰進行解密，然後使用這個指紋算法計算"ABC Company"證書的指紋，將這個計算的指紋與放在證書中的指紋對比，如果一致，說明"ABC
Company"的證書肯定沒有被修改過並且證書是"SecureTrust CA" 發佈的，證書中的公鑰肯定是"ABC Company"的。對方然後就可以放心的使用這個公鑰和我們"ABC
Company"進行通信了。
這個部分非常重要，一定要理解，您可以重新回顧一下之前的兩章“1、基礎知識”和“2、一個加密通信過程的演化”，然後再來理解這部分的內容。
原文鏈接：https://blog.csdn.net/junehappylove/article/details/52288796