數字證書原理（轉）

原文地址：http://blog.csdn.net/zhulinfeiba/article/details/5957028

文中首先解釋了加密解密的一些基礎知識和概念，而後經過一個加密通訊過程的例子說明了加密算法的做用，以及數字證書的出現所起的做用。接着對數字證書作一個詳細的解釋，並討論一下windows中數字證書的管理，最後演示使用makecert生成數字證書。若是發現文中有錯誤的地方，或者有什麼地方說得不夠清楚，歡迎指出！

 

一、基礎知識

      這部份內容主要解釋一些概念和術語，最好是先理解這部份內容。

1.一、公鑰密碼體制(public-key cryptography)

公鑰密碼體制分爲三個部分，公鑰、私鑰、加密解密算法，它的加密解密過程以下：

• 加密：經過加密算法和公鑰對內容(或者說明文)進行加密，獲得密文。加密過程須要用到公鑰。
• 解密：經過解密算法和私鑰對密文進行解密，獲得明文。解密過程須要用到解密算法和私鑰。注意，由公鑰加密的內容，只能由私鑰進行解密，也就是說，由公鑰加密的內容，若是不知道私鑰，是沒法解密的。

公鑰密碼體制的公鑰和算法都是公開的(這是爲何叫公鑰密碼體制的緣由)，私鑰是保密的。你們都以使用公鑰進行加密，可是隻有私鑰的持有者才能解密。在實際的使用中，有須要的人會生成一對公鑰和私鑰，把公鑰發佈出去給別人使用，本身保留私鑰。

 

1.二、對稱加密算法(symmetric key algorithms)

在對稱加密算法中，加密使用的密鑰和解密使用的密鑰是相同的。也就是說，加密和解密都是使用的同一個密鑰。所以對稱加密算法要保證安全性的話，密鑰要作好保密，只能讓使用的人知道，不能對外公開。這個和上面的公鑰密碼體制有所不一樣，公鑰密碼體制中加密是用公鑰，解密使用私鑰，而對稱加密算法中，加密和解密都是使用同一個密鑰，不區分公鑰和私鑰。

 

        // 密鑰，通常就是一個字符串或數字，在加密或者解密時傳遞給加密/解密算法。前面在公鑰密碼體制中說到的公鑰、私鑰就是密鑰，公鑰是加密使用的密鑰，私鑰是解密使用的密鑰。

 

1.三、非對稱加密算法(asymmetric key algorithms)

在非對稱加密算法中，加密使用的密鑰和解密使用的密鑰是不相同的。前面所說的公鑰密碼體制就是一種非對稱加密算法，他的公鑰和是私鑰是不能相同的，也就是說加密使用的密鑰和解密使用的密鑰不一樣，所以它是一個非對稱加密算法。

 

1.四、RSA簡介

RSA是一種公鑰密碼體制，如今使用得很普遍。若是對RSA自己有興趣的，後面看我有沒有時間寫個RSA的具體介紹。

RSA密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密算法是公開的。 由公鑰加密的內容能夠而且只能由私鑰進行解密，而且由私鑰加密的內容能夠而且只能由公鑰進行解密。也就是說，RSA的這一對公鑰、私鑰均可以用來加密和解密，而且一方加密的內容能夠由而且只能由對方進行解密。

 

1.五、簽名和加密

咱們說加密，是指對某個內容加密，加密後的內容還能夠經過解密進行還原。 好比咱們把一封郵件進行加密，加密後的內容在網絡上進行傳輸，接收者在收到後，經過解密能夠還原郵件的真實內容。

這裏主要解釋一下簽名，簽名就是在信息的後面再加上一段內容，能夠證實信息沒有被修改過，怎麼樣能夠達到這個效果呢？通常是對信息作一個hash計算獲得一個hash值，注意，這個過程是不可逆的，也就是說沒法經過hash值得出原來的信息內容。在把信息發送出去時，把這個hash值加密後作爲一個簽名和信息一塊兒發出去。 接收方在收到信息後，會從新計算信息的hash值，並和信息所附帶的hash值(解密後)進行對比，若是一致，就說明信息的內容沒有被修改過，由於這裏hash計算能夠保證不一樣的內容必定會獲得不一樣的hash值，因此只要內容一被修改，根據信息內容計算的hash值就會變化。固然，不懷好意的人也能夠修改信息內容的同時也修改hash值，從而讓它們能夠相匹配，爲了防止這種狀況，hash值通常都會加密後(也就是簽名)再和信息一塊兒發送，以保證這個hash值不被修改。至於如何讓別人能夠解密這個簽名，這個過程涉及到數字證書等概念，咱們後面在說到數字證書時再詳細說明，這裏您先只需先理解簽名的這個概念。

 

二、一個加密通訊過程的演化

      咱們來看一個例子，如今假設「服務器」和「客戶」要在網絡上通訊，而且他們打算使用RSA(參看前面的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去加密通訊過程，而是要再肯定一個對稱加密算法來保證通訊過程的安全，那麼就說明前面的內容您已經理解了。(若是不清楚，再看下2.3和2.4，若是仍是不清楚，那應該是咱們說清楚，您能夠留言提問。)

到這裏，「客戶」就能夠確認「服務器」的身份，而且雙方的通訊內容能夠進行加密，其餘人就算截獲了通訊內容，也沒法解密。的確，好像通訊的過程是比較安全了。

 

可是這裏還留有一個問題，在最開始咱們就說過，「服務器」要對外發布公鑰，那「服務器」如何把公鑰發送給「客戶」呢？咱們第一反應可能會想到如下的兩個方法：

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下查看一個證書時，界面是這樣的，咱們主要關注一下Details Tab頁，其中的內容比較長，我滾動內容後後抓了三個圖，把完整的信息顯示出來：

裏面的內容比較多——Version、Serial number、Signature algorithm 等等，挑幾個重要的解釋一下。

 

◆Issuer (證書的發佈機構)

指出是什麼機構發佈的這個證書，也就是指明這個證書是哪一個公司建立的(只是建立證書，不是指證書的使用者)。對於上面的這個證書來講，就是指"SecureTrust CA"這個機構。

 

◆Valid from , Valid to (證書的有效期)

也就是證書的有效時間，或者說證書的使用期限。 過了有效期限，證書就會做廢，不能使用了。

 

◆Public key (公鑰)

這個咱們在前面介紹公鑰密碼體制時介紹過，公鑰是用來對消息進行加密的，第2章的例子中常常用到的。這個數字證書的公鑰是2048位的，它的值能夠在圖的中間的那個對話框中看獲得，是很長的一串數字。

 

◆Subject (主題)

這個證書是發佈給誰的，或者說證書的全部者，通常是某我的或者某個公司名稱、機構的名稱、公司網站的網址等。 對於這裏的證書來講，證書的全部者是Trustwave這個公司。

 

◆Signature algorithm (簽名所使用的算法)

就是指的這個數字證書的數字簽名所使用的加密算法，這樣就可使用證書發佈機構的證書裏面的公鑰，根據這個算法對指紋進行解密。指紋的加密結果就是數字簽名(第1.5節中解釋過數字簽名)。

 

◆Thumbprint, Thumbprint algorithm (指紋以及指紋算法)

這個是用來保證證書的完整性的，也就是說確保證書沒有被修改過，這東西的做用和2.7中說到的第3個問題相似。 其原理就是在發佈證書時，發佈者根據指紋算法(一個hash算法)計算整個證書的hash值(指紋)並和證書放在一塊兒，使用者在打開證書時，本身也根據指紋算法計算一下證書的hash值(指紋)，若是和剛開始的值對得上，就說明證書沒有被修改過，由於證書的內容被修改後，根據證書的內容計算的出的hash值(指紋)是會變化的。 注意，這個指紋會使用"SecureTrust CA"這個證書機構的私鑰用簽名算法(Signature algorithm)加密後和證書放在一塊兒。

 

注意，爲了保證安全，在證書的發佈機構發佈證書時，證書的指紋和指紋算法，都會加密後再和證書放到一塊兒發佈，以防有人修改指紋後僞造相應的數字證書。這裏問題又來了，證書的指紋和指紋算法用什麼加密呢？他們是用證書發佈機構的私鑰進行加密的。能夠用證書發佈機構的公鑰對指紋和指紋算法解密，也就是說證書發佈機構除了給別人發佈證書外，他本身自己也有本身的證書。證書發佈機構的證書是哪裏來的呢？？？這個證書發佈機構的數字證書(通常由他本身生成)在咱們的操做系統剛安裝好時(例如windows xp等操做系統)，這些證書發佈機構的數字證書就已經被微軟(或者其它操做系統的開發機構)安裝在操做系統中了，微軟等公司會根據一些權威安全機構的評估選取一些信譽很好而且經過必定的安全認證的證書發佈機構，把這些證書發佈機構的證書默認就安裝在操做系統裏面了，而且設置爲操做系統信任的數字證書。這些證書發佈機構本身持有與他本身的數字證書對應的私鑰，他會用這個私鑰加密全部他發佈的證書的指紋做爲數字簽名。

 

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塊，出了問題確定要負責任的)

×××××××××××××××證書內容結束×××××××××××××××××

               // 記不記得咱們前面的約定？{} 表示RSA加密後的內容，[ | ]表示用什麼密鑰和算法進行加密

 

咱們"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"進行通訊了。

★這個部分很是重要，必定要理解，您能夠從新回顧一下以前的兩章「一、基礎知識」和「 二、一個加密通訊過程的演化」，而後再來理解這部分的內容。後面在Https的配置演示中，我還會再舉例子說明證書的構成和原理。若是您把這節的內容看了幾遍尚未搞懂證書的工做原理，您能夠留言指出我沒有說清楚的內容，我好方便進行修正。

 

3.3 證書的發佈機構

前面已經初步介紹了一下證書發佈機構，這裏再深刻討論一下。

其實全部的公司均可以發佈證書，咱們本身也能夠去註冊一家公司來專門給別人發佈證書。可是很明顯，咱們本身的專門發佈證書的公司是不會被那些國際上的權威機構承認的，人家怎麼知道你是否是個狗屁皮包公司？所以微軟在它的操做系統中，並不會信任咱們這個證書發佈機構，當應用程序在檢查證書的合法信的時候，一看證書的發佈機構並非操做系統所信任的發佈機構，就會拋出錯誤信息。也就是說windows操做系統中不會預先安裝好咱們這個證書發佈機構的證書，不信任咱們這個發佈機構。

  

不受信任的證書發佈機構的危害

爲何一個證書發佈機構受不受信任這麼重要？咱們舉個例子。假設咱們開了一個狗屁公司來爲別人發佈證書，而且我和微軟有一腿，微軟在他們的操做系統中把我設置爲了受信任的證書發佈機構。如今若是有個小公司叫Wicrosoft 花了10塊錢讓我爲他們公司申請了一個證書，而且公司慢慢壯大，證書的應用範圍也愈來愈廣。而後有個奸商的公司JS Company想冒充Wicrosoft，因而給了我￥10000，讓我爲他們頒佈一個證書，可是證書的名字(Subject)要寫Wicrosoft，假如我爲了這￥10000，真的把證書給了他們，那麼他們之後就可使用這個證書來冒充Wicrosoft了。

若是是一個優秀的證書發佈機構，好比你要向他申請一個名字叫Wicrosoft的證書，它會讓你提供不少資料證實你確實能夠表明Wicrosoft這個公司，也就是說他回去覈實你的身份。證書發佈機構是要爲他發佈出的證書負法律責任的。

  

到這裏，你可能會想，TMD，那咱們本身就不能發佈證書嗎？就必定要花錢去申請？固然不是，咱們本身也能夠成立證書發佈機構，可是須要經過一些安全認證等等，只是有點麻煩。另外，若是數字證書只是要在公司內部使用，公司能夠本身給本身生成一個證書，在公司的全部機器上把這個證書設置爲操做系統信任的證書發佈機構的證書(這句話仔細看清楚，有點繞口)，這樣之後公司發佈的證書在公司內部的全部機器上就能夠經過驗證了(在發佈證書時，把這些證書的Issuer(發佈機構)設置爲咱們本身的證書發佈機構的證書的Subject(主題)就能夠了)。可是這隻限於內部應用，由於只有咱們公司本身的機器上設置了信任咱們本身這個所謂的證書發佈機構，而其它機器上並無事先信任咱們這個證書發佈機構，因此在其它機器上，咱們發佈的證書就沒法經過安全驗證。

 

4. 在windows中對數字證書進行管理

4.1 查看、刪除、安裝 數字證書

咱們在上一章中說到了，咱們的操做系統中會預先安裝好一些證書發佈機構的證書，咱們看下在windows中如何找到這些證書，步驟以下：

1)開始菜單->運行，輸入mmc，回車

2)在打開的窗口中選擇 File-> Add/Remove Snap-in…

3)而後在彈出的對話框的 Standalone Tab頁裏面點擊 Add… 按鈕

4)在彈出的對對話框中選擇 certificates 後點擊 Add 按鈕

具體的步驟以下圖所示：

 

上面的步驟結束後，會又彈出一個對話框，裏面有三個單選按鈕以下：

• My user account
• Service account
• Computer account

能夠選擇第一或者第三個選項，用來查看當前用戶的證書或整個計算裏面安裝的證書。咱們這裏就默認選擇第一個，平時通常安裝證書的時候都會給全部用戶安裝，因此選擇第一個和第三個選項看到的證書會差很少。咱們在左邊的導航樹中選中受信任的證書發佈機構(Trusted Root Certificate Authorities)，而後點擊下面的證書(Certificates)，在右邊的區域中就能夠看到全部的受信任的證書發佈機構的證書。

注意上面的圖片中，右邊咱們選中的這個證書發佈機構"SecureTrust CA"，咱們前面在第3章3.2節中舉例子的時候，就是去向這個證書發佈機構申請的證書，因爲咱們申請的證書是這個機構發佈的，因此應用程序在檢查咱們的證書的發佈機構時(會檢查咱們證書的簽名，確認是該機構發佈的證書)，就會發現是能夠信任的證書發佈機構，從而就會相信咱們證書的真實性。

刪除數字證書很簡單，直接在右邊的列表中右鍵而後刪除就能夠了。

數字證書的安裝也比較簡單，直接雙擊數字證書文件，會打開數字證書，對話框下面會有一個Install Certificate按鈕，點擊後就能夠根據嚮導進行安裝，以下圖所示：

這個證書是我本身生成的測試證書，在證書的導入嚮導裏面，它會讓你選擇導入到什麼位置，若是是一個咱們本身信任的證書發佈機構本身的證書，只要導入到Certificate Authorities就能夠了。Trusted Root Certificate Authorities, Intermediate Certification Authorities, Third-Party Root Certification Authorities 都是能夠的，他們只是對證書的發佈機構作了一個分類，還有一些其它的證書類型，例如Personal(我的證書)等等，具體就不介紹了。安裝的時候通常來講能夠用默認的選擇項一直"下一步"到底。

 

4.2 如何本身建立證書

每一個證書發佈機構都有本身的用來建立證書的工具，固然，具體他們怎麼去建立一個證書的我也不太清楚。 微軟爲咱們提供了一個用來建立證書的工具makecert.exe，在安裝Visual Studio的時候會安裝上。若是沒有安裝也無所謂，能夠上網去下一個，搜索makecert就能夠了。若是對我放心的話，能夠直接從個人博客下載，這是連接。

向一些正規的證書發佈機構申請證書通常是要收費的(由於別人要花時間檢查你的身份，確認有沒有同名的證書等等)，這裏咱們看下如何本身建立一個證書，爲後面在IIS中配置Https作準備。

咱們用到的是makecert這個工具，微軟有很詳細的使用幫助，我這裏只作一個簡單的解釋，詳細的各類參數和使用方法請查看MSDN的makecert的幫助。可是裏面有些參數說得不夠清楚，並且還有遺漏的，能夠參看我後面的解釋做爲一個補充。

 

先看下makecert最簡單的使用方式：

makecert.exe test.cer

上面的命令會在makecert.exe所在的目錄生成一個證書文件test.cer的數字證書文件。能夠雙擊證書打開，看看證書的內容以下：

證書的發佈機構是"Root Agency"，證書的主題(證書發佈給誰)是"Joe’s-Software-Emporium"，由於咱們沒有指定把證書發佈給誰，makecert本身給咱們隨便生成了一個公司的名字。另外還指定了公鑰、簽名算法(用來解密簽名)、指紋和指紋算法等。

注意，由於這個證書是由微軟的工具生成的，嚴格來講它沒什麼發佈機構，因此微軟虛擬了一個叫作"Root Agency"的發佈機構，默認狀況下，windows裏面安裝了這個所謂的證書發佈機構的證書，可是這證書默認狀況下不是受信任的，緣由很簡單，這樣作你們均可以用makecert來製做合法的數字證書了。若是咱們本身硬是要，也能夠把它設置爲受信任的。

 

下面咱們看下其它的參數，好比咱們要給網站 www.jefferysun.com 生成一個證書MyCA.cer，假設咱們把makecert.exe放在C：盤下，命令行以下：

makecert -r -pe -n "CN=10.30.146.206" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

C:/> makecert.exe –pe -r  –n  "CN=www.jefferysun.com" -ss my -sr LocalMachine -a sha1 -len 2048  MyCA.cer

解釋一下makecert的經常使用參數的意思：

• -n 指定主題的名字，這個是有固定的格式的， CN=主題名字 ，CN應該是Certificate Name的縮寫。我這裏的主題的名字就是咱們的IIS所在機器的IP。這裏能夠指定一些主題的其它附加信息，例如 O= *** 表示組織信息等等。
• -r 建立自簽署證書，意思就是說在生成證書時，將證書的發佈機構設置爲本身。
• -pe 將所生成的私鑰標記爲可導出。注意，服務器發送證書給客戶端的時候，客戶端只能從證書裏面獲取公鑰，私鑰是沒法獲取的。若是咱們指定了這個參數，證書在安裝在機器上後，咱們還能夠從證書中導出私鑰，默認狀況下是不能導出私鑰的。正規的途徑發佈的證書，是不可能讓你導出私鑰的。
• -b –e 證書的有效期
• -ss 證書的存儲名稱，就是windows證書存儲區的目錄名，若是不存在在的話就建立一個。
• -sr 證書的存儲位置，只有currentuser（默認值）或 localmachine兩個值。
• -sv 指定保存私鑰的文件，文件裏面除了包含私鑰外，其實也包含了證書。這個文件是須要保密的，這個文件在服務端配置時是須要用到的。
• 這個CN=10.30.146.206要與本身的服務器相對應，要否則在配置HTTPS的時候會出現錯誤
• -a 指定簽名算法，必須是md5或rsa1。(還記得簽名算法的做用不？能夠看一下3章的第1節中關於簽名算法的介紹)
• -in 指定證書發佈機構的名稱
• -len 這個參數在中文的幫助文檔中好像沒有提到，可是這個其實很重要，用於指定公鑰的位數，越大越安全，默認值是1024，推薦2048。我試了下，這個不爲1024的倍數也是能夠的。

生成證書後能夠進行安裝，安裝過程能夠參看4.1節