眾所周知，公鑰密碼學通過使用公鑰和私鑰這一密鑰對，使數字簽名和加密通訊等密鑰服務變得容易起來。公鑰技術之所以能得到廣泛的應用，原因就在於對那些使用密鑰對中的公鑰來獲得安全服務的實體，他們能很方便地取得公鑰，即密鑰分發與管理比起對稱密鑰的分發與管理變得簡單了。所以有人稱，非對稱密碼算法是計算機安全通訊的一次技術革命。
　　當然，公鑰的分發也需要數據完整性保護措施，即需要數據完整性服務來保障公鑰不被篡改，並保證公鑰一定要有與其聲明持有者的身份相對應綁定的機制，最終目的是能提供一種簡單安全識別的機制，其一可以使公鑰及其相關信息的完整性得到保障；其二可以使公鑰及其相關信息以一種可信的方式與其聲明所有者綁定在一起。
　　這就是證書機制，證書在電子商務中是一種權威性的文檔，證書的頒發者必須具有可信賴性，它是由權威性、可信任性和公正性的第三方機構所頒發的。證書是一種安全機制，它能保證實現和完成PKI的身份認證、完整性、保密性及不可否認性的安全服務。
　　證書是一種新的安全機制，一般初期使用者會感到困惑。如一個網上購物者或網上銀行客戶，或是一個某銀行支付網關的管理員，他（她）們經常會想：為什麽瀏覽器 /服務器中裝入數字證書就會在互聯網上變得安全了呢？它們在實際認證中是如何操作的？它是如何保證安全的呢？針對這些常見的問題，本文通過討論 X.509V3版公鑰證書的結構和語義、內容和用途以及對證書的哪些項要進行檢查和如何進行檢查的全部過程等，來說明證書認證的安全性。相信廣大讀者在了解了證書認證的“遊戲規則”以後，對證書機制所能完成的身份識別和鑒別認證的安全服務會有所理解。證書確實是網上交易安全的守護神。
一、有關概念
　　1.關於CA
　　CA(Certification Authority)在PKI中稱“認證機構”，它為電子商務環境中各個實體頒發電子證書，即對實體的身份信息和相應公鑰數據進行數字簽名，用以捆綁該實體的公鑰和身份，以證明各實體在網上身份的真實性；並負責在交易中檢驗和管理證書。CA是認證電子商務和網上銀行交易的權威性、可信賴性及公正性的第三方機構，是電子商務的重要基礎設施，是電子商務的安全保證。
　　2.關於數字證書
　　數字證書也叫電子證書,或簡稱證書，在很多場合下,數字證書、電子證書和證書都是X.509公鑰證書的同義詞，它符合ITU－T X.509 V3標準。證書是隨PKI的形成而新發展起來的安全機制，它實現身份的鑒別與識別（認證）、完整性、保密性及不可否認性安全服務（安全需求）；數字證書是電子商務中各實體的網上身份的證明，它證明實體所聲明的身份與其公鑰的匹配關系，使得實體身份與證書上的公鑰相綁定；從公鑰管理的機制來講，數字證書是公鑰體制密鑰管理的媒介，即在公鑰體制中，公鑰的分發、傳送是靠證書機制來實現的。所以有時也將數字證書稱為公鑰證書；數字證書是一種權威性的電子文檔，它是由具有權威性、可信任性及公正性的第三方機構（CA）所頒發。
二、證書的內容及用途
　　CFCA所發放的證書均遵循X.509 V3標準，其基本格式及其用途如下：
　　1.Certificate Format Version
　　證書版本號,用來指定證書格式用的X.509版本號，用於目錄查詢。
　　2.Certificate Serial Number
　　證書序列號,證書頒發者指定證書唯一序列號, 以標識CA發出的所有證書，用於目錄查詢。
　　3.Signature Algorithm Identifier
　　簽名算法標識,用來指定本證書所用的簽名算法（如SHA－1、RSA）。
　　4.Issuer
　　簽發此證書的CA名稱,用來指定簽發證書的CA的可識別的唯一名稱(DN, Distinguished Name)，用於認證。
　　5.Validity Period
　　證書有效期,指定證書起始日期（notBefore）和終止日期（notAfter），用於校驗證書的有效性。
　　6.Subject
　　用戶主體名稱,用來指定證書用戶的X.500唯一名稱(DN)，用於認證。
　　7.Subject Public Key Information
　　用戶主體公鑰信息。
　　(1)Algorithm Identifier,算法標識。用來標識公鑰使用的算法。
　　(2)Subject Public Key,用戶主體公鑰。用來標識公鑰本身，用於加/解密和數字簽名。
　　8.Issuer Unique ID
　　頒發者可選唯一標識，很少用。
　　9.Subject Unique ID
　　主體證書擁有者唯一標識，很少用。
　　10.Extensions
　　證書擴充部分(擴展域)，用來指定額外信息。
　　(1)Authority Key Identifier,簽發者CA的公鑰標識。
　　　　Key Identifier,公鑰標識;
　　　　Cert Issuer,證書簽發者的甄別名,電子郵件、IP地址等;
　　　　Cert Serial Number,簽發證書的序列號,用於簽發根證書及交叉認證。
　　(2)Subject Key Identifier,用戶主體的公鑰標識。證書主體所含密鑰的唯一標識，用來區分一個證書擁有者的多對密鑰，主要用於對由以前公鑰加密過的文件進行解密。
　　(3)CRL Distribution Point, CRL分布。指明CRL分段的地點，用於分布式存放。
　　(4)Key Usage,證書中的公鑰用途，用來指定公鑰用途,數字簽名、加密等。
　　(5)Private Key Usage Period,用戶的私鑰有效期。用來指定用戶簽名私鑰的起始日期和終止日期。
　　(6)Certificate Policies,CA承認的證書政策列表。用來指定用戶證書所適用的政策, 證書政策可由對象標識符表示，一個詳細提示（200字符）。
　　(7)Policy Mappings,策略映射。表明在兩個CA之間一個或多個策略標識的等價映射關系——僅在CA證書裏存在。
　　(8)Subject Alt Name,用戶的代用名。用來指定用戶的代用名。
　　(9)Issuer Alt Name,CA的代用名。用來指定CA的代用名。
　　(10)Basic Constraints,基本制約。用來表明證書用戶是最終用戶還是CA，用於交易路徑。
　　(11)Subject Directory Attributes,用戶主體目錄屬性。指出證書擁有者的一系列屬性。
　　11.Signature Acgorithm
　　CA簽名算法標識。
　　12.CA Signature
　　CA簽名。
三、證書的認證過程
　　以上介紹了證書結構、內容及用途，那麽證書是如何相互認證的呢？相互的身份是如何識別的？為什麽應用證書機制就是安全的呢？
　　首先看一下證書的認證過程（也稱驗證過程）。
　　1.拆封證書
　　所謂證書的拆封，是驗證發行者CA的公鑰能否正確解開客戶實體證書中的“發行者的數字簽名”。兩個證書在交換傳遞之後，要進行拆封，看是否能夠拆封。一個證書或證書鏈的拆封操作，是為了從中獲得一個公鑰。可示為X1p?X1<<X2>>,這為一個中綴操作，其左操作數為一個認證機構的公鑰，右操作數則為該認證機構所頒發的一個證書。如果能正確解開，輸出結果為用戶的公鑰。
　　從證書內容列表中可以看出，證書結構的最後內容是認證機構CA的數字簽名，即一個可信任的CA已經在證書上用自己的私鑰做了簽名。如果用該CA的公鑰就可以拆封一個用戶實體的證書，那麽，這個簽名被驗證是正確的。因為它證明了這個證書是由權威的、可信任的認證機構所簽發。因此，這個實體證書是真實可信的。
　　2.證書鏈的驗證
　　所謂證書鏈的驗證，是想通過證書鏈追溯到可信賴的CA的根（ROOT）。換句話說，要驗證簽發用戶實體證書的CA是否是權威可信的CA，如CFCA。證書鏈驗證的要求是，路徑中每個證書從最終實體到根證書都是有效的，並且每個證書都要正確地對應發行該證書的權威可信任性CA。操作表達式為 Ap?A<<B>>B<<C>>,指出該操作使用A的公鑰，從B的證書中獲得B的公鑰Bp，然後再通過 Bp來解封C的證書。操作的最終結果得到了C的公鑰Cp。這就是一個證書鏈的認證拆封過程。
　　(1)證書鏈的定義。證書鏈也稱認證鏈，它是最終實體到根證書的一系列證書組成，這個證書鏈的處理過程是所有根的前輩指向最開始的根證書，即子輩連向父輩。如圖1所示。
　　證書（無論是SET或是Non－SET證書）是通過圖1所顯示的信任層次來驗證的，每個證書都對應於發行該證書的實體的數字簽名。如圖所示，SET：CCA（MCA、PCA）—B—R；non－SET：CCA（BCA、UCA）—P—R。這樣就可用一級一級的公鑰解開每級的數字簽名，一直上溯到可信任的根CA ROOT。它們是通過直到根CA ROOT的信任層次來驗證證書的。
　　(2)從用戶實體證書到ROOT CA的證書鏈確認，其具體的做法如下頁圖2所示。
　　從以上對比中可以看出：用戶實體證書中的Authority Key Identifier擴展項Cert Issuer，即證書簽發者的甄別名，應當與CA證書中簽發此證書的CA名稱相匹配，如圖中箭頭所指。即CA證書中的Subject Name是用戶實體證書中Issuer Name的父名，對上級CA來說又成為子名，CA證書中Issuer Name是上一級CA的名字，成為可信任的鏈狀結構。這樣通過各級實體證書的驗證，逐漸上溯到鏈的終止點——可信任的根CA，如CFCA。
　　3．序列號驗證
　　序列號的驗證是指檢查實體證書中的簽名實體序列號是否與簽發者證書的序列號相一致，驗證證書的真偽。驗證操作過程是：用戶實體證書中的Authority Key Identifier擴展項Cert Serial Number,即簽發證書的序列號，檢查CA證書中的Certificate Serial Number 證書序列號，二者應該相一致，否則證書不是可信任的認證機構CA所簽發。
　　4．有效期驗證
　　有效期驗證就是檢查用戶證書使用的日期是否合法，有無過期。具體做法為：
　　（1）用戶實體證書的有效期Validity Period及私鑰的有效期Priva Key Usege Period,應當在CA證書的有效日期Validity Period之內。如圖2中粗箭頭所示，超過CA證書有效期，實體證書應作廢，交易是不安全的。
　　（2）用戶實體證書有效期開始時間Validity Period中notBefore日期應在CA證書的私鑰有效期Private Key Usagc Period日期之內，否則證書是不安全的。
　　5．證書作廢止列表查詢
　　所謂證書作廢止列表查詢，是檢查用戶的證書是否已經作廢，並發布在證書吊銷列表中。一般稱CRL查詢，俗稱“黑名單查詢”。一個實體證書因私鑰泄密等原因，需要廢止時，應及時向CA聲明作廢。CA實時地通過LDAP標準協議向證書庫中以X.500的格式進行發布，以供訪問時實體間進行開放式查詢。
　　瀏覽器和Web服務器之間進行的雙方認證，即進行雙向CRL查詢，在Web服務器查詢瀏覽器證書是否為“黑名單”的同時，瀏覽器也去證書庫查詢Web服務器證書是否為有效。此為“雙向認證”，CFCA的企業級高級證書即為這種機制，是中國金融CA PKI的特點。一般B to B模式的網上銀行、網上購物皆采取這種方式。當然，也有“單向認證”方式，即Web服務器只去查驗瀏覽器證書的有效性，如SSL證書的認證，這是一般CA 的普遍做法。
　　6.證書使用策略的認證
　　證書的使用方式與任何聲明的策略Certificate Policy或使用限制相一致，即用戶實體證書中的Certificate Policies應為CA所承認的證書政策列表。它是用特殊擴展域來限定的，用來指定用戶證書所適用的政策，這些政策應在CA的CPS中有明確規定，對象標識符不超過200個字符。沒有CA承認的政策，用戶證書是不能執行的。如Policy URL、 Policy E－mail地址，必須由根政策陳述。
　　7.最終用戶實體證書的確認
　　為了證書的使用安全，CA所簽發的認證機構內部管理員的證書要與最終用戶實體證書相區分。為此：
　　(1)在擴展域基本制約Basic Constraints中其默認值表示最終實體（End Entity），以區別其他CA內部管理證書，防止證書用於不同的目的。
　　(2)在擴展域Key Usage中要對聲明的用途有效，用於數字簽名或用於傳輸加密，為確保安全，要明確分開，不能混用，以備爭議時審計，為仲裁提供依據。
　　當然，以上這些操作對用戶來說都是透明的。
　　關於數字證書(雙向)的若幹想法[ZT]
　　雙向數字認證,需要客戶端和服務器均有自己的私鑰和公鑰(一般為X509證書),
　　工程服務器為Apache或是Tomcat,客戶端一般可發布為Pkcs12包.
　　SSL工作原理:
　　SSL協議使用不對稱加密技術實現會話雙方之間信息的安全傳遞。可以實現信息傳遞的保密性、完整性，並且會話雙方能鑒別對方身份。不同於常用的http協議，我們在與網站建立SSL安全連接時使用https協議，即采用https://ip:port/的方式來訪問。當我們與一個網站建立https連接時，我們的瀏覽器與Web Server之間要經過一個握手的過程來完成身份鑒定與密鑰交換，從而建立安全連接。具體過程如下：
　　用戶瀏覽器將其SSL版本號、加密設置參數、與session有關的數據以及其它一些必要信息發送到服務器。
　　服務器將其SSL版本號、加密設置參數、與session有關的數據以及其它一些必要信息發送給瀏覽器，同時發給瀏覽器的還有服務器的證書。如果配置服務器的SSL需要驗證用戶身份，還要發出請求要求瀏覽器提供用戶證書。
　　客戶端檢查服務器證書，如果檢查失敗，提示不能建立SSL連接。如果成功，那麽繼續。客戶端瀏覽器為本次會話生成pre-master secret，並將其用服務器公鑰加密後發送給服務器。如果服務器要求鑒別客戶身份，客戶端還要再對另外一些數據簽名後並將其與客戶端證書一起發送給服務器。
　　如果服務器要求鑒別客戶身份，則檢查簽署客戶證書的CA是否可信。如果不在信任列表中，結束本次會話。如果檢查通過，服務器用自己的私鑰解密收到的pre-master secret，並用它通過某些算法生成本次會話的master secret。
　　客戶端與服務器均使用此master secret生成本次會話的會話密鑰(對稱密鑰)。在雙方SSL握手結束後傳遞任何消息均使用此會話密鑰。這樣做的主要原因是對稱加密比非對稱加密的運算量低一個數量級以上，能夠顯著提高雙方會話時的運算速度。
　　客戶端通知服務器此後發送的消息都使用這個會話密鑰進行加密。並通知服務器客戶端已經完成本次SSL握手。
　　服務器通知客戶端此後發送的消息都使用這個會話密鑰進行加密。並通知客戶端服務器已經完成本次SSL握手。
　　本次握手過程結束，會話已經建立。雙方使用同一個會話密鑰分別對發送以及接受的信息進行加、解密。
幾個概念:
　　1.個人信息交換 (PKCS #12)
　　個人信息交換格式（PFX，也稱為 PKCS #12）允許證書及相關私鑰從一臺計算機傳輸到另一臺計算機或可移動媒體。
　　2.DER 編碼和Base64編碼
　　在各類證書,私鑰及其參數一般有兩種表示,Der為二進制表示格式,Base64不言自明,在應用過程中無甚差別,但是因為Base64的文本性,其很容易在HTTP環境傳播.
　　3.PKCS#10：描述證書請求語法, 證書請求文件一般以csr為擴展名.
　　4.X509證書封裝了公鑰.一般意義可以認為證書就是公鑰,當然公鑰未必是以X509證書形式存在.
　　5.PKCS7,一般用於證書鏈.以p7b結尾.
　　6.CRL, Certificate revocation list.證書失效列表.
　　7.Openssl提供了CA認證的全面支持,Keytool及JCA,JCE API對應了Java對PKI實現
若幹問題.
　　1.客戶端數字證書及私鑰的發放方法,
　　可以客戶到櫃臺,由營業員辦理
　　可以由客戶生成自己的CSR文件,提交到網站,由系統自己生成.
　　由客戶在網頁上添加自己相關信息,由系統生成,發回客戶.
　　以上三種方法都需要進行確認客戶的真實性.都需要開發相應的支持系統.可用Java JCE API,Openssl API或是Openssl Commandline,Keytool實現.
　　2.數字證書 失效問題.
　　如果發生證書對應密鑰丟失,客戶可能需要對證書進行調銷,這需要建立建立比較完善的CA基礎,支持Certificate revocation list,這需要完整的CA解決方案.需要開發相應支持系統.
　　3.是否所有的客戶都必須選用數字證書.
　　理論上,至少在一段時間的轉移過程內,會出現使用和不使用數字證書的客戶同時存在,這樣需要建立兩套不同的系統.還要解決同一入口問題.
　　4.程序是否還需要用戶名和密碼的認證.
　　5.是否支持使用USB Key(這個應該不需要額外的開發工作).
　　6.項目前臺使用Flash管理對後臺服務器的連接,經測試能夠讀取所駐留瀏覽器的證書(及私鑰)信息,成功建立雙向SSL連接.
　　7.純從安全角度講,使用由verisign或其它可信的CA機關認證的證書並沒有好處,但這樣能提高客戶對公司的信任度,使公司能明確的向客戶確認自己的身份, 從實現角度講,如果采用自簽名CA的話,只是由公司內部CA對客戶證書進行簽名, 如果是使用經過如verisign簽名的證書,那麽公司將是二級CA,即證書的信任需要一個證書鏈,同樣也是由公司內的二級CA對客戶證書進行簽發.
　　8.調查實現的步驟,
　　因為沒有正式的證書及密鑰,測試過程選用了自簽名的證書,另外也沒有使用完整的CA基礎,沒有考慮CRL的問題,即證書註銷問題.

數字證書及其認證過程[轉載]