數字證書詳解.doc

《數字證書詳解.doc》由會員分享，可在線閱讀，更多相關《數字證書詳解.doc（27頁珍藏版）》請在裝配圖網上搜索。

數字證書 一. 什么是數字證書？ 數字證書就是網絡通訊中標志通訊各方身份信息的一系列數據，其作用類似于現實生活中的身份證。它是由一個權威機構發(fā)行的，人們可以在互聯(lián)網上用它來識別對方的身份。 最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。一般情況下證書中還包括密鑰的有效時間，發(fā)證機關(證書授權中心)的名稱，該證書的序列號等信息，證書的格式遵循ITUT X.509國際標準。 一個標準的X.509數字證書包含以下一些內容： 證書的版本信息； 證書的序列號，每個證書都有一個唯一的證書序列號； 證書所使用的簽名算法； 證書的發(fā)行機構名稱，命名規(guī)則一般采用X.500格式； 證書的有效期，現在通用的證書一般采用UTC時間格式，它的計時范圍為1950-2049； 證書所有人的名稱，命名規(guī)則一般采用X.500格式； 證書所有人的公開密鑰； 證書發(fā)行者對證書的簽名。 使用數字證書，通過運用對稱和非對稱密碼體制等密碼技術建立起一套嚴密的身份認證系統(tǒng)，從而保證：信息除發(fā)送方和接收方外不被其它人竊取；信息在傳輸過程中不被篡改；發(fā)送方能夠通過數字證書來確認接收方的身份；發(fā)送方對于自己的信息不能抵賴。 二. 為什么要使用數字證書？ 基于Internet網的電子商務系統(tǒng)技術使在網上購物的顧客能夠極其方便輕松地獲 得商家和企業(yè)的信息，但同時也增加了對某些敏感或有價值的數據被濫用的風險。買 方和賣方都必須對于在因特網上進行的一切金融交易運作都是真實可靠的，并且要使 顧客、商家和企業(yè)等交易各方都具有絕對的信心，因而因特網(Internet)電子商務 系統(tǒng)必須保證具有十分可靠的安全保密技術，也就是說，必須保證網絡安全的四大要 素，即信息傳輸的保密性、數據交換的完整性、發(fā)送信息的不可否認性、交易者身份的確定性。 　　1、信息的保密性 　　交易中的商務信息均有保密的要求。如信用卡賬號和用戶名被人知悉，就可能 被盜用，訂貨和付款的信息被競爭對手獲悉，就可能喪失商機。因此在電子商務的信息傳播中一般均有加密的要求。 　　2、交易者身份的確定性 　　網上交易的雙方很可能素昧平生，相隔千里。要使交易成功首先要能確認對方的 身份，對商家要考慮客戶端不能是騙子，而客戶也會擔心網上的商店不是一個玩弄欺 詐的黑店。因此能方便而可靠地確認對方身份是交易的前提。對于為顧客或用戶開展 服務的銀行、信用卡公司和銷售商店，為了做到安全、保密、可靠地開展服務活動， 都要進行身份認證的工作。對有關的銷售商店來說，他們對顧客所用的信用卡的號碼 是不知道的，商店只能把信用卡的確認工作完全交給銀行來完成。銀行和信用卡公司 可以采用各種保密與識別方法，確認顧客的身份是否合法，同時還要防止發(fā)生拒付款 問題以及確認訂貨和訂貨收據信息等。 　　3、不可否認性 　　由于商情的千變萬化，交易一旦達成是不能被否認的。否則必然會損害一方的利 益。例如訂購黃金，訂貨時金價較低，但收到訂單后，金價上漲了，如收單方能否認 受到訂單的實際時間，甚至否認收到訂單的事實，則訂貨方就會蒙受損失。因此電子 交易通信過程的各個環(huán)節(jié)都必須是不可否認的。 　　4、不可修改性 　　交易的文件是不可被修改的，如上例所舉的訂購黃金。供貨單位在收到訂單后， 發(fā)現金價大幅上漲了，如其能改動文件內容，將訂購數1噸改為1克，則可大幅受益， 那么訂貨單位可能就會因此而蒙受損失。因此電子交易文件也要能做到不可修改，以 保障交易的嚴肅和公正。 　　人們在感嘆電子商務的巨大潛力的同時，不得不冷靜地思考，在人與人互不見面 的計算機互聯(lián)網上進行交易和作業(yè)時，怎么才能保證交易的公正性和安全性，保證交易雙方身份的真實性。國際上已經有比較成熟的安全解決方案， 那就是建立安全證書體系結構。數字安全證書提供了一種在網上驗證身份的方式。安全證書體制主要采 用了公開密鑰體制，其它還包括對稱密鑰加密、數字簽名、數字信封等技術。 　　我們可以使用數字證書，通過運用對稱和非對稱密碼體制等密碼技術建立起一套嚴密的身份認證系統(tǒng)，從而保證：信息除發(fā)送方和接收方外不被其它人竊取；信息在傳輸過程中不被篡改；發(fā)送方能夠通過數字證書來確認接收方的身份；發(fā)送方對于自己的信息不能抵賴。 三.數字證書原理？ 1.密碼學 在密碼學中，有一個五元組：{明文、密文、密鑰、加密算法、解密算法}，對應的加密方案稱為密碼體制（或密碼）。 　　明文：是作為加密輸入的原始信息，即消息的原始形式所有可能明文的有限集稱為明文空間。 　　密文：是明文經加密變換后的結果，即消息被加密處理后的形式，所有可能密文的有限集稱為密文空間。 　　密鑰：是參與密碼變換的參數，一切可能的密鑰構成的有限集稱為密鑰空間。 　　加密算法：是將明文變換為密文的變換函數，相應的變換過程稱為加密，即編碼的過程。 　　解密算法：是將密文恢復為明文的變換函數，相應的變換過程稱為解密，即解碼的過程。 現代密碼學算法： 對稱算法： 加密和解密使用同一密鑰 主要算法包括：DES、3DES、RC2、RC4 加/解密速度快，但密鑰分發(fā)問題嚴重 非對稱算法： 不需要首先共享秘密 兩個密鑰同時產生 ：一把密鑰（公鑰）是公開的，任何人都可 以得到。另一把密鑰（私人密鑰）只有密鑰的擁有者知道。 用其中一把密鑰（公鑰或者是私鑰）加密的信息，只能用另一把 打開。 RSA算法，ECC（橢圓曲線）算法 由已知的公鑰幾乎不可能推導出私鑰 強度依賴于密鑰的長度 很慢-不適合加密大數據 公鑰可以廣泛地、開放地分發(fā) 用于加密，簽名/校驗，密鑰交換 主要算法包括：RSA，ECC，Diffie-Hellman， DSA 數字摘要： 把可變輸入長度串轉換成固定長度輸出串的一種函數。稱輸出串 為輸入串的指紋，或者數字摘要； 不同明文的摘要相同的概要是非常非常小的；而同樣明文其摘要必定一致； 明文的長度不固定，摘要的長度固定。 沒有密鑰 不可回溯 典型算法：MD5, SHA-1 用于完整性檢測，產生數字簽名 最好的解決方案： 使用對稱算法加密大的數據 – 每次加密先產生新的隨機密鑰 使用非對稱算法交換隨機產生的密鑰 用非對稱算法做數字簽名（對散列值即摘要做數字簽名） 四條基本規(guī)則 – 先簽名，然后加密 – 加密之前先壓縮 – 用你自己的私鑰做簽名 – 用接收者的公鑰做加密 加密： 解密： 怎樣解決4個通訊安全需求？ – 私密性　加密 – 完整性　？ – 不可否認性　？ – 身份認證 ？ 問題：如何解決以上三個問題？ 2.數字簽名 數字簽名采用公鑰體制（PKI），即利用一對互相匹配的密鑰進行加密、解密。每個用戶自己設定一把特定的僅為本人所知的私有密鑰(私鑰)，用它進行解密和簽名；同時設定一把公共密鑰(公鑰)并由本人公開，為一組用戶所共享，用于加密和驗證簽名。當發(fā)送一份保密文件時，發(fā)送方使用接收方的公鑰對數據加密，而接收方則使用自己的私鑰解密，這樣信息就可以安全無誤地到達目的地了。通過這種手段保證加密過程是一個不可逆過程，即只有用私有密鑰才能解密。在公開密鑰密碼體制中，常用的一種是RSA體制。其數學原理是將一個大數分解成兩個質數的乘積，加密和解密用的是兩個不同的密鑰。即使已知明文、密文和加密密鑰(公開密鑰)，想要推導出解密密鑰(私密密鑰)，在計算上是不可能的。按現在的計算機技術水平，要破解目前采用的1024位RSA密鑰，需要上千年的計算時間。公開密鑰技術解決了密鑰發(fā)布的管理問題，商戶可以公開其公開密鑰，而保留其私有密鑰。購物者可以用人人皆知的公開密鑰對發(fā)送的信息進行加密，安全地傳送給商戶，然后由商戶用自己的私有密鑰進行解密。 　　用戶也可以采用自己的私鑰對信息加以處理，由于密鑰僅為本人所有，這樣就產生了別人無法生成的文件，也就形成了數字簽名。采用數字簽名，能夠確認以下兩點： 　　(1)保證信息是由簽名者自己簽名發(fā)送的，簽名者不能否認或難以否認； (2)保證信息自簽發(fā)后到收到為止未曾作過任何修改，簽發(fā)的文件是真實文件。 數字簽名具體做法是： 　　(1)將報文按雙方約定的HASH算法計算得到一個固定位數的報文摘要。在數學上保證：只要改動報文中任何一位，重新計算出的報文摘要值就會與原先的值不相符。這樣就保證了報文的不可更改性。 　　(2)將該報文摘要值用發(fā)送者的私人密鑰加密，然后連同原報文一起發(fā)送給接收者，而產生的報文即稱數字簽名。這樣就保證了簽發(fā)者不可否認性。 (3)接收方收到數字簽名后，用同樣的HASH算法對報文計算摘要值，然后與用發(fā)送者的公開密鑰進行解密解開的報文摘要值相比較。如相等則說明報文確實來自所稱的發(fā)送者。 四. 數字證書是如何生成的？ 數字證書是數字證書在一個身份和該身份的持有者所擁有的公/私鑰對之間建立了一種聯(lián)系，由認證中心（CA）或者認證中心的下級認證中心頒發(fā)的。根證書是認證中心與用戶建立信任關系的基礎。在用戶使用數字證書之前必須首先下載和安裝。 認證中心是一家能向用戶簽發(fā)數字證書以確認用戶身份的管理機構。為了防止數字憑證的偽造，認證中心的公共密鑰必須是可靠的，認證中心必須公布其公共密鑰或由更高級別的認證中心提供一個電子憑證來證明其公共密鑰的有效性，后一種方法導致了多級別認證中心的出現。 數字證書頒發(fā)過程如下：用戶產生了自己的密鑰對，并將公共密鑰及部分個人身份信息(稱作P10請求)傳送給一家認證中心。認證中心在核實身份后，將執(zhí)行一些必要的步驟，以確信請求確實由用戶發(fā)送而來，然后，認證中心將發(fā)給用戶一個數字證書，該證書內附了用戶和他的密鑰等信息，同時還附有對認證中心公共密鑰加以確認的數字證書。當用戶想證明其公開密鑰的合法性時，就可以提供這一數字證書。 證書的產生：認證中心把用戶證書的基本信息做哈希算法，然后用自己的私鑰對哈希值進行加密。 五.數字證書是如何分發(fā)的？ CA將證書分發(fā)給用戶的途徑有多種。第一種途徑是帶外分發(fā)(Out-of-band Distribution)，即離線方式。例如，密鑰對是由軟件運營商代替客戶生成，證書也是由運營商代替客戶從CA下載，然后把私鑰和下載的證書一起儲存在軟盤里，再交給用戶的。這樣做的好處是免去了用戶上網下載證書的麻煩。第二種途徑是帶內分發(fā)(In-band distribution)，即用戶從網上下載數字證書到自己的電腦中。下載時，用戶要向CA出示“參考號”和“授權碼”，以向CA證明自己的身份。這樣做成本較低，但對使用計算機不太熟悉的用戶來說，可能在下載時會碰到一些麻煩。除了以上兩種方式外，CA還把證書集中放置在公共的數據庫中公布，用戶可以隨用隨查詢隨調用。 六.數字證書是如何存儲的？ 　　數字證書和私鑰儲存的介質有多種，大致分為硬證書和軟證書?？梢源鎯υ谟嬎銠C硬盤、軟盤、智能卡或USB key里。 　　1、關于私鑰的唯一性 　　嚴格地講，私鑰既然是世上唯一且只由主體本身持有，它就必須由主體的計算機程序來生成。因為如果在別處生成將會有被拷貝的機會。然而在實際應用上并非如此，出于某些特殊需要(例如，如果只有一份私鑰，單位的加密文件就會因為離職員工帶走 私鑰而無法解密。)加密用的公/私鑰對會要求在可信的第三方儲存其備份。這樣，加密用的私鑰可能并不唯一。然而簽名用的私鑰則必須保持唯一，否則就無法保證被簽名信息的不可否認性。 　　在生成用戶的密鑰對時，用于加密的公/私鑰對可以由CA、RA產生，也可以在用戶終端的機器上用專用的程序(如瀏覽器程序或認證軟件)來產生。用于數字簽名的密鑰對原則上只能由用戶終端的程序自行產生，才能保證私鑰信息的私密性以及通信信息的不可否認性。 　　有人可能會產生疑問：有的加密和簽名的密鑰對都是由軟件運營商代替客戶生成的，這是否破壞了上述的私鑰唯一性原則呢？答案是否定的。這時候，私鑰的唯一性要依靠法律合同的保證以及操作過程中相應制度的約束，使得不可否認性得到支持。出于這種機制，我們仍然可以認為，用戶的簽名私鑰是唯一的。 　　2、證書，私鑰，到底保護哪一個？ 　　我們常常聽到有人說：“保管好你的軟盤，保管好你的KEY，不要讓別人盜用你的證書?！庇行┙炭茣弦策@樣講。應該說，這句話是有毛病的。數字證書可以在網上公開，并不怕別人盜用和篡改。因為證書的盜用者在沒有掌握相應的私鑰的情況下，盜用別人的證書既不能完成加密通信，又不能實現數字簽名，沒有任何實際用處。而且，由于有CA對證書內容進行了數字簽名，在網上公開的證書也不怕黑客篡改。我們說，更該得到保護的是儲存在介質中的私鑰。如果黑客同時盜走了證書和私鑰，危險就會降臨。 　　3、為什么說USB key安全性好？ 　　不同的存儲介質，安全性是不同的。如果證書和私鑰儲存在計算機的硬盤里，計算機一旦受到黑客攻擊，(例如被埋置了木馬程序)證書和私鑰就可能被盜用。 　　使用軟盤或存儲型IC卡來保存證書和私鑰，安全性要比硬盤好一些，因為這兩種介質僅僅在使用時才與電腦相連，用完后即被拔下，證書和私鑰被竊取的可能性有所降低。但是黑客還是有機會，由于軟盤和存儲型IC卡不具備計算能力，在進行加密運算時，用戶的私鑰必須被調出軟盤或IC卡進入外部的電腦，在這個過程中就會造成一定的安全隱患。 　　使用智能卡(含CPU的IC卡)儲存數字證書和私鑰是更為安全的方式。為什么這樣說呢？原來智能卡具有一定的計算機的功能，芯片中的CPU就是一臺小小的計算機。 　　產生公私密鑰對的程序(指令集)是智能卡生產者燒制在芯片中的ROM中的，密碼算法程序也是燒制在ROM中。公私密鑰對在智能卡中生成后，公鑰可以導出到卡外，而私鑰則存儲于芯片中的密鑰區(qū)，不允許外部訪問。 　　智能卡中密鑰文件存儲在E2PROM之中。對密鑰文件的讀寫和修改都必須由卡內的程序調用。從卡接口的外面，沒有任何一條命令能夠對密鑰區(qū)的內容進行讀出、修改、更新和刪除、。除非設計和編寫卡操作系統(tǒng)(COS)的人自己在COS上留了后門，只有他才知道如何從外部調出密鑰區(qū)的內容。但我們可以排除黑客與COS設計者相勾結的這種幾率極小的可能性。 　　在加密和簽名的運算過程中，外部計算機中的應用軟件使用智能卡API調用的方式，輸入參數、數據和命令，啟動智能卡內部的數字簽名運算、密碼運算等，并獲得返回結果。由于智能卡內部的CPU可以完成這些操作，全過程中私鑰可以不出智能卡介質，黑客的攻擊程序沒有機會去截獲私鑰，因此這就比證書和私鑰放在軟盤或硬盤上要安全得多。 從物理上講，對智能卡芯片中的內容作整體拷貝也是幾乎不可能的。雖然聽說有人能夠從智能卡芯片在操作過程中發(fā)生的微弱的電磁場變化，或者I/O口上反映出的微弱的電平變化中分析出芯片中的代碼。但現在國際上對智能卡生產商的技術要求很高，要求上述的指標要低到不能夠被測出來。國際上生產智能卡的公司都采用了種種安全措施，確保智能卡內部的數據不能用物理方法從外部拷貝。 為了防止USBkey不慎丟失而可能被他人盜用，不少證書應用系統(tǒng)在使用過程中還設置了口令認證機制。如口令輸入得不對，即使掌握了USB key，也不能登錄進入應用系統(tǒng)。這種雙因素認證機制可以使USB key更加安全可靠，值得提倡。 USB Key和智能卡除了I/O物理接口不一樣以外，內部結構和技術是完全一樣的，其安全性也一樣。只不過智能卡需要通過讀卡器接到電腦的串行接口上，而USB Key通過電腦的通用串行總線(USB)接口直接與電腦相接。另外，USB接口的通信速度要遠遠高于串行接口的通信速度。現在出品的電腦已經把USB接口作為標準配置，而使用智能卡則需要加配讀卡器。出于以上原因，各家CA都把USB Key作為首選的證書和私鑰存儲介質而加以推廣。 4、第二代USB Key 第二代USBKey帶有液晶顯示屏和安全按鍵，按上下鍵可在顯示屏上查看轉賬信息（包括收款賬號、收款人姓名和交易金額等），如發(fā)現轉賬內容不正確，按清除鍵可以清楚所有輸入的內容，再重新輸入。當輸入無誤，需要使用USBKey進行簽名時，在有效時限內按下物理按鍵后簽名才能成功，否則簽名操作失敗，即使USBKey的密碼被人截取，木馬程序發(fā)起一個非法的交易申請，由于無法進行物理上的按鍵操作致使整個交易不能進行下去?？杀ＷC交易的內容不會被黑客程序非法修改，有效防止交易偽造和交易劫持的攻擊。 　　5、仍需注意的問題 　　這里需要指出的是，有些號稱智能卡的產品實際上只是不含CPU的存儲型IC卡，它僅僅具有存儲功能。上文已經介紹過，存儲型IC卡的安全性與軟盤相仿，對于這兩種不同類型的IC卡，用戶需要甄別清楚。 第二個問題是，盡管智能卡在設計和生產過程中，對安全機制給以了充分的考慮和保證，然而，由于人為因素，也可能帶來安全隱患。例如智能卡上提供一個閃存(flash)隨機存儲區(qū)域，是供寫入一般用戶數據或增加卡片功能的程序之用的。敏感的數據和程序不允許寫在閃存區(qū)，必須寫在安全存儲區(qū)。制作智能卡時，安全區(qū)要通過硬件方法做掩模處理。硬件的掩模處理費工費時成本高，一般需要時間較長。有些卡商為了降低成本縮短工期迎合客戶要求，將應該放在安全區(qū)中的敏感數據和程序放在閃存區(qū)中，閃存區(qū)里的內容是可以從卡片外部進行讀寫的，這就造成了可能被黑客侵入的安全隱患。這就要求我們對合作的IC卡廠商的工藝流程也要仔細審查。 七.如何驗證數字證書？ 以Alice驗證Bob證書為例： 校驗Bob的證書的合法性 （1）Alice獲得Bob的證書和簽發(fā)Bob證書的CA的證書 （2）用CA的公鑰解密Bob的證書摘要 （3）計算Bob的證書的摘要 （4）比較這兩個摘要 （5）校驗Bob的證書證書有效期 （6）校驗簽發(fā)者簽名（證書鏈） （7）檢查證書作廢列表（CRL,OCSP） 八.CRL和OCSP是什么？ 證書的有效性取決于兩個方面因素： 第一個因素是證書有效期：證書的有效期在證書被頒發(fā)之日就已經確定了，例如CFCA(中國金融認證中心)規(guī)定個人證書的有效期是一年（可擴展），企業(yè)證書的有效期是三年。證書的有效期（Validity Period）作為一項內容被寫進了數字證書之中，它用兩個日期——證書開始生效的日期和證書失效的日期來表示。顯然，已經過了有效期的證書不能通過驗證。 　　證書有效期的設定是出于安全的考慮，當一張證書有效期將結束時，如果想繼續(xù)使用就需要更新，證書更新時將產生新的公私密鑰對，密鑰定期更新對于證書的安全性是有好處的。 第二個因素是證書注銷：雖然證書有效期沒有過，但是如果發(fā)生了特殊情況，例如用戶發(fā)現證書遺失或私鑰失密，用戶會向CA/RA提出注銷證書的申請，CA/RA經過審核后將實施證書注銷。那么，被注銷的證書也不能通過驗證。 　　第一種情況比較簡單，證書的有效期就寫在了證書之中，安全認證應用軟件只要調出證書的內容，判斷一下就知道這張數字證書當前是否還在有效期內。 　　第二種情況則比較復雜，證書一旦發(fā)出，是不可能收回的。怎么辦呢？只能申請注銷。所謂注銷，就是要求當初頒發(fā)這張證書的單位（CA）出一張告示，宣布某張證書已經被注銷作廢，警告有關的交易者注意，不要再使用與這張證書綁定的公鑰。在PKI安全認證體系中，這種“告示”稱為證書注銷列表（或證書撤銷清單、證書注銷清單、證書廢止列表等），英文原文是Certificate Revocation List，縮寫為CRL。 　　對于第二種情況，安全認證應用軟件在驗證證書的有效性時就需要去訪問證書注銷列表（CRL）。這個列表相當于“黑名單”，一旦發(fā)現通信對方的證書在這張列表中，就不能通過驗證。 　　證書注銷機制可以防止證書遺失或發(fā)現私鑰失密后，不法分子冒用用戶證書、私鑰實行欺詐交易所帶來的損失。這和信用卡注銷、有效證件注銷的機制十分類似。 　注銷證書的其他原因還包括：銀行方面認為證書用戶信用喪失、用戶身份姓名發(fā)生改變、用戶從他所屬單位離職、崗位和職權發(fā)生變更等情況。 CRL的內容 根據X.509標準，CRL的內容和數據結構定義如所示： 版本 簽名算法 簽發(fā)者 更新時間 下一次更新時間 廢止的證書列表 用戶證書序列號 廢止時間 CRL入口擴展 CRL的內容包括CRL的版本號、計算本CRL的數字簽名所用的算法的標識符（如加密算法RSA、數字摘要算法MD5等算法的標識符）、頒發(fā)CRL的CA的可識別名（DN）、CRL的發(fā)布/更新時間、被注銷證書的列表（僅列出被注銷證書的唯一序列號）以及擴展項。 　　 擴展項中的內容有： （1）理由代碼——指出該證書被注銷的理由，如：密鑰損壞、CA損壞、關系變動、操作終止等； （2）證書頒發(fā)者——列出該證書頒發(fā)者的名字； （3）控制指示代碼——用于證書的臨時凍結； （4）失效日期——列出該證書不再有效的日期。 為了保證CRL的真實性和完整性，CRL數據的后面附有頒發(fā)CRL的CA對CRL的數字簽名。 CRL的發(fā)布 CRL的數據形成后，要把它公布在網上，放在哪里呢？首先，在CFCA的證書系統(tǒng)中，設置了一個LDAP服務器，它與互聯(lián)網相連接，有特定的IP地址，CRL的數據就放在這里供用戶查詢。LDAP的全稱是Lightweight Directory Access Protocol，即輕型目錄訪問協(xié)議。LDAP的信息模型是建立在“條目”（entries）的基礎上，目錄的基本信息單元是條目。目錄條目呈現為一個層次狀的樹形結構。CRL的數據以條目的形式存放在LDAP服務器中。根據LDAP目錄服務所具有的特性，用戶可以在網上方便快捷地對CRL進行查詢。 　　然而，CRL的數據集中存放在CA的服務器中可能帶來另一個問題，就是當用戶數量龐大，而且到了交易集中發(fā)生的高峰時期時，對LDAP服務器的并發(fā)訪問可能造成網絡和服務器的擁塞，致使交易效率急劇下降甚至超時。 　　解決這個問題有以下兩個辦法： 　　第一個辦法是使用分段的CRL，就是把龐大的CRL分成很多可控的片段，并允許一個CA的證書注銷信息通過多個CRL發(fā)布出來。在證書的擴展項中，有一個子項稱為CRL分布點，它指出CRL分布點的分布位置，用戶可以根據這個參數來訪問相應的CRL。 　　第二個辦法是建立遠程的鏡像LDAP服務器。這些鏡像服務器分布在其他城市或一些大客戶的所在地。CA的LDAP主服務器負責對這些鏡像服務器進行定期數據更新，以便使鏡像服務器的數據內容和主服務器保持一致。設置鏡像服務器的目的有兩個：一是加快當地用戶訪問目錄服務器的響應時間。二是通過設置鏡像服務器可以對大量的并發(fā)訪問進行分流，減輕高峰時間LDAP主服務器的負擔。此外，作為一種備份機制，鏡像服務器還可以在主服務器故障期間起到備份作用，提供不間斷服務，這就提高了整個系統(tǒng)的可用率。 CRL的更新 　　從安全的角度上講，CRL最好是進行實時更新，即一旦發(fā)生證書注銷事件就立即更新，以杜絕欺詐案件的得逞。但這種實時更新的代價非常高，要占用大量的網絡資源和服務器資源，反過來又會影響到網上交易的進行。因此，業(yè)內普遍的做法是定期更新，如CFCA的管理策略是對主服務器的CRL和所有遠程鏡像CRL每天更新一次。 　　然而，當CRL數據總量非常龐大時，即使是每天更新一次也會給系統(tǒng)帶來過大的負擔。因此，又出現了增量CRL的概念。增量CRL的想法就是不需要每注銷一張證書就產生一個完整的、越來越大的CRL，它只是產生一個與注銷該證書相關的增加信息。 　　根據定義，增量CRL是以已經頒發(fā)的注銷信息為基礎的，這個已經頒發(fā)的注銷信息稱為基本CRL，增量CRL中含有的是基本CRL中不含有的信息。引入增量CRL概念的好處是體積很小的增量CRL可以比基本CRL的更新頻率高得多。例如，龐大的基本CRL的更新周期如果是一周的話，增量CRL的更新周期可以定為8小時，甚至更短。顯然，這樣的安全策略具有較高的安全性，而且不會給系統(tǒng)造成大的負擔。 在線查詢機制——OCSP 我們在上文已經提到，CRL方法存在一些缺點，其一就是CRL不可能實時更新，由于CA每隔一定時間才發(fā)布CRL，所以CRL不能及時地反應證書的狀態(tài)，在安全性上有一定局限；其二，即使定期更新CRL也有麻煩，當注銷證書的數量很大及用戶基礎很大時，CRL常常會越變越大。 每次CRL分發(fā)會大量消耗網絡帶寬和服務器處理能力。對于很多集群客戶來說（例如一家銀行和它的眾多客戶或者一家大企業(yè)和它的子公司、分銷店），為了提高證書有效性驗證效率，往往把CRL先下載到自己的服務器上，以減少對CRL的在線查詢。然而頻繁地下載CRL也是令用戶頭疼的問題。有時候，這種CRL處理方式還要求用戶配置客戶PC來處理來自多個證書機構的CRL。 　　于是，另一種證書有效性的管理和查詢方法，即在線查詢機制應運而生。它使用的協(xié)議稱為在線證書狀態(tài)協(xié)議，英文是OCSP（Online Certificate Status Protocol）。 　　在線證書狀態(tài)協(xié)議（OCSP）是IETF頒布的用于檢查數字證書在某一交易時間是否有效的標準，在RFC 2560中有描述。它為網上業(yè)務提供了一種檢驗數字證書有效性的途徑，比下載和處理證書注銷列表（CRL）的傳統(tǒng)方式更快、更方便和更具獨立性。OCSP實時在線地向用戶提供證書狀態(tài)，其結果是它比CRL處理快得多，并避免了令人頭痛的邏輯問題和處理開銷。 OCSP在線查詢機制的簡單過程如下（見插圖）： 用戶的客戶機形成查詢指定證書狀態(tài)請求，并將請求轉發(fā)到一個OCSP應答器(服務器)，應答器建立與CA證書庫的連接，并查詢CA證書庫而獲得該證書的狀態(tài)，應答器返回客戶機有關證書有效性信息。 　　 簡單地說，一個OCSP請求，由協(xié)議版本號、服務請求類型及一個或多個證書標識符等信息所組成；響應信息是由證書標識符、證書狀態(tài)——“有效”、“注銷”或“未知”三個中的一個、以及驗證相應時間等信息所組成。詳細信息見下表所示。 表：OCSP響應信息 用戶的客戶機形成查詢指定證書狀態(tài)請求，并將請求轉發(fā)到一個OCSP應答器(服務器)，應答器建立與CA證書庫的連接，并查詢CA證書庫而獲得該證書的狀態(tài)，應答器返回客戶機有關證書有效性信息。 　　簡單地說，一個OCSP請求，由協(xié)議版本號、服務請求類型及一個或多個證書標識符等信息所組成；響應信息是由證書標識符、證書狀態(tài)——“有效”、“注銷”或“未知”三個中的一個、以及驗證相應時間等信息所組成。詳細信息見下表所示。 響應信息必須經過數字簽名，以保證這個信息的真實性和完整性（未被篡改）。簽名密鑰屬于CA，即頒發(fā)這張證書的權威、可信的第三方機構，因此，在任何情況下，用戶都能夠信任這個信息。 　　OCSP在線查詢機制只能檢測證書的注銷狀態(tài)，沒有其他功能，例如不能檢查證書的有效期，也不返回用戶一個完全的證書。但是這種用法在某些應用場合下，對于驗證證書的有效性來說是快速有效的。 　　由于使用OCSP在線查詢必須保持用戶在線狀態(tài)，且用戶訪問的對象集中在CA的OCSP服務器上，這同樣會帶來高峰負載過重，交通擁塞效率下降的問題。 　　從以上的描述中我們可以看到，CRL和OCSP兩種機制所針對的目標和實現的功能是一樣的，只不過實現的方法途徑不一樣，兩者具有異曲同工之妙。用戶可根據自己的需求決定使用哪種方法，目前，CFCA對這兩種方法都提供服務。 九.常見的數字證書格式 1.在Security編程中，有幾種典型的密碼交換信息文件格式： 　　DER-encoded certificate： .cer, .crt 　　PEM-encoded message： .pem 　　PKCS#12 Personal Information Exchange： .pfx, .p12 　　PKCS#10 Certification Request： .p10 　　PKCS#7 cert request response： .p7r 　　PKCS#7 binary message： .p7b 　　.cer/.crt是用于存放證書，它是2進制形式存放的，不含私鑰。 　　.pem跟crt/cer的區(qū)別是它以Ascii來表示。 　　pfx/p12用于存放個人證書/私鑰，他通常包含保護密碼，2進制方式 　　p10是證書請求 　　p7r是CA對證書請求的回復，只用于導入 　　p7b以樹狀展示證書鏈(certificate chain)，同時也支持單個證書，不含私鑰。 2.數字證書文件格式（cer和pfx）的區(qū)別 　　作為文件形式存在的證書一般有這幾種格式： 　　1.帶有私鑰的證書 　　由Public Key Cryptography Standards #12，PKCS#12標準定義，包含了公鑰和私鑰的二進制格式的證書形式，以 　　pfx作為證書文件后綴名。 　　2.二進制編碼的證書 　　證書中沒有私鑰，DER 編碼二進制格式的證書文件，以cer作為證書文件后綴名。 　　3.Base64編碼的證書 　　證書中沒有私鑰，BASE64 編碼格式的證書文件，也是以cer作為證書文件后綴名?！∮啥x可以看出，只有pfx格式的數字證書是包含有私鑰的，cer格式的數字證書里面只有公鑰沒有私鑰。在pfx證書的導入過程中有一項是“標志此密鑰是可導出的。這將您在稍候備份或傳輸密鑰”。一般是不選中的，如果選中，別人就有機會備份你的密鑰了。如果是不選中，其實密鑰也導入了，只是不能再次被導出。這就保證了密鑰的安全。 　如果導入過程中沒有選中這一項，做證書備份時“導出私鑰”這一項是灰色的，不能選。只能導出cer格式的公鑰。 　　如果導入時選中該項，則在導出時“導出私鑰”這一項就是可選的。 　　如果要導出私鑰（pfx),是需要輸入密碼的，這個密碼就是對私鑰再次加密，這樣就保證了私鑰的安全，別人即使拿到了你的證書備份（pfx),不知道加密私鑰的密碼，也是無法導入證書的。相反，如果只是導入導出cer格式的證書，是不會提示你輸入密碼的。因為公鑰一般來說是對外公開的，不用加密 3.X.509定義了兩種證書：公鑰證書和屬性證書 　　 PKCS#7和PKCS#12使用的都是公鑰證書 　　 PKCS＃7的SignedData的一種退化形式可以分發(fā)公鑰證書和CRL 　　 一個SignedData可以包含多張公鑰證書 　　 PKCS＃12可以包含公鑰證書及其私鑰，也可包含整個證書鏈 十.數字證書命名 C（county） 國家 O（organization）頒發(fā)機構名稱 OU(Organizational Unit) 組織單位名稱 CN (common name) 持有者的名稱 例如：CN=zhangsan，OU=beijingICBCbank，O=ICBCbank 十一.證書工具使用 1.KeyTool工具 　　Java自帶的keytool工具是個密鑰和證書管理工具。它使用戶能夠管理自己的公鑰/私鑰對及相關證書，用于（通過數字簽名）自我認證（用戶向別的用戶/服務認證自己）或數據完整性以及認證服務。它還允許用戶儲存他們的通信對等者的公鑰（以證書形式）。keytool 將密鑰和證書儲存在一個所謂的密鑰倉庫（keystore）中。缺省的密鑰倉庫實現將密鑰倉庫實現為一個文件。它用口令來保護私鑰。 Java KeyStore的類型 　　JKS和JCEKS是Java密鑰庫(KeyStore)的兩種比較常見類型(我所知道的共有5種，JKS, JCEKS, PKCS12, BKS，UBER)。 　　JKS的Provider是SUN，在每個版本的JDK中都有，JCEKS的Provider是SUNJCE，1.4后我們都能夠直接使用它。 JCEKS在安全級別上要比JKS強，使用的Provider是JCEKS(推薦)，尤其在保護KeyStore中的私鑰上（使用TripleDes）。 　　PKCS#12是公鑰加密標準，它規(guī)定了可包含所有私鑰、公鑰和證書。其以二進制格式存儲，也稱為 PFX 文件，在 　　windows中可以直接導入到密鑰區(qū)，注意，PKCS#12的密鑰庫保護密碼同時也用于保護Key。 　　BKS 來自BouncyCastle Provider，它使用的也是TripleDES來保護密鑰庫中的Key，它能夠防止證書庫被不小心修改（Keystore的keyentry改掉1個 bit都會產生錯誤），BKS能夠跟JKS互操作，讀者可以用Keytool去TryTry。UBER比較特別，當密碼是通過命令行提供的時候，它只能跟keytool交互。整個keystore是通過PBE/SHA1/Twofish加密，因此keystore能夠防止被誤改、察看以及校驗。以前，Sun JDK(提供者為SUN)允許你在不提供密碼的情況下直接加載一個Keystore，類似cacerts，UBER不允許這種情況。 　　證書導入 　　Der/Cer證書導入： 　　要從某個文件中導入某個證書，使用keytool工具的-import命令： 　　keytool -import -file mycert.der -keystore mykeystore.jks 　　如果在 -keystore 選項中指定了一個并不存在的密鑰倉庫，則該密鑰倉庫將被創(chuàng)建。如果不指定 -keystore 選項，則缺省密鑰倉庫將是宿主目錄中名為 .keystore 的文件。如果該文件并不存在，則它將被創(chuàng)建。創(chuàng)建密鑰倉庫時會要求輸入訪問口令，以后需要使用此口令來訪問?？墒褂?list命令來查看密鑰倉庫里的內容： keytool -list -rfc -keystore mykeystore.jks P12格式證書導入： 　　keytool無法直接導入PKCS12文件。 　　第一種方法是使用IE將pfx證書導入，再導出為cert格式文件。使用上面介紹的方法將其導入到密鑰倉庫中。這樣的話倉庫里面只包含了證書信息，沒有私鑰內容。 　　第二種方法是將pfx文件導入到IE瀏覽器中，再導出為pfx文件。 　　新生成的pfx不能被導入到keystore中，報錯：keytool錯誤： java.lang.Exception： 所輸入的不是一個 　　X.509 認證。新生成的pfx文件可以被當作keystore使用。但會報個錯誤as unknown attr1.3.6.1.4.1.311.17.1, 　　查了下資料,說IE導出的就會這樣,使用Netscape就不會有這個錯誤. 　　第三種方法是將pfx文件當作一個keystore使用。但是通過微軟的證書管理控制臺生成的pfx文件不能直接使用。 　　keytool不認此格式，報keytool錯誤： java.io.IOException： failed to decrypt safe contents entry。需要 　　通過OpenSSL轉換一下： 　　1）openssl pkcs12 -in mycerts.pfx -out mycerts.pem 　　2）openssl pkcs12 -export -in mycerts.pem -out mykeystore.p12 　　通過keytool的-list命令可檢查下密鑰倉庫中的內容： 　　keytool -rfc -list -keystore mykeystore.p12 -storetype pkcs12 　　這里需要指明倉庫類型為pkcs12，因為缺省的類型為jks。這樣此密鑰倉庫就即包含證書信息也包含私鑰信息。 　　P7B格式證書導入： 　　keytool無法直接導入p7b文件。 　　需要將證書鏈RootServer.p7b（包含根證書）導出為根rootca.cer和子rootcaserver.cer 。 　　將這兩個證書導入到可信任的密鑰倉庫中。 　　keytool -import -alias rootca -trustcacerts -file rootca.cer -keystore testkeytrust.jks 　　遇到是否信任該證書提示時，輸入y 　　keytool -import -alias rootcaserver -trustcacerts -file rootcaserver.cer -keystore testkeytrust.jks 　　總結： 　　1)P12格式的證書是不能使用keytool工具導入到keystore中的 　　2)The Suns PKCS12 Keystore對從IE和其他的windows程序生成的pfx格式的證書支持不太好. 　　3)P7B證書鏈不能直接導入到keystore，需要將里面的證書導出成cer格式，再分別導入到keystore。 2.OPENSSL使用 生成私鑰 Generate the private key 　　請使用以下命令來生成私鑰 　　openssl genrsa –des3 –out [url]www.mydomain.com.key[/url] 1024 　　如上所示，此命令將生成1024位的RSA私鑰，私鑰文件名為： [url]www.mydomain.com.key[/url]，會提示您設定私鑰密碼，并牢記！ 　　生成CSR文件 Generate the CSR 　　請使用以下命令來生成CSR 　　openssl req –new –key [url]www.mydomain.com.key[/url] –out [url]www.mydomain.com.csr[/url] 　　此命令將提示您輸入X.509證書所要求的字段信息，包括國家(中國添CN)、省份、所在城市、單位名稱、單位部門。名稱(可以不填直接回車)。請注意： 除國家縮寫必須填CN外，其余都可以是英文或中文。請輸入您要申請SSL證書的域名，如果您需要為[url]www.domain.com[/url]申請SSL證書就不能只輸入domain.com。SSL證書是嚴格綁定域名的。請不要輸入Email、口令(challenge password)和可選的公司名稱，直接打回車即可。您現在已經成功生成了密鑰對，私鑰文件：[url]www.mydomain.com.key[/url] 保存在您的服務器中， 請把CSR文件：[url]www.mydomain.com.csr[/url] 發(fā)給WoTrust/Thawte即可。 　 備份私鑰文件 Backup your private key 　　請備份您的私鑰文件并記下私鑰密碼。最好是把私鑰文件備份到軟盤或光盤中。 　 幾種證書轉換 （1） 用openssl創(chuàng)建CA證書的RSA密鑰(PEM格式)： 　　openssl genrsa -des3 -out ca.key 1024 　　（2）用openssl創(chuàng)建CA證書(PEM格式,假如有效期為一年)： 　　openssl req -new -x509 -days 365 -key ca.key -out ca.crt -config openssl.cnf 　　openssl是可以生成DER格式的CA證書的，最好用IE將PEM格式的CA證書轉換成DER格式的CA證書。 　　（3）x509到pfx 　　openssl pkcs12 -export -out server.pfx -inkey server.key -in server.crt 　?。?）PEM格式的ca.key轉換為Microsoft可以識別的pvk格式。 　　 pvk -in ca.key -out ca.pvk -nocrypt -topvk 　?。?）PKCS#12 到 PEM 的轉換 　　openssl pkcs12 -nocerts -nodes -in cert.p12 -out private.pem 　　驗證 openssl pkcs12 -clcerts -nokeys -in cert.p12 -out cert.pem 　　（6）從 PFX 格式文件中提取私鑰格式文件 (.key) 　　openssl pkcs12 -in mycert.pfx -nocerts -nodes -out mycert.key 　?。?）轉換 pem 到到 spc 　　openssl crl2pkcs7 -nocrl -certfile venus.pem -outform DER -out venus.spc 　　用 -outform -inform 指定 DER 還是 PAM 格式。例如： 　　openssl x509 -in Cert.pem -inform PEM -out cert.der -outform DER 　　（8）PEM 到 PKCS#12 的轉換， 　　openssl pkcs12 -export -in Cert.pem -out Cert.p12 -inkey key.pem 　　cd c：\openssl set OPENSSL_CONF=openssl.cnf openssl pkcs12 - 　　export -out server.pfx -inkey server.key -in server.crt (server.key和server.crt文件是Apache的證書文件，生成的server.pfx用于導入IIS)