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

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