3.5 公钥基础设施（PKI）

3.5.1 数字证书

数字证书是一段包含用户身份信息、用户公钥信息以及身份验证机构的数字签名的数据。身份验证机构的数字签名可以确保证书信息的真实性。证书格式及证书内容遵循X.509标准。

从证书的用途来看，数字证书可分为签名证书和加密证书。签名证书主要用于对用户信息进行签名，以保证信息的不可否认性；加密证书主要用于对用户传送信息进行加密，以保证信息的真实性和完整性。

数字证书的格式一般遵循国际电信联盟（International Telecommunications Union，ITU）制定的X.509标准，其具体字段及说明如图3.15所示。

1.证书各部分的含义

1）版本号：标识证书的版本（版本1、版本2或是版本3）。

2）证书序列号：由证书颁发者分配的证书唯一标识符。

3）签名算法标识符：由对象标识符加上相关参数而组成，用于说明本证书所用的数字签名算法。

4）颁发者名称：证书颁发者的可识别名称（DN），这是必须说明的。

5）有效期：证书有效的时间段。本段由“不早于”和“不晚于”两项组成。

6）主体名称：证书拥有者的可识别名称。此字段必须是非空的，除非使用了其他的名字形式。

7）主体公钥信息：主体的公钥（以及算法标识符），这是必须说明的。

8）颁发者唯一标识符：证书颁发者的唯一标识符，仅在版本2和版本3中要求，属于可选项；该字段在实际应用中很少使用，并且不被RFC 2459推荐使用。

9）主体唯一标识符：证书拥有者的唯一标识符，仅在版本2和版本3中要求，属于可选项；该字段在实际应用中很少使用，并且不被RFC 2459推荐使用。

10）扩展项：可选的标准和专用扩展（仅在版本3中使用）。

2.标准的版本3证书扩展项

在版本2之后，证书协议子集显然仍然还有不足之处，于是提出了一系列扩展项附加在版本3格式证书的后面。这些扩展项包括密钥和策略信息、主体和颁发者属性以及证书路径限制等。内容如下。

1）机构密钥标识符：用来验证证书密钥的唯一标识符，以区分同一个证书颁发者的多对密钥。RFC 2459中要求除自签名（Self-signed）的证书以外的所有证书都要包含此字段。

2）主体密钥标识符：证书所含密钥的唯一标识符，用来区分同一个证书拥有者的多对密钥。RFC 2459中要求认证中心（CA）的证书包含此字段，推荐终端实体的证书也包含此字段。

3）密钥用途：一个比特串，指明（限定）利用证书中的公钥可完成的各项功能或服务，如数字签名、密钥加密、数据加密、密钥协商等。一个典型的属性描述表描述了各种允许的组合。

4）扩展密钥用途：由一个或多个对象标识符（OIDs）组成，用以说明证书中密钥的特别用途。尽管在X.509中没有明确定义这一用途的标识符，RFC 2459中还是规定了几个扩展密钥使用的对象标识符，包括传输层安全服务器确认、安全电子邮件等。

5）证书撤销列表（CRL）分布点：指明CRL的分布地点。

6）私钥使用期：指明与证书中的公钥相对应的私钥的使用期限，用于数字签名和证书。就像证书有效期一样，私钥使用期也用“不早于”和“不晚于”两项来限定使用的时间。当此项扩展不在时，公私钥的有效期是一样的。在私钥的终止期到来之前必须颁发一对新的密钥。

7）证书策略：说明一系列与证书颁发和使用有关的策略对象标识符和可选的限定符。有了这项扩展，在实际应用中就必须遵照声明的策略，否则证书就不能使用。

8）策略映射：表明在两个CA域之间的一个或多个策略对象标识符的等价映射关系，仅在CA证书里存在。

9）主体别名：指出证书拥有者的别名（例如，电子邮件地址、IP地址、URL等）。此项如果存在的话，可以认为别名是和主体的DN绑定在一起的。

10）颁发者别名：指出证书颁发者的别名（例如，电子邮件地址、IP地址、URL等）。RFC 2459中详细规定了和主体别名扩展一样的处理规则，除了颁发者的DN必须在颁发者字段出现以外。

11）主体目录属性：指出证书拥有者的一系列属性，一些著名的应用却使用了这一扩展来传递访问控制信息。

12）基本限制：该扩展项表明一个主体是否可以充当证书颁发机构。它提供了一种限制最终用户充当证书颁发机构的方式。

13）名称限制：该扩展项仅仅在CA证书中使用，用于指明一个名字空间，使得分配给证书路径中任何后继证书的主体的名称都在这一名字空间中。

14）策略限制：该扩展项仅仅在CA证书中使用，用于通过请求策略标识符或者禁止策略映射（或者两者都有）来指定策略路径验证。

X.509 v3证书的基本语法如下所示，为签名计算，将证书按照ASN.1语法（DER）规则进行编码传递。DER编码是对每个元素对应的标签、长度、值编码的系统。

3.5.2 PKI的基本组成与功能

公钥基础设施（Public Key Infrastructure，PKI）是网络安全的基础。其原理是利用公钥技术所构建的，用来解决网络安全问题的一种普遍适用的基础设施。也有学者把提供全面安全服务的基础设施，包括软件、硬件、人员和策略的集合称为PKI。PKI在网络信息空间的地位相当于电力基础设施在工业中的地位。可以说PKI是目前电子商务和电子政务必不可少的安全基础。

PKI体系结构采用证书管理公钥，通过第三方的可信机构认证中心（Certificate Authority，CA），把用户的公钥和用户的其他标识信息（如名称、电子邮件地址、身份证号等）捆绑在一起，在互联网上验证用户的身份。PKI体系结构把公钥密码和对称密码结合起来，在互联网上实现密钥的自动管理。其主要目的是通过自动管理密钥和证书，为用户建立起一个安全的网络运行环境，使用户可以在多种应用环境下方便地使用加密和数字签名技术，从而保证网上数据的机密性、完整性和不可抵赖性。

作为网络环境的一种基础设施，PKI必须具有良好的性能。通常对PKI的性能要求如下。

1）透明性和易用性：这是最基本的要求，PKI必须尽可能地向上层应用屏蔽密码服务的实现细节，向用户屏蔽复杂的安全解决方案，使密码服务对用户而言简单易用，同时便于各类组织（如企业）完全控制其信息资源。

2）可扩展性：证书库和CRL必须具有良好的可扩展性。

3）互操作性：不同组织的PKI实现方法可能是不同的，这就提出了互操作性要求。要保证PKI的互操作性，必须将PKI建立在标准之上，这些标准包括加密标准、数字签名标准、Hash标准、密钥管理标准、证书格式、目录标准、文件信封格式、安全会话格式、安全应用程序接口规范等。

4）支持多应用：PKI应该面向广泛的网络应用，提供文件传送安全、文件存储安全、电子邮件安全、电子表单安全、Web应用安全等保护。

5）支持多平台：PKI应该支持目前广泛使用的操作系统平台，包括Windows、UNIX、macOS等。

PKI是一种遵循标准的密钥管理平台，涉及多个实体之间的协作过程，它们包括认证中心（CA）、注册机构（Registration Authority，RA）、证书数据库（Certificate Database）、密钥管理系统（Key Manage System）、证书撤销管理系统（Certificate Revocation List Manage System）、PKI应用接口系统（PKI Application Interface System）及最终用户。PKI各构成部件之间的交互作用如图3.16所示。

1.认证中心

证书是一种权威性的电子文档，如同网络计算环境中的一种身份证，用于证明某一主体（如人、服务器等）的身份以及其公开密钥的合法性。在公钥密码体制环境中，必须有一个可信的机构来对所有主体的公钥进行验证，证明主体的身份以及它与公钥的匹配关系。认证中心（CA）正是这样的机构，它是证书的签发机构，是PKI系统的核心。

CA的证书处理流程如图3.17所示。

CA的功能主要有以下几项。

（1）接受证书请求

接受证书请求，检查其合法性，审核用户的证书申请。这部分工作一般由RA来完成，它可以是独立的部门，也可以看作CA的一部分。

（2）证书签发、审核、制作

它以数据库（PKICADB）为核心按照既定的业务流程到数据库中查找待签发用户信息，向证书签发服务器发送证书签发消息。

（3）证书发布

证书的发布是指将证书保存到LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议）目录服务器上。证书管理协议主要基于LDAP API技术，LDAP API支持LDAP证书读、搜索，证书或证书撤销列表的增加、删除，以及目录服务器中的信息修改。

CA证书系统的证书库构造采用支持LDAP协议的目录系统，CA将已经生成但未发布的数字证书一次性地向目录服务器发布。用户或相关的应用通过LDAP来访问证书库。

（4）证书的归档及撤销

CA所发证书要定期归档，以备查询。除用于用户的签名密钥外，对证书的所有数据信息，都要进行归档处理。

CA使用符合LDAP X.500标准的目录服务器系统存储证书和证书的撤销列表。目录和数据库备份，可以根据组织机构的安全策略执行归档，最长时间可达7年保存期。数据库还保存审计和安全记录。对于用户密钥对，CA通过专用程序自动存储和管理密钥历史及密钥备份。

在证书的有效期内，由于私钥丢失、泄密等原因，必须废除证书时，证书持有者要提出证书废除申请。注册管理中心一旦收到证书撤销请求，就可以立即执行证书撤销，并同时通知用户，使其知道特定证书已被撤销。CA提供了一套成熟、易用和基于标准的证书撤销系统，目前主要采用的方案有CRL及在线证书状态查询协议（OCSP）。从安全角度来说，每次使用证书时，系统都要检查证书是否已被撤销。为了保证执行这种检查，证书撤销是自动进行的，而且对用户是透明的。这种自动透明的检查是针对企业证书进行的，个人证书则要人工查询。

（5）证书的更新

证书都具有一定的有效期，这种有效期是由证书的安全策略或证书运作规范（CPS）所规定的。当证书“接近”过期时，就必须颁发一个新的公/私密钥和相关证书，这也被称为密钥更新。

所谓“接近”过期，一般是指在证书到达有效期之前的时间“提前量”，这个提前量，通常规定为整个密钥生存期的20%左右，即一旦密钥生存周期被用到80%时，密钥更新就应发生。然后，新的密钥资料应该被用到随后所有的密码操作中。实践证明，这是一个合理的转变时间，可以防止因证书过期而得不到安全的服务。

因为扩展性的要求，这个过程必须是自动的，对终端用户而言，也应该是透明的。

（6）密钥的备份与恢复

PKI中一个很重要的内容就是密钥的备份与恢复。密钥的备份与恢复分为CA自身密钥（包括CA根密钥和运营CA的密钥）与用户密钥的备份与恢复。

1）CA根密钥的备份与恢复。根密钥是由根密钥加密机（硬件加密模块）产生的，因此密钥备份由加密机系统管理员启动加密机管理程序来执行，它将根密钥分割成多块，为每一块生成一个随机口令，使用该口令加密对应的密钥块。然后将加密后的私钥块分别写入不同的IC卡中，每一个口令以一个文件形式保存，每人只能保存一块。恢复密钥时，必须由各密钥备份持有人员分别插入各自保管的IC卡，并输入相应口令才能恢复根密钥。

2）运营CA的密钥的备份和恢复。运营CA直接为各种用户实体签发证书，其密钥备份非常重要。一般由加密机系统管理员启动加密机管理程序来执行。它将运营CA密钥切分成多块，为每一块生成一个随机口令，使用该口令加密对应的密钥块。然后将加密的私钥块分别写入不同的IC卡中，每个口令以一个文件形式保存，最后将每个IC卡及其对应的口令文件交给备份人员保存，每人只能保存一块。当需要密钥恢复时，其做法与根密钥恢复时的做法相同。

3）用户密钥的备份与恢复。在CA签发用户证书时，即可进行用户密钥的备份。一般是将用户密钥存放在CA的资料库中。

若由于用户密钥丢失或其他原因，用户不愿意撤销原密钥，希望能对原密钥进行恢复，就可以根据密钥历史存档进行恢复。在完成这个恢复过程之后，相应的软件将产生一个新的签名密钥对来代替旧的签名密钥对。

密钥的备份与恢复也可考虑用门限秘密共享体制来实现。

（7）交叉认证

属于不同CA的用户之间要检查对方证书的合法性时，需要交叉认证，交叉认证扩展了第三方认证的范围。

2.注册机构

尽管可以将注册机构（RA）看作PKI的一个扩展部分，但是管理员却渐渐发现它是必不可少的。随着一个PKI区域的最终实体数量的增加，施加在一个CA上的负载也会随之增加。而RA可以充当CA和它的最终用户之间的中间实体，辅助CA来完成它的证书生成功能，并且可以将CA从不安全的环境中分离出去。

RA子系统包括RA端的初始化、操作员管理、证书和证书撤销列表申请录入、证书和证书撤销列表申请审核、证书和证书撤销列表申请上传、证书下载和制卡、数据库备份管理、日志管理和报表统计。系统应自动记录系统内发生的每一事件，包括系统自动执行的和管理操作执行的事件，如图3.18所示。

3.证书目录

证书生成后，必须存储以备以后使用。为了减少最终用户将证书存储于本地机器的需要，CA通常使用一个证书目录，或者中央存储点。作为PKI的一个重要的组成部分，证书目录提供证书管理和分发的单一点。

X.500目录正被广泛接受，因为它除了可以充当证书库之外，还可以给予管理员一个个人属性信息入口的集中点。通过使用目录访问协议，如轻量级目录访问协议（LDAP），目录客户端可以定位条目项以及它们的属性。

4.客户端系统

客户端软件（有的称其为证书的客户端代理）运行在用户的机器上。一方面，在申请双证书时帮助用户生成签名密钥对；另一方面，它负责本地证书的管理，帮助用户对证书进行导入、导出，以便完成证书在电子商务应用系统中的认证作用。它以客户端的身份与RA通信，进行证书的申请与下载。该软件也可以插件的形式与浏览器集成在一起，帮助完成在线交易。

客户端软件的功能如下。

1）查询证书和相关的撤销信息。

2）在一定时刻为文档请求时间戳。

3）作为安全通信的接收点。

4）进行传输加密或数字签名操作。

5）能理解策略，知道是何时和怎样去执行取消操作。

6）证书路径处理等。

没有客户端软件，PKI就无法有效地提供很多服务。客户端软件应当独立于所有应用程序之外，去完成PKI服务的上述客户端功能。应用程序应通过标准接入点与客户端软件连接，客户端软件作为PKI，供应用程序使用。

5.密钥管理及其要求

密钥管理是一门综合性的技术，涉及密钥的产生、检验、分配、传递、保管、使用、销毁的全过程。

一般来说，一个好的密钥管理系统应满足以下三点要求。

1）密钥难以被非法窃取。

2）在一定条件下即使窃取了密钥也没有用。

3）密钥的分配和更换过程对用户而言是透明的。

CA中心不在其任何设备上保存用户的私有密钥。如果需要托管密钥，则密钥的托管由密钥管理中心负责。

密钥管理中心不备份用户私有的签名密钥，用户应备份他们的私有签名密钥，并确保这些密钥的安全；密钥管理中心可备份用户要求托管的私有加密密钥及一些相关信息，并确保密钥得到安全的保护。

6.证书状态查询方案

（1）离线证书状态查询方案

离线证书状态查询方案通过一个经过签名的证书撤销列表来发布认证数据。服务器可以通过“推”（push）或“拉”（pull）的方式将此撤销列表发送给无线用户（如果用户向服务器提出查询证书状态的请求，就用“拉”的方式；如果用户没有提出查询证书状态的请求，服务器可以使用“推”的方式将数据传送给用户）。通过证书撤销列表的方式，用户就能拥有所有的撤销数据。在数据有效期内及没有在线传输要求的情况下，这些数据常被缓存起来。这种方案最简单的实现例子就是传统的证书撤销列表（Traditional-Certificate Revocation List）方案。

（2）在线证书状态查询机制

在线证书状态查询机制是基于在线证书状态协议（On-line Certificate Status Protocol，OCSP）的一种在线的证书撤销信息获得方式。OCSP是一种请求/响应协议，它提供了一种从名称为OCSP响应器（可信第三方）获得在线证书状态信息的手段。

OCSP请求由版本号、服务请求类型以及证书标识符组成，其中，证书标识符包括证书颁发者可识别名的Hash值、颁发者公钥Hash值、证书序列号以及扩展；OCSP响应包括证书标识符和证书状态（即“正常”“撤销”“未知”），若证书状态是“撤销”，还应包括撤销的具体时间和撤销原因。OCSP的可信性和在传输过程中的安全性是由OCSP响应器（可信第三方）的数字签名来保证的。

OCSP的优点在于它本身不存在延迟，但它有一定的局限性。第一，OCSP的响应必须由响应器进行数字签名。一个加密的签名响应，对响应产生的周期时间的影响是非常大的，因此使得系统可能拒绝大量查询的请求。但是没有签名的响应将使攻击者有机可乘，可能送给客户一个伪装的错误响应。第二，必须保证用户与OCSP响应器之间的在线通信，这会造成较高的通信成本，还会引起通信瓶颈。第三，OCSP只是一个协议，它没有用来搜集撤销信息的后端结构，它仍然需要通过CRL或其他方法搜集证书撤销信息，因此，OCSP响应器提供的信息实时性将取决于获得这些信息的来源的延迟。所以，认为OCSP能自动更新信息以提供实时服务是不恰当的。第四，由于OCSP的可信性和在传输过程中的安全性是由OCSP响应器的数字签名来保证的，因而一旦签名秘密泄露，OCSP就毫无安全性可言。

（3）证书状态信息的发布模式

如何为PKI系统的证书状态信息的发布机制选择一种最佳的模式，要考虑大量的因素。除了客户的校验率和CRL的有效期外，还有一个必须考虑的因素是吊销证书可能的数量和PKI系统的运行环境。

1）客户的校验率很低或者系统要求较低的信息延迟。如果系统要求较低的证书状态信息的延迟，以提高系统的安全性，就需要减少CRL的有效期，以缩短客户请求吊销证书到该信息发布给所有客户的时间。如果CRL的有效期很短，将造成客户每执行一次或很少几次校验都必须从资料库中获得最新的作废信息。如果客户的校验证书的需求率很低，也会产生这种情况。在CRL发布信息的几种模式中，峰值请求率的降低都依赖于缓存信息的再次使用。当Cache中缓存的CRL的信息不可用或很少用到时，这几种技术没有一种能够很有效地降低峰值请求率。这种情况下较好的解决方案是将CRL分段，以缩短服务一次请求要求的时间。也可以考虑采用在线发布的方式，使系统获得实时的响应，但遗憾的是这种方式不适用于大规模的PKI系统。如果希望缩短系统的响应时间，同时又能在一定程度上降低峰值请求率，可考虑采用Delta-CRL方式。通过Delta-CRL较短的生命期获得较好的系统响应，而将CRL分成基本CRL和增量CRL来降低峰值请求率。

2）可能被吊销的证书数目很少。如果CRL的有效期相对较长，可以使得缓存的CRL信息生效，那么证书作废信息的最佳发布方式将依赖于可能的作废证书的数目。如果能预期到只可能有很少的证书会被吊销，那么分段发布CRL的模式对CRL的大小就没有什么效果。在这种情况下，最好的方法是采用分时但不分段发布CRL的模式，以降低峰值请求率。

3）可能被吊销的证书数目很多。如果可能有大量的作废信息需要发布，那么减少CRL的数量就比降低峰值请求率更重要。这种情况下必须使用分段发布CRL的模式。如果CRL需要被分成较多的段，就不需要分时发布CRL的分段了，因为这时分时发布技术已不能充分地降低峰值请求率，反而会增加额外的系统开销。

4）在离线环境下的客户操作。这种情况下分段将毫无用处，因为离线操作的客户在从资料库中获取CRL信息时，并不知道哪个证书将被校验。如果CRL被分段，那客户就需要获得所有分段的CRL。此时，分时发布CRL的方案却十分有效。如果CRL采用分时发布，每次客户请求CRL时，可以确保总是获得相对更新的信息。反之若不采用分时发布，某些请求获得证书状态信息的客户可能会得到过期的CRL，这样的CRL将被抛弃。

3.5.3 常用信任模型及信任路径

选择信任模型（Trust Model）是构筑和运作PKI所必需的一个环节。选择正确的信任模型以及与它相对应的安全级别是非常重要的，同时也是部署PKI所要做的较早和基本的决策之一。

在X.509规范中给出了信任的定义：如果实体A认定实体B严格地按A所期望的那样行动，则A信任B。从这个定义可以看出，信任涉及假设、期望和行为，这意味着信任是不可能被定量测量的，信任是与风险相联系的并且信任的建立不可能总是全自动的。在PKI中，可以把这个定义具体化为：如果一个用户认为CA可以把任一公钥绑定到某个实体上，则他信任该CA。

1.常用信任模型

常用的信任模型有四种：

① 认证机构的严格层次结构模型（Strict Hierarchy of Certification Authorities Model）；

② 分布式信任结构模型（Distributed Trust Architecture Model）；

③ Web模型（Web Model）；

④ 以用户为中心的信任模型（User Centric Trust Model）。

（1）认证机构的严格层次结构模型

认证机构的严格层次结构模型是最早的PKI信任模型，可以用一棵倒转的树来描述它。在该模型中，整个领域中的信任点是根CA （Root CA）。在根CA的下面是零层或多层中介CA（Intermediate CA），也被称作子CA。根CA认证直接连接它下面的子CA。每个CA都认证零个或多个直接连接在它下面的子CA。

CA对非CA实体的认证有两种方式：一种是上层的CA既可以认证其他CA也可以认证终端实体；另一种是CA要么认证终端实体，要么认证其他CA，但不能两者都认证。

（2）分布式信任结构模型

与PKI系统中所有实体都信任唯一一个CA的严格层次结构相反，分布式信任结构把信任分散在两个或多个CA上，即整个PKI系统由若干个子集构成，而每个子集都是一个严格层次结构。也就是说，A把CA1作为信任的根，而B可以把CA2作为信任的根。这些CA必须是整个PKI系统的一个子集所构成的严格层次结构的根CA（CA1是包括A在内的严格层次结构的根，CA2是包括B在内的严格层次结构的根）。两个根CA之间可以通过交叉认证（Cross Certification）机制实现相互之间的信任。

（3）Web模型

Web模型是在万维网上诞生的，而且依赖于流行的浏览器，如Microsoft公司的Internet Explorer。在这种模型中，许多CA的公钥被预装在标准的浏览器上。这些公钥确定了一组浏览器用户最初信任的CA。尽管这组公钥可以被用户修改，然而大多数普通用户对于PKI和安全问题尚未精通到可以进行这种修改的程度。这也是这种模型存在的安全缺陷之一。

Web模型在方便性和简单互操作性方面有明显的优势，但是也存在许多安全隐患。例如，因为浏览器用户自动地信任预安装的所有公钥，所以他们一般不知道收到的证书是由哪一个根密钥签发的，即使这些根CA中只有一个是“坏的”（例如，该CA从没有认真核实被认证的实体），安全性也都将被完全破坏；另外一个潜在的安全隐患是没有实用的机制来撤销嵌入浏览器中的CA。如果发现一个CA的公钥是“坏的”，要使全世界数百万个浏览器自动地废止该密钥的使用是非常困难的；而且该模型还缺少有效的方法在CA和用户之间建立合法协议，该协议的目的是使CA和用户共同承担责任。

（4）以用户为中心的信任模型

在以用户为中心的信任模型中，每个用户可以自己决定信任哪些证书。因为要依赖用户自身的行为和决策能力，所以以用户为中心的模型在技术水平较高和利害关系高度一致的群体中是可行的，但是在一般的群体（它的许多用户极少有或者没有安全及PKI的概念）中是不现实的。而且，这种模型一般不适合用在贸易、金融或政府环境中，因为在这些环境中，通常希望或需要对用户的信任实行某种控制，显然这种情况下的安全策略在以用户为中心的模型中是不可能实现的。

所谓信任路径，就是指当一个实体认证另一个实体时，构成两者之间信任链的证书的集合。以最简单的严格层次结构信任模型为例（见图3.19），U为根CA，由于根认证中心U的证书对于Alice和Bob来说是预装的，即对Alice来讲可以直接信任U，当Alice和Bob的发证中心不同时（Alice的证书由X颁发，而Bob的证书由Z颁发），则Alice可由以下证书链实现对Bob的认证。

U＜＜V>>V＜＜Y>>Y＜＜Z>>Z＜＜B>>

其中，U＜＜V>>表示V的证书由U来颁发，所以V可以得到U的公钥，从而认证U。在得到信任路径后，就要取回信任路径上的所有证书进行完整性验证。

由以上内容可以看出，构建信任路径由两个过程组成：

① 从目录服务器中获取证书并且构建证书路径；

② 验证每个证书的完整性及其相关的策略是否正确。

2.构建信任路径的几种方法

（1）证书链

这种方法被商业CA和大多数SSL所采用，还有S/MIME也是采用这种认证方式的。证书链由一系列从根CA到用户的证书所组成。为了能够认证不同信任域内的用户证书，客户端要保存所有需要的自签根证书，还要有能够验证其他域CA自签证书所用到的签名算法。大多数情况下，可以通过目录服务器来访问分布式的数据库，或用S/MIME电子邮件消息来发布和得到证书链。还有一种是将证书链的构建过程放到发证和制作数字信封当中，这样做可以使客户端变得十分简单而且易于实现，因为剩下的工作只是做签名验证。但是，在大规模的分布式环境中，维护和管理本地每一个用户的数个根CA证书链，而且还要实施密钥保护和维持证书安全策略是很困难的。用户必须经常地从系统管理员那里更新自签证书，一旦用户没有得到正确及时的更新信息，使用了不可信任的根证书所带来的风险就是难以估量的。

（2）路径图

这种实施方法是指客户端程序通过检查并存储用户信任域所有的层次关系，产生一幅节点路径图，节点代表CA和用户，弧代表证书。根据某种算法，可以合并包含节点的新的路径图和原有的路径图，来产生更新的路径图。对于每一个新插入路径图的节点都要进行完整性校验，在整个路径构建完毕后，就可以进行路径验证了。

在这种方法下可能会有多重路径，所以要有相应的算法来决定最短路径。如果最短路径无效，那么就要对次短路径进行检测，从最短路径到最长路径的序列中找到可以通过验证的最短路径。层次路径图是一种通用的、适应性强的确定证书信任路径的方法，它独立于证书策略所决定的层次结构的形式。另外，如果在层次结构中只有一个自签的证书，那么路径图这种方法对于直接对用户进行欺骗攻击的抵御性是很强的。当然，本地层次结构中的CA也可以通过交叉认证来与其他的PKI信任域中的节点建立信任。但是，当信任域增加时，由于路径图的复杂性也大大增强，证书的获得、路径图的查找、最短路径的选择的复杂性将会大大增强。当许多拥有大量节点的路径图直接或间接地相连时，客户端会将所有的证书取回本地，这样客户端实施路径图的计算量将会比真正执行其主要功能的运算量还要大。一种解决方案是将经常用到的信任域的证书存储到本地的缓存当中，但是，维护和管理缓存也会降低客户端的运行效率。另外一种可选的方法是将缓存和PKI信息服务器相结合，以保证客户端证书信息的更新。这种方法的缺点是：在系统出现意外事故或受到拒绝服务攻击时，会使得客户端无法连接到PKI信息服务器，从而损害所有用户之间信任的建立。

（3）证书路径验证服务

用一个专用的DCS（Data Certification Server）服务器来处理证书信任路径的构建和验证，并提供证书的更新信息。为了认证一个PKI用户，客户端将一个认证请求连同自己的证书发送给DCS，DCS负责从目录服务器获取所有需要的证书，构建证书信任路径并加以验证，将结果发送回用户，如图3.20所示。在这种情况下，客户端是极其简单的，因为它不需要构建证书路径，也不需要验证证书。但从另一方面看，整个系统的安全性依赖于一个服务器，如果该服务器受到拒绝服务攻击或者欺骗攻击，所有的用户和实体都将受到损害，所以要实施DCS，就必须要使用附加的强大的安全手段来保护服务器，另外，要实施DCS就肯定需要一个高性能的服务器，这样无疑增加了系统成本。

（4）目录服务器路径构建

由目录服务器来进行路径的构建，在接收到请求之后，目录服务器负责构建证书路径，并将路径上的所有证书都发回给客户端，客户端负责对证书路径进行验证，如图3.21所示。因为验证操作是在客户端完成的，所以对于目录服务器自身的安全性没有什么损害。在大规模分布式环境下，在目录服务器上实施这样的操作，将会给目录服务器造成极大的负担，从而影响目录服务器的主要功能—提供对分布式存储的访问。另外，要想在目录服务器中实现这项功能，就必须对已有的目录服务器的协议进行修改，这势必会对其开放性和互操作性造成影响。