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

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