怎樣驗證數字證書
數字證書號稱是網上的身份證。網上交易者通過交易對象的數字證書對其產生信任，並能夠使用和證書綁定的公鑰和交易對象通信，這是PKI認證機制的基本宗旨。但是，當網上交易者從交易對象那裏直接獲取，或通過訪問CA證書庫等不同途徑得到了交易對象的數字證書以後，這張證書不經過驗證是不能放心使用的。驗證由安全認證應用軟件執行，驗證需要包括以下的內容：
· 證書完整性驗證。即確認這個證書沒有被別人篡改過。這項驗證可以通過驗證證書中CA的數字簽名而完成。
· 證書可信性驗證。即確認該證書是由一個可信的CA頒發的。爲此驗證者必須驗證證書鏈，即從對方的CA信任域的底層開始，逐層向上查詢，一直追溯到信任鏈的終點，通常是根CA爲止，找到權威的根CA的簽名，這才完成驗證。（有關證書鏈的概念，可參閱《晨曦》07年第 期知識園地“證書鏈是怎麼回事”一文。）
· 證書有效性驗證。即確認該證書是否已經失效。
· 有關證書使用策略限制的驗證。即確認證書的當前使用有沒有超出證書中規定的策略限制。
本文將對證書有效性的管理和驗證作一番探討。
證書有效性的管理機制
證書的有效性取決於兩個方面因素：
第一個因素是證書有效期,證書的有效期在證書被頒發之日就已經確定了，例如CFCA規定個人證書的有效期是一年（可擴展），企業證書的有效期是三年。證書的有效期（Validity Period）作爲一項內容被寫進了數字證書之中，它用兩個日期——證書開始生效的日期和證書失效的日期來表示。顯然，已經過了有效期的證書不能通過驗證。
證書有效期的設定是出於安全的考慮，當一張證書有效期將結束時，如果想繼續使用就需要更新，證書更新時將產生新的公私密鑰對，密鑰定期更新對於證書的安全性是有好處的。
第二個因素是證書註銷,雖然證書有效期沒有過，但是如果發生了特殊情況，例如用戶發現證書遺失或私鑰失密，用戶會向CA/RA提出註銷證書的申請，CA/RA經過審覈後將實施證書註銷。那麼，被註銷的證書也不能通過驗證。
第一種情況比較簡單，證書的有效期就寫在了證書之中，安全認證應用軟件只要調出證書的內容，判斷一下就知道這張數字證書當前是否還在有效期內。
第二種情況則比較複雜，證書一旦發出，是不可能收回的。怎麼辦呢？只能申請註銷。所謂註銷，就是要求當初頒發這張證書的單位（CA）出一張告示，宣佈某張證書已經被註銷作廢，警告有關的交易者注意，不要再使用與這張證書綁定的公鑰。在PKI安全認證體系中，這種“告示”稱爲證書註銷列表（或證書撤銷清單、證書註銷清單、證書廢止列表等），英文原文是Certificate Revocation List，縮寫爲CRL。
對於第二種情況，安全認證應用軟件在驗證證書的有效性時就需要去訪問證書註銷列表（CRL）。這個列表相當於“黑名單”，一旦發現通信對方的證書在這張列表中，就不能通過驗證。
證書註銷機制可以防止證書遺失或發現私鑰失密後，不法分子冒用用戶證書、私鑰實行欺詐交易所帶來的損失。這和信用卡註銷、有效證件註銷的機制十分類似。
註銷證書的其他原因還包括：銀行方面認爲證書用戶信用喪失、用戶身份姓名發生改變、用戶從他所屬單位離職、崗位和職權發生變更等情況。
CRL的內容
根據X.509標準，CRL的內容和數據結構定義如下圖所示：
CRL的內容包括CRL的版本號、計算本CRL的數字簽名所用的算法的標識符（如加密算法RSA、數字摘要算法MD5等算法的標識符）、頒發CRL的CA的可識別名（DN）、CRL的發佈/更新時間、被註銷證書的列表（僅列出被註銷證書的唯一序列號）以及擴展項。
擴展項中的內容有：
a、理由代碼——指出該證書被註銷的理由，如：密鑰損壞、CA損壞、關係變動、操作終止等；
b、證書頒發者——列出該證書頒發者的名字；
c、控制指示代碼——用於證書的臨時凍結；
d、失效日期——列出該證書不再有效的日期。
爲了保證CRL的真實性和完整性，CRL數據的後面附有頒發CRL的CA對CRL的數字簽名。
CRL的發佈
CRL的數據形成後，要把它公佈在網上，放在哪裏呢？首先，在CFCA的證書系統中，設置了一個LDAP服務器，它與互聯網相連接，有特定的IP地址，CRL的數據就放在這裏供用戶查詢。LDAP的全稱是Lightweight Directory Access Protocol，即輕型目錄訪問協議。LDAP的信息模型是建立在“條目”（entries）的基礎上，目錄的基本信息單元是條目。目錄條目呈現爲一個層次狀的樹形結構。CRL的數據以條目的形式存放在LDAP服務器中。根據LDAP目錄服務所具有的特性，用戶可以在網上方便快捷地對CRL進行查詢。
然而，CRL的數據集中存放在CA的服務器中可能帶來另一個問題，就是當用戶數量龐大，而且到了交易集中發生的高峯時期時，對LDAP服務器的併發訪問可能造成網絡和服務器的擁塞，致使交易效率急劇下降甚至超時。
解決這個問題有以下兩個辦法：
第一個辦法是使用分段的CRL，就是把龐大的CRL分成很多可控的片段，並允許一個CA的證書註銷信息通過多個CRL發佈出來。在證書的擴展項中，有一個子項稱爲CRL分佈點，它指出CRL分佈點的分佈位置，用戶可以根據這個參數來訪問相應的CRL。
第二個辦法是建立遠程的鏡像LDAP服務器。這些鏡像服務器分佈在其他城市或一些大客戶的所在地。CA的LDAP主服務器負責對這些鏡像服務器進行定期數據更新，以便使鏡像服務器的數據內容和主服務器保持一致。設置鏡像服務器的目的有兩個：一是加快當地用戶訪問目錄服務器的響應時間。二是通過設置鏡像服務器可以對大量的併發訪問進行分流，減輕高峯時間LDAP主服務器的負擔。此外，作爲一種備份機制，鏡像服務器還可以在主服務器故障期間起到備份作用，提供不間斷服務，這就提高了整個系統的可用率。
CRL的更新
從安全的角度上講，CRL最好是進行實時更新，即一旦發生證書註銷事件就立即更新，以杜絕欺詐案件的得逞。但這種實時更新的代價非常高，要佔用大量的網絡資源和服務器資源，反過來又會影響到網上交易的進行。因此，業內普遍的做法是定期更新，如CFCA的管理策略是對主服務器的CRL和所有遠程鏡像CRL每天更新一次。
然而，當CRL數據總量非常龐大時，即使是每天更新一次也會給系統帶來過大的負擔。因此，又出現了增量CRL的概念。增量CRL的想法就是不需要每註銷一張證書就產生一個完整的、越來越大的CRL，它只是產生一個與註銷該證書相關的增加信息。
根據定義，增量CRL是以已經頒發的註銷信息爲基礎的，這個已經頒發的註銷信息稱爲基本CRL，增量CRL中含有的是基本CRL中不含有的信息。引入增量CRL概念的好處是體積很小的增量CRL可以比基本CRL的更新頻率高得多。例如，龐大的基本CRL的更新週期如果是一週的話，增量CRL的更新週期可以定爲8小時，甚至更短。顯然，這樣的安全策略具有較高的安全性，而且不會給系統造成大的負擔。
在線查詢機制——OCSP
我們在上文已經提到，CRL方法存在一些缺點，其一就是CRL不可能實時更新，由於CA每隔一定時間才發佈CRL，所以CRL不能及時地反應證書的狀態，在安全性上有一定侷限；其二，即使定期更新CRL也有麻煩，當註銷證書的數量很大及用戶基礎很大時，CRL常常會越變越大。 每次CRL分發會大量消耗網絡帶寬和服務器處理能力。對於很多集羣客戶來說（例如一家銀行和它的衆多客戶或者一家大企業和它的子公司、分銷店），爲了提高證書有效性驗證效率，往往把CRL先下載到自己的服務器上，以減少對CRL的在線查詢。然而頻繁地下載CRL也是令用戶頭疼的問題。有時候，這種CRL處理方式還要求用戶配置客戶PC來處理來自多個證書機構的CRL。
於是，另一種證書有效性的管理和查詢方法，即在線查詢機制應運而生。它使用的協議稱爲在線證書狀態協議，英文是OCSP（Online Certificate Status Protocol）。
在線證書狀態協議（OCSP）是IETF頒佈的用於檢查數字證書在某一交易時間是否有效的標準，在RFC 2560中有描述。它爲網上業務提供了一種檢驗數字證書有效性的途徑，比下載和處理證書註銷列表（CRL）的傳統方式更快、更方便和更具獨立性。OCSP實時在線地向用戶提供證書狀態，其結果是它比CRL處理快得多，並避免了令人頭痛的邏輯問題和處理開銷。
OCSP在線查詢機制的簡單過程如下（見插圖）：
圖：OCSP在線查詢原理圖
用戶的客戶機形成查詢指定證書狀態請求，並將請求轉發到一個OCSP應答器(服務器)，應答器建立與CA證書庫的連接，並查詢CA證書庫而獲得該證書的狀態，應答器返回客戶機有關證書有效性信息。
簡單地說，一個OCSP請求，由協議版本號、服務請求類型及一個或多個證書標識符等信息所組成；響應信息是由證書標識符、證書狀態——“有效”、“註銷”或“未知”三個中的一個、以及驗證相應時間等信息所組成。詳細信息見下表所示。
表：OCSP響應信息
（引自CFCA OCA2系統CPS）
響應信息必須經過數字簽名，以保證這個信息的真實性和完整性（未被篡改）。簽名密鑰屬於CA，即頒發這張證書的權威、可信的第三方機構，因此，在任何情況下，用戶都能夠信任這個信息。
OCSP在線查詢機制只能檢測證書的註銷狀態，沒有其他功能，例如不能檢查證書的有效期，也不返回用戶一個完全的證書。但是這種用法在某些應用場合下，對於驗證證書的有效性來說是快速有效的。
由於使用OCSP在線查詢必須保持用戶在線狀態，且用戶訪問的對象集中在CA的OCSP服務器上，這同樣會帶來高峯負載過重，交通擁塞效率下降的問題。
從以上的描述中我們可以看到，CRL和OCSP兩種機制所針對的目標和實現的功能是一樣的，只不過實現的方法途徑不一樣，兩者具有異曲同工之妙。用戶可根據自己的需求決定使用哪種方法，目前，CFCA對這兩種方法都提供服務。