數(shù)字證書格式常見的數(shù)字證書格式cer 后綴的證書文件有兩種編碼-->DER二進制編碼或者BASE64編碼(也就是. pem) p7b一般是證書鏈，里面包括1到多個證書pfx 是指以pkcs#12格式存

數(shù)字證書格式

常見的數(shù)字證書格式

cer 后綴的證書文件有兩種編碼-->DER二進制編碼或者BASE64編碼(也就是. pem) p7b一般是證書鏈，里面包括1到多個證書pfx 是指以pkcs#12格式存儲的證書和相應私鑰。在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)，同時也支持單個證書，不含私鑰。其中，我介紹如何從p12/pfx文件中提取密鑰對及其長度: 1，首先，讀取pfx/p12文件（需要提供保護密碼）

2，通過別名(Alias,注意，所有證書中的信息項都是通過Alias 來提取的) 提取你想要分析的證書鏈

3，再將其轉(zhuǎn)換為一個以X509證書結(jié)構體

4，提取里面的項，如果那你的證書項放在第一位（單一證書），直接讀取 x509Certs[0]（見下面的代碼）這個X509Certificate 對象

5，X509Certificate 對象有很多方法，tain198127網(wǎng)友希望讀取RSA 密鑰（公私鑰）及其長度（見 http://www.matrix.org.cn/thread.shtml?topicId=43786&forumId=55&#reply），那真是太Easy 了，

X509Certificate keyPairCert = x509Certs[0];

int iKeySize = X509CertUtil.getCertificateKeyLength(keyPairCert); System.out.println("證書密鑰算法=" keyPairCert.getPublicKey().getAlgorithm());

System.out.println("證書密鑰長度=" iKeySize);

提取了他所需要的信息。

X.509定義了兩種證書：公鑰證書和屬性證書

PKCS#7和PKCS#12使用的都是公鑰證書

PKCS＃7的SignedData 的一種退化形式可以分發(fā)公鑰證書和CRL 一個SignedData 可以包含多張公鑰證書

PKCS＃12可以包含公鑰證書及其私鑰，也可包含整個證書鏈

簡介

Java 自帶的keytool 工具是個密鑰和證書管理工具。它使用戶能夠管理自己的公鑰/私鑰對及相關證書，用于（通過數(shù)字簽名）自我認證（用戶向別的用戶/服務認證自己）或數(shù)據(jù)完整性以及認證服務。它還允許用戶儲存他們的通信對等者的公鑰（以證書形式）。keytool 將密鑰和證書儲存在一個所謂的密鑰倉庫（keystore ）中。缺省的密鑰倉庫實現(xiàn)將密鑰倉庫實現(xiàn)為一個文件。它用口令來保護私鑰。

Java KeyStore的類型

JKS 和JCEKS 是Java 密鑰庫(KeyStore)的兩種比較常見類型(我所知道的共有5種，JKS, JCEKS, PKCS12, BKS，UBER) 。

JKS 的Provider 是SUN ，在每個版本的JDK 中都有，JCEKS 的Provider 是S UNJCE ，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 都會產(chǎn)生錯誤），BKS 能夠跟JKS 互操作，讀者可以用Keytool 去TryTry 。U BER 比較特別，當密碼是通過命令行提供的時候，它只能跟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 命令來查看密鑰倉庫里的內(nèi)容：

keytool -list -rfc -keystore mykeystore.jks

P12格式證書導入：

keytool 無法直接導入PKCS12文件。

第一種方法是使用IE 將pfx 證書導入，再導出為cert 格式文件。使用上面介紹的方法將其導入到密鑰倉庫中。這樣的話倉庫里面只包含了證書信息，沒有私鑰內(nèi)容。

第二種方法是將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 轉(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 格式證書導入：

keytool 無法直接導入p7b 文件。

需要將證書鏈RootServer.p7b （包含根證書）導出為根rootca.cer 和子r ootcaserver.cer 。

將這兩個證書導入到可信任的密鑰倉庫中。

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 工具導入到keystore 中的

2)The Sun's PKCS12 Keystore對從IE 和其他的windows 程序生成的pfx 格式的證書支持不太好.

3)P7B 證書鏈不能直接導入到keystore ，需要將里面的證書導出成cer 格式，再分別導入到keystore 。

**************************************

數(shù)字證書文件格式（cer 和pfx ）的區(qū)別

作為文件形式存在的證書一般有這幾種格式：

1. 帶有私鑰的證書

由Public Key Cryptography Standards #12，PKCS#12標準定義，包含了公鑰和私鑰的二進制格式的證書形式，以

pfx 作為證書文件后綴名。

2. 二進制編碼的證書

證書中沒有私鑰，DER 編碼二進制格式的證書文件，以cer 作為證書文件后綴名。

3.Base64編碼的證書

證書中沒有私鑰，BASE64 編碼格式的證書文件，也是以cer 作為證書文件后綴名。 由定義可以看出，只有pfx 格式的數(shù)字證書是包含有私鑰的，cer 格式的數(shù)字證書里面只有公鑰沒有私鑰。在pfx 證書的導入過程中有一項是“標志此密鑰是可導出的。這將您在稍候備份或傳輸密鑰”。一般是不選中的，如果選中，別人就有機會備份你的密鑰了。如果是不選中，其實密鑰也導入了，只是不能再次被導出。這就保證了密鑰的安全。

如果導入過程中沒有選中這一項，做證書備份時“導出私鑰”這一項是灰色的，不能選。只能導出cer 格式的公鑰。

如果導入時選中該項，則在導出時“導出私鑰”這一項就是可選的。

如果要導出私鑰（pfx), 是需要輸入密碼的，這個密碼就是對私鑰再次加密，這樣就保證了私鑰的安全，別人即使拿到了你的證書備份（pfx), 不知道加密私鑰的密碼，也是無法導入證書的。相反，如果只是導入導出cer 格式的證書，是不會提示你輸入密碼的。因為公鑰一般來說是對外公開的，不用加密

*************************

SSL 證書類型和轉(zhuǎn)換

PKCS 全稱是 Public-Key Cryptography Standards ，是由 RSA 實驗室與其它安全系統(tǒng)開發(fā)商為促進公鑰密碼的發(fā)展而制訂的一系列標準，PKCS 目前共發(fā)布過 15 個標準。 常用的有：

PKCS#7 Cryptographic Message Syntax Standard

PKCS#10 Certification Request Standard

PKCS#12 Personal Information Exchange Syntax Standard

X.509是常見通用的證書格式。所有的證書都符合為Public Key Infrastructure (PKI) 制定的 ITU-T X509 國際標準。

PKCS#7 常用的后綴是： .P7B .P7C .SPC

PKCS#12 常用的后綴有： .P12 .PFX

X.509 DER 編碼(ASCII)的后綴是： .DER .CER .CRT

X.509 PAM 編碼(Base64)的后綴是： .PEM .CER .CRT

.cer/.crt是用于存放證書，它是2進制形式存放的，不含私鑰。 .pem 跟crt/cer的區(qū)別是它以Ascii 來表示。

pfx/p12用于存放個人證書/私鑰，他通常包含保護密碼，2進制方式 p10是證書請求

p7r 是CA 對證書請求的回復，只用于導入

p7b 以樹狀展示證書鏈(certificate chain)，同時也支持單個證書，不含私鑰。

1. 生成私鑰 Generate the private key

請使用以下命令來生成私鑰

openssl genrsa –des3 –out [url]www.mydomain.com.key[/url] 1024 如上圖所示，此命令將生成1024位的RSA 私鑰，私鑰文件名為： [url]www.mydomain.com.key[/url]，會提示您設

定私鑰密碼，請設置密碼，并牢記！

2. 生成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)和可選的公司名稱，直接打回車即可。

您現(xiàn)在已經(jīng)成功生成了密鑰對，私鑰文件：[url]www.mydomain.com.key[/url] 保存在您的服務器中， 請把CSR 文

件：[url]www.mydomain.com.csr[/url] 發(fā)給WoTrust/Thawte即可，CSR 文件格式如下圖所示。

3. 備份私鑰文件 Backup your private key

請備份您的私鑰文件并記下私鑰密碼。最好是把私鑰文件備份到軟盤或光盤中。

4. 測試CSR

生成CSR 后，建議您自己測試一下生成的CSR 文件是否正確，

一 用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

四 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 用于導入IIS)

*********************

公鑰和私鑰的區(qū)別

公鑰密碼體制的核心思想是：加密和解密采用不同的密鑰。這是公鑰密碼體制和傳統(tǒng)的對稱密碼體制最大的區(qū)別。對于傳統(tǒng)對稱密碼而言，密文的安全性完全依賴于 密鑰的保密性，一旦密鑰泄漏，將毫無保密性可言。但是公鑰密碼體制徹底改變了這一狀況。在公鑰密碼體制中，公鑰是公開的，只有私鑰是需要保密的。知道公鑰 和密碼算法要推測出私鑰在計算上是不可行的。這樣，只要私鑰是安全的，那么加密就是可信的。

顯然，對稱密碼和公鑰密碼都需要保證密鑰的安全，不同之處在于密鑰的管理和分發(fā)上面。在對稱密碼中，必須要有一種可靠的手段將加密密鑰（同時也是解密密 鑰）告訴給解密方；而在公鑰密碼體制中，這是不需要的。解密方只需要保證自己的私鑰的保密性即可，對于公鑰，無論是對加密方而言還是對密碼分

析者而言都是 公開的，故無需考慮采用可靠的通道進行密碼分發(fā)。這使得密鑰管理和密鑰分發(fā)的難度大大降低了。

加密和解密:發(fā)送方利用接收方的公鑰對要發(fā)送的明文進行加密, 接受方利用自己的

私鑰進行解密, 其中公鑰和私鑰匙相對的, 任何一個作為公鑰, 則另一個 就為私鑰. 但是因為非對稱加密技術的速度比較慢, 所以, 一般采用對稱

加密技術加密明文, 然后用非對稱加密技術加密對稱密鑰, 即數(shù)字信封 技術. 簽名和驗證:發(fā)送方用特殊的hash 算法，由明文中產(chǎn)生固定長度的摘要，然后利用

自己的私鑰對形成的摘要進行加密，這個過程就叫簽名。接受方利用 發(fā)送方的公鑰解密被加密的摘要得到結(jié)果A ，然后對明文也進行hash 操 作產(chǎn)生摘要B. 最后, 把A 和B 作比較。此方式既可以保證發(fā)送方的身份不 可抵賴，又可以保證數(shù)據(jù)在傳輸過程中不會被篡改。

首先要分清它們的概念:

加密和認證

首先我們需要區(qū)分加密和認證這兩個基本概念。

加密是將數(shù)據(jù)資料加密，使得非法用戶即使取得加密過的資料，也無法獲取正確的資料內(nèi)容， 所以數(shù)據(jù)加密可以保護數(shù)據(jù)，防止監(jiān)聽攻擊。其重點在于數(shù)據(jù)的安全性。身份認證是用來判斷某個身份的真實性，確認身份后，系統(tǒng)才可以依不同的身份給予不同的 權限。其重點在于用戶的真實性。兩者的側(cè)重點是不同的。

公鑰和私鑰

其次我們還要了解公鑰和私鑰的概念和作用。

在現(xiàn)代密碼體制中加密和解密是采用不同的密鑰（公開密鑰），也就是非對稱密鑰密碼系統(tǒng)，每個通信方均需要兩個密鑰，即公鑰和私鑰，這兩把密鑰可以互為加解密。公鑰是公開的，不需要保密，而私鑰是由個人自己持有，并且必須妥善保管和注意保密。

公鑰私鑰的原則：

一個公鑰對應一個私鑰。

密鑰對中，讓大家都知道的是公鑰，不告訴大家，只有自己知道的，是私鑰。

如果用其中一個密鑰加密數(shù)據(jù)，則只有對應的那個密鑰才可以解密。 如果用其中一個密鑰可以進行解密數(shù)據(jù)，則該數(shù)據(jù)必然是對應的那個密鑰進行的加密。

非對稱密鑰密碼的主要應用就是公鑰加密和公鑰認證，而公鑰加密的過程和公鑰認證的過程是不一樣的，下面我就詳細講解一下兩者的區(qū)別。

事例說明下:

例如:比如有兩個用戶Alice 和Bob ，Alice 想把一段明文通過雙鑰加密的技術發(fā)送給Bob ，Bob 有一對公鑰和私鑰，那么加密解密的過程如下：

Bob 將他的公開密鑰傳送給Alice 。

Alice 用Bob 的公開密鑰加密她的消息，然后傳送給Bob 。

Bob 用他的私人密鑰解密Alice 的消息。

那么Bob 怎么可以辨認Alice 是不是真人還是冒充的. 我們只要和上面的例子方法相反就可以了.

Alice 用她的私人密鑰對文件加密，從而對文件簽名。

Alice 將簽名的文件傳送給Bob 。

Bob 用Alice 的公鑰解密文件，從而驗證簽名。

通過例子大家應該有所了解吧!