李明柱 博士 (mzli@263.net)

北京邮电大学信息安全中心

2002 年 6 月

3 证书认证机构CA

3.1 数字证书基础

数字证书是一种数字标识，可以说是Internet上的安全护照或身份证明。当人们到其他国家旅行时，用户护照可以证实其身份，并被获准进入这个国家。数字证书提供的是网络上的身份证明。

数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息和公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。一般情况下证书中还包括密钥的有效时间，发证机关（证书授权中心）的名称，该证书的序列号等信息，证书的格式遵循ITUT X.509国际标准。

3.1.1 证书格式

在 Internet网络中，应用程序使用的证书都来自不同的厂商或组织，为了实现可交互性，要求证书能够被不同的系统识别，符合一定的格式，并实现标准化。 X.509为证书及其CRL格式提供了一个标准。但X.509本身不是Internet标准，而是国际电联ITU标准，它定义了一个开放的框架，并在一定的范围内可以进行扩展。

为了适应PKI技术的发展，IETF也必须制定在Internet上使用X.509和CRL的标准。PKIX工作组就提供了一个Internet草案"Part I: X.509 Certificate and CRL Profile"（详细内容可见：ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-11.txt），用于定义在Internet PKI中使用X.509和CRL的方法和规范。该草案把X.509作为标准，并对各标准项和扩展做了说明，基本接收了X.509作为Internet中的证书标准，但也定义了被PKI应用的X.509 V3和CRL V2标准格式的设置，这些设置包含了PKIX工作组对X.509所做的一些新的扩展。

X.509目前有三个版本：V1、V2和V3，其中V3是在V2的基础上加上扩展项后的版本，这些扩展包括由ISO文档（X.509-AM）定义的标准扩展，也包括由其他组织或团体定义或注册的扩展项。X.509由ITU-T X.509（前身为CCITT X.509）或ISO/IEC 9594-8定义，最早以X.500目录建议的一部分发表于1988年，并作为V1版本的证书格式。X.500于1993年进行了修改，并在V1基础上增加了两个额外的域，用于支持目录存取控制，从而产生了V2版本。

为了适应新的需求ISO/IEC和ANSI X9发展了X.509 V3版本证书格式，该版本证书通过增加标准扩展项对V1和V2证书进行了扩展。另外，根据实际需要，各个组织或团体也可以增加自己的私有扩展。

X.509 V1和V2证书所包含的主要内容如下：

* 证书版本号（Version）：版本号指明X.509证书的格式版本，现在的值可以为0、1、2，也为将来的版本进行了预定义。

* 证书序列号（SerialNumber）：序列号指定由CA分配给证书的唯一的数字型标识符。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，这也是序列号唯一的原因。

* 签名算法标识符（Signature）：签名算法标识用来指定由CA签发证书时所使用的签名算法。算法标识符用来指定CA签发证书时所使用的公开密钥算法和hash算法，须向国际知名标准组织（如ISO）注册。

* 签发机构名（Issuer）：此域用来标识签发证书的CA的X.500 DN名字。包括国家、省市、地区、组织机构、单位部门和通用名。

* 有效期（Validity）：指定证书的有效期，包括证书开始生效的日期和时间以及失效的日期和时间。每次使用证书时，需要检查证书是否在有效期内。

* 证书用户名（Subject）：指定证书持有者的X.500唯一名字。包括国家、省市、地区、组织机构、单位部门和通用名，还可包含email地址等个人信息等

* 证书持有者公开密钥信息（subjectPublicKeyInfo）：证书持有者公开密钥信息域包含两个重要信息：证书持有者的公开密钥的值；公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。

* 签发者唯一标识符（Issuer Unique Identifier）：签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串来唯一标识签发者的X.500名字。可选。

* 证书持有者唯一标识符（Subject Unique Identifier）：持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，用一比特字符串来唯一标识证书持有者的X.500名字。可选。

* 签名值（Issuer’s Signature）：证书签发机构对证书上述内容的签名值。

X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。

3.1.2 CRL格式

证书废除列表CRL（Certificate revocation lists，又称证书黑名单）为应用程序和其它系统提供了一种检验证书有效性的方式。任何一个证书废除以后，证书机构CA会通过发布CRL的方式来通知各个相关方。目前，同X.509 V3证书对对应的CRL为X.509 v2 CRL，其所包含的内容格式如下：

* CRL的版本号：0表示X.509 V1 标准；1表示X.509 V2 标准；目前常用的是同X.509 V3证书对应的CRL V2版本。

* 签名算法：包含算法标识和算法参数，用于指定证书签发机构用来对CRL内容进行签名的算法。

* 证书签发机构名：签发机构的DN名，由国家、省市、地区、组织机构、单位部门和通用名等组成。

* 此次签发时间：此次CRL签发时间，遵循ITU-T X.509 V2标准的CA在2049年之前把这个域编码为UTCTime类型，在2050或2050年之后年之前把这个域编码为GeneralizedTime类型。

* 下次签发时间：下次CRL签发时间，遵循ITU-T X.509 V2标准的CA在2049年之前把这个域编码为UTCTime类型，在2050或2050年之后年之前把这个域编码为GeneralizedTime类型。

* 用户公钥信息，其中包括废除的证书序列号和证书废除时间。废除的证书序列号是指要废除的由同一个CA签发的证书的一个唯一标识号，同一机构签发的证书不会有相同的序列号。

* 签名算法：对CRL内容进行签名的签名算法。

* 签名值：证书签发机构对CRL内容的签名值。

另外，CRL中还包含扩展域和条目扩展域。CRL扩展域用于提供与CRL有关的额外信息部份，允许团体和组织定义私有的CRL扩展域来传送他们独有的信息； CRL条目扩展域则提供与CRL条目有关的额外信息部份，允许团体和组织定义私有的CRL条目扩展域来传送他们独有的信息。

3.1.3 证书的存放

数字证书作为一种电子数据格式，可以直接从网上下载，也可以通过其他方式。

* 使用IC卡存放用户证书。即把用户的数字证书写到IC卡中，供用户随身携带。这样用户在所有能够读IC卡证书的电子商务终端上都可以享受安全电子商务服务。

* 用户证书直接存放在磁盘或自己的终端上。户将从CA申请来的证书下载或复制到磁盘或自己的PC机或智能终端上，当用户使用自己的终端享受电子商务服务时，直接从终端读入即可。

另外，CRL一般通过网上下载的方式存储在用户端。

3.2 CA框架模型

证书机构CA用于创建和发布证书，它通常为一个称为安全域（security domain）的有限群体发放证书。创建证书的时候，CA系统首先获取用户的请求信息，其中包括用户公钥（公钥一般由用户端产生，如电子邮件程序或浏览器等），CA将根据用户的请求信息产生证书，并用自己的私钥对证书进行签名。其他用户、应用程序或实体将使用CA的公钥对证书进行验证。如果一个CA系统是可信的，则验证证书的用户可以确信，他所验证的证书中的公钥属于证书所代表的那个实体。

CA 还负责维护和发布证书废除列表CRL（certificate revocation lists，又称为证书黑名单）。当一个证书，特别是其中的公钥因为其他原因无效时（不是因为到期），CRL提供了一种通知用户和其他应用的中心管理方式。CA系统生成CRL以后，要么是放到LDAP服务器中供用户查询或下载，要么是放置在Web服务器的合适位置，以页面超级连接的方式供用户直接查询或下载。

一个典型的CA系统包括安全服务器、注册机构RA、CA服务器、LDAP目录服务器和数据库服务器等。如图2所示。

图2 典型CA框架模型

* 安全服务器：安全服务器面向普通用户，用于提供证书申请、浏览、证书撤消列表以及证书下载等安全服务。安全服务器与用户的的通信采取安全信道方式（如SSL 的方式，不需要对用户进行身份认证）。用户首先得到安全服务器的证书（该证书由CA颁发），然后用户与服务器之间的所有通信，包括用户填写的申请信息以及浏览器生成的公钥均以安全服务器的密钥进行加密传输，只有安全服务器利用自己的私钥解密才能得到明文，这样可以防止其他人通过窃听得到明文。从而保证了证书申请和传输过程中的信息安全性。

* CA服务器：CA服务器使整个证书机构的核心，负责证书的签发。CA首先产生自身的私钥和公钥（密钥长度至少为 1024位），然后生成数字证书，并且将数字证书传输给安全服务器。CA还负责为操作员、安全服务器以及注册机构服务器生成数字证书。安全服务器的数字证书和私钥也需要传输给安全服务器。CA服务器是整个结构中最为重要的部分，存有CA的私钥以及发行证书的脚本文件，出于安全的考虑，应将CA服务器与其他服务器隔离，任何通信采用人工干预的方式，确保认证中心的安全。

* 注册机构RA：登记中心服务器面向登记中心操作员，在CA体系结构中起承上启下的作用，一方面向CA转发安全服务器传输过来的证书申请请求，另一方面向LDAP服务器和安全服务器转发CA颁发的数字证书和证书撤消列表。

* LDAP服务器：LDAP服务器提供目录浏览服务，负责将注册机构服务器传输过来的用户信息以及数字证书加入到服务器上。这样其他用户通过访问LDAP服务器就能够得到其他用户的数字证书。

* 数据库服务器：数据库服务器是认证机构中的核心部分，用于认证机构中数据（如密钥和用户信息等）、日志合统计信息的存储和管理。实际的的数据库系统应采用多种措施，如磁盘阵列、双机备份和多处理器等方式，以维护数据库系统的安全性、稳定性、可伸缩性和高性能。

3.3 证书的申请和撤销

证书的申请有两种方式，一是在线申请，另外一个就是离线申请。在线申请就是通过浏览器或其他应用系统通过在线的方式来申请证书，这种方式一般用于申请普通用户证书或测试证书。离线方式一般通过人工的方式直接到证书机构证书受理点去办理证书申请手续，通过审核后获取证书，这种方式一般用于比较重要的场合，如服务器证书和商家证书等。下面讨论的主要是在线申请方式。

当证书申请时，用户使用浏览器通过Internet访问安全服务器，下载CA的数字证书（又叫做根证书），然后注册机构服务器对用户进行身份审核，认可后便批准用户的证书申请，然后操作员对证书申请表进行数字签名，并将申请及其签名一起提交给CA服务器。

CA 操作员获得注册机构服务器操作员签发的证书申请，发行证书或者拒绝发行证书，然后将证书通过硬拷贝的方式传输给注册机构服务器。注册机构服务器得到用户的证书以后将用户的一些公开信息和证书放到LDAP服务器上提供目录浏览服务，并且通过电子邮件的方式通知用户从安全服务器上下载证书。用户根据邮件的提示到指定的网址下载自己的数字证书，而其他用户可以通过LDAP服务器获得他的公钥数字证书。

证书申请的步骤如下：

1. 用户申请。

用户首先下载CA的证书，又叫根证书，然后在证书的申请过程中使用SSL安全方式与服务器建立连接，用户填写个人信息，浏览器生成私钥和公钥对，将私钥保存客户端特定文件中，并且要求用口令保护私钥，同时将公钥和个人信息提交给安全服务器。安全服务器将用户的申请信息传送给注册机构服务器。

2. 注册机构审核

用户与注册机构人员联系，证明自己的真实身份，或者请求代理人与注册机构联系。 注册机构操作员利用自己的浏览器与注册机构服务器建立SSL安全通信，该服务器需要对操作员进行严格的身份认证，包括操作员的数字证书、IP地址，为了进一步保证安全性，可以设置固定的访问时间。

操作员首先查看目前系统中的申请人员，从列表中找出相应的用户，点击用户名，核对用户信息，并且可以进行适当的修改，如果操作员同意用户申请证书请求，必须对证书申请信息进行数字签名。操作员也有权利拒绝用户的申请。

操作员与服务器之间的所有通信都采用加密和签名，具有安全性、抗否认性，保证了系统的安全性和有效性。

3. CA发行证书

注册机构RA通过硬拷贝的方式向CA传输用户的证书申请与操作员的数字签名，CA操作员查看用户的详细信息，并且验证操作员的数字签名，如果签名验证通过，则同意用户的证书请求，颁发证书。然后CA将证书输出。如果CA操作员发现签名不正确，则拒绝证书申请，

CA 颁发的数字证书中包含关于用户及CA自身的各种信息，如：能唯一标识用户的姓名及其他标识信息，如个人的email地址；证书持有者的公钥。公钥用于为证书持有者加密敏感信息、签发个人证书的认证机构的名称、个人证书的序列号和个人证书的有效期（证书有效起止日期）等

4. 注册机构证书转发

注册机构RA操作员从CA处得到新的证书，首先将证书输出到LDAP目录服务器以提供目录浏览服务，最后操作员向用户发送一封电子邮件，通知用户证书已经发行成功，并且把用户的证书序列号告诉用户到指定的网址去下载自己的数字证书。并且告诉用户如何使用安全服务器上的LDAP配置，让用户修改浏览器的客户端配置文件以便访问LDAP服务器，获得他人的数字证书。

5. 用户证书获取

用户使用证书申请时的浏览器到指定的网址，键入自己的证书序列号，服务器要求用户必须使用申请证书时的浏览器，因为浏览器需要用该证书相应的私钥去验证数字证书。只有保存了相应私钥的浏览器才能成功下载用户的数字证书。

这时用户打开浏览器的安全属性，就可以发现自己已经拥有了CA颁发的数字证书，可以利用该数字证书与其他人以及web服务器（拥有相同CA颁发的证书）使用加密、数字签名进行安全通信。

认证中心还涉及到CRL的管理。用户向特定的操作员（仅负责CRL的管理）发一份加密签名的邮件，申明自己希望撤消证书。操作员打开邮件，填写CRL注册表，并且进行数字签名，提交给CA，CA操作员验证注册机构操作员的数字签名，批准用户撤消证书，并且更新CRL，然后CA将不同格式的CRL输出给注册机构，公布到安全服务器上，这样其他人可以通过访问服务器得到CRL。

证书撤销流程步骤如下：

1. 用户向注册机构操作员CRLManager发送一封签名加密的邮件，声明自己自愿撤消证书。

2. 这册机构同意证书撤消，操作员键入用户的序列号，对请求进行数字签名。

3. CA查询证书撤消请求列表，选出其中的一个，验证操作员的数字签名，如果正确的话，则同意用户的证书撤消申请，同时更新CRL列表，然后将CRL以多种格式输出。

4. 注册机构转发证书撤消列表。操作员导入CRL，以多种不同的格式将CRL公布于众。

5. 用户浏览安全服务器，下载或浏览CRL。

在一个PKI，特别是CA中，信息的存储是一个非常核心的问题，它包括两个方面：一是CA服务器利用数据库来备份当前密钥和归档过期密钥，该数据库需高度安全和机密，其安全等级同CA本身相同；另外一个就是目录服务器，用于分发证书和CRL，一般采用LDAP目录服务器。

3.4 密钥管理

密钥管理也是PKI（主要指CA）中的一个核心问题，主要是指密钥对的安全管理，包括密钥产生、密钥备份、密钥恢复和密钥更新等。

1. 密钥产生

密钥对的产生是证书申请过程中重要的一步，其中产生的私钥由用户保留，公钥和其他信息则交于CA中心进行签名，从而产生证书。根据证书类型和应用的不同，密钥对的产生也有不同的形式和方法。对普通证书和测试证书，一般由浏览器或固定的终端应用来产生，这样产生的密钥强度较小，不适合应用于比较重要的安全网络交易。而对于比较重要的证书，如商家证书和服务器证书等，密钥对一般由专用应用程序或CA中心直接产生，这样产生的密钥强度大，适合于重要的应用场合。

另外，根据密钥的应用不同，也可能会有不同的产生方式。比如签名密钥可能在客户端或RA中心产生，而加密密钥则需要在CA中心直接产生。

2. 密钥备份和恢复

在一个PKI系统中，维护密钥对的备份至关重要，如果没有这种措施，当密钥丢失后，将意味着加密数据的完全丢失，对于一些重要数据，这将是灾难性的。所以，密钥的备份和恢复也是PKI密钥管理中的重要一环。

使用PKI的企业和组织必须恩能够得到确认：即使密钥丢失，受密要加密保护的重要信息也必须能够恢复，并且不能让一个独立的个人完全控制最重要的主密钥，否则将引起严重后果。

企业级的PKI产品至少应该支持用于加密的安全密钥的存储、备份和恢复。密钥一般用口令进行保护，而口令丢失则是管理员最常见的安全疏漏之一。所以，PKI产品应该能够备份密钥，即使口令丢失，它也能够让用户在一定条件下恢复该密钥，并设置新的口令。

例如，在某些情况下用户可能有多对密钥，至少应该有两个密钥：一个用于加密，一个用于签名。签名密要不需要备份，因为用于验证签名的公钥（或公钥证书）广泛发布，即使签名私钥丢失，任何用于相应公要的人都可以对已签名的文档进行验证。但PKI系统必须备份用于加密的密钥对，并允许用户进行恢复，否则，用于解密的私钥丢失将意味着加密数据的完全不可恢复。

另外，使用PKI的企业也应该考虑所使用密钥的生命周期，它包括密钥和证书的有效时间，以及已撤销密钥和证书的维护时间等。

3. 密钥更新

对每一个由CA颁发的证书都会有有效期，密钥对生命周期的长短由签发证书的CA中心来确定，各CA系统的证书有效期限有所不同，一般大约为2-3年。

当用户的私钥被泄漏或证书的有效期快到时，用户应该更新私钥。这时用户可以废除证书，产生新的密钥对，申请新的证书。

3.5 证书的使用

在实际应用中，为了验证信息的数字签名，用户首先必须获取信息发送者的公钥证书，以及一些额外需要的证书（如CA证书等，用于验证发送者证书的有效性）。

证书的获取可以有多种方式，如发送者发送签名信息时附加发送自己的证书，或以另外的单独信息发送证书，或者可以通过访问证书发布的目录服务器来获得，或者直接从证书相关的实体处获得。在一个PKI体系中，可以采取某种或某几种上述方式获得证书。

在电子商务系统中，证书的持有者可以是个人用户、企事业单位、商家、银行等。无论是电子商务中的哪一方，在使用证书验证数据时，都遵循同样的验证流程。一个完整的验证过程有以下几步：

1. 将客户端发来的数据解密 (如解开数字信封)。

2. 将解密后的数据分解成原始数据，签名数据和客户证书三部分。

3. 用CA根证书验证客户证书的签名完整性。

4. 检查客户证书是否有效 (当前时间在证书结构中的所定义的有效期内)。

5. 检查客户证书是否作废 (OCSP方式或CRL方式)。

6. 验证客户证书结构中的证书用途。

7. 客户证书验证原始数据的签名完整性。

如果以上各项均验证通过，则接受该数据。