【转载】证书的有效性管理和验证--CRL和OCSP

怎样验证数字证书
　　 数字证书号称是网上的身份证。网上交易者通过交易对象的数字证书对其产生信任，并能够使用和证书绑定的公钥和交易对象通信，这是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对这两种方法都提供服务。