1.3. 证书和身份验证

1.3.1. 证书标识某些人或信息

证书是一个电子文件，用于识别个人、服务器、公司或其他实体并将该身份与公钥关联。比如某个驱动程序的许可或论坛，证书可提供个人身份的可识别验证。公钥加密使用证书来解决身份模拟问题。

要获得个人 ID，如驱动程序的许可证，用户必须提供一些其他身份证明，以确认个人是谁是谁。证书的工作方式与相同。证书颁发机构(CA)验证身份和发布证书。CA 可以是独立的第三方，也可以是运行自己的证书的组织，如证书系统。用于验证身份的方法因所请求的证书类型的给定 CA 策略而异。在发布证书前，CA 必须使用标准验证过程确认用户身份。

CA 发布的证书将特定公钥绑定到证书标识的实体名称，如员工或服务器的名称。证书有助于防止使用假的公钥模拟。只有证书认证的公钥将与证书标识的实体拥有的对应私钥一起使用。

除了公钥外，证书始终包括它标识的实体的名称、到期日期、签发证书的 CA 的名称以及序列号。最重要的是，证书总是包括发布 CA 的数字签名。CA 的数字签名允许证书充当知道和信任 CA 的用户的有效凭证，但不知道证书标识的实体。

有关 CA 角色的更多信息，请参阅第 1.3.6 节 “CA 证书如何建立信任”。

1.3.2. 身份验证确认身份

身份验证 是确认身份的过程。对于网络交互，身份验证涉及由另一方识别方。可以通过多种方式通过网络使用身份验证。证书是这些方法之一。

网络交互通常在客户端（如 Web 浏览器和服务器）之间发生。客户端身份验证 指的是服务器的标识（假定使用软件的人）。服务器身份验证 指的是客户端的识别服务器（假定在网络地址中运行服务器）。

客户端和服务器身份验证不是证书支持的唯一验证形式。例如，电子邮件消息上的数字签名与标识发送者的证书相结合，可以验证邮件的发送者。同样，HTML 表单上的数字签名与标识签名者的证书相结合，可以提供由该证书标识给表单内容的人员的证据。除了身份验证之外，两个情况下的数字签名还确保了一定程度的非缓解；数字签名使签名者难以在以后不会发送电子邮件或表单。

客户端身份验证是大多数 Inets 或 extranets 中网络安全性的基本元素。客户端身份验证有两种形式：

基于密码的身份验证

几乎所有服务器软件都允许通过在授予服务器访问权限之前要求识别的名称和密码进行客户端身份验证。

基于证书的验证

基于证书的客户端身份验证是 SSL/TLS 协议的一部分。客户端以数字方式签署随机生成的数据，并通过网络发送证书和签名数据。服务器验证签名并确认证书的有效性。

=== 基于密码的身份验证

图 1.4 “使用密码验证客户端到服务器” 显示使用用户名和密码验证用户的过程。这个示例假设如下：

用户已经信任服务器，无需身份验证，或基于 SSL/TLS 服务器身份验证。
用户请求由服务器控制的资源。
服务器需要客户端身份验证，然后允许访问所请求的资源。

图 1.4. 使用密码验证客户端到服务器

以下是此身份验证过程中的步骤：

当服务器从客户端请求身份验证时，客户端会显示一个对话框，请求该服务器的用户名和密码。
客户端在网络上发送名称和密码，可以是纯文本或加密的 SSL/TLS 连接。
服务器在其本地密码数据库中查找名称和密码，如果匹配，则接受它们作为验证用户身份的证据。
服务器决定识别的用户是否允许访问所请求的资源，如果允许客户端访问它。

通过此安排，用户必须为访问的每个服务器提供新密码，并且管理员必须跟踪每个用户的名称和密码。

1.3.2.1. 基于证书的验证

基于证书的身份验证的一个优点是，它可用于用一种机制替换身份验证中的前三个步骤，允许用户提供一个密码（不通过网络发送），并允许管理员集中控制用户身份验证。这称为 单点登录。

图 1.5 “使用证书向服务器验证客户端” 显示客户端身份验证如何使用证书和 SSL/TLS 工作。为了验证用户到服务器，客户端以数字方式签署随机生成的数据，并通过网络发送证书和签名数据。服务器根据证书和签名数据中的数据验证用户身份。

与图 1.4 “使用密码验证客户端到服务器” 一样，图 1.5 “使用证书向服务器验证客户端” 假设用户已信任服务器并请求一个资源，且服务器在授予对所请求资源的访问权限前已请求客户端身份验证。

图 1.5. 使用证书向服务器验证客户端

与图 1.4 “使用密码验证客户端到服务器” 中的身份验证过程不同，图 1.5 “使用证书向服务器验证客户端” 中的身份验证过程需要 SSL/TLS。图 1.5 “使用证书向服务器验证客户端” 另外，也假设客户端具有有效的证书，可用于识别客户端到服务器。基于证书的验证是首选基于密码的身份验证，因为它基于具有私钥和知道密码的用户。但是，只有在未授权人员没有获得用户机器或密码的访问权限时，才会满足这两个假设，客户端软件的私钥数据库的密码已被设置，软件会被设置为以合理的间隔请求密码。

注意

无基于密码的身份验证或基于证书的身份验证地址与对各个机器或密码的物理访问相关的安全问题。公钥加密只能验证用于签署某些数据的私钥是否与证书中的公钥对应。用户负责保护机器的物理安全性，并保持私钥密码 secret。

以下是图 1.5 “使用证书向服务器验证客户端” 中显示的身份验证步骤：

客户端软件维护一个私钥数据库，该密钥对应于为该客户端发布的任何证书中的公钥。客户端在第一次在给定会话中需要访问这个数据库时（如首次尝试访问启用了证书的 SSL/TLS 服务器时），客户端会要求提供密码。
输入此密码后，用户不需要为其余会话再次输入它，即使访问其他启用了 SSL/TLS 的服务器也是如此。
客户端解锁私钥数据库，检索用户证书的私钥，并使用该私钥为客户端和服务器输入随机生成的数据签名。此数据和数字签名的证据表明私钥的有效性。数字签名只能使用该私钥创建，并可以根据签名数据使用对应的公钥进行验证，这对 SSL/TLS 会话是唯一的。
客户端在网络上发送用户的证书和随机生成的数据。
服务器使用证书和签名数据来验证用户身份。
服务器可以执行其他身份验证任务，如检查是否由客户端提供的证书存储在 LDAP 目录中的用户条目中。然后，服务器会评估识别的用户是否允许访问所请求的资源。此评估过程可以使用各种标准授权机制，可能在 LDAP 目录或公司数据库中使用其他信息。如果评估的结果是正数，服务器则允许客户端访问请求的资源。

证书替换客户端和服务器间交互的身份验证部分。单点登录不必要求用户不断在网络中发送密码，而是要求用户输入一次私钥数据库密码，而无需通过网络发送密码。对于会话的其余部分，客户端提供用户的证书，以向它遇到的每个新服务器验证用户。基于经过身份验证的用户身份的现有授权机制不会受到影响。

1.3.3. 用于证书

证书的目的是建立信任。其使用量因它们用来确保的信任类型而异。某些类型的证书用于验证 presenter 的身份；另一些的证书用于验证对象或项目是否已被篡改。

1.3.3.1. SSL/TLS

传输层安全性/安全套接字层(SSL/TLS)协议管理服务器和客户端之间的服务器身份验证、客户端身份验证和加密通信。SSL/TLS 在互联网上广泛使用，特别是涉及交换机密信息的交互，如信用卡号码。

SSL/TLS 需要 SSL/TLS 服务器证书。作为初始 SSL/TLS 握手的一部分，服务器向客户端提供其证书以验证服务器的身份。身份验证使用公钥加密和数字签名来确认服务器是它声明为的服务器。服务器经过身份验证后，客户端和服务器使用对称密钥加密（非常快），加密会话剩余部分交换的所有信息，并检测任何篡改。

服务器可以配置为需要客户端身份验证以及服务器身份验证。在这种情况下，在服务器身份验证成功完成后，客户端还必须向服务器提供其证书，以便在建立加密的 SSL/TLS 会话前验证客户端的身份。

有关通过 SSL/TLS 客户端验证概述及其与基于密码的身份验证的不同，请参阅第 1.3.2 节 “身份验证确认身份”。

1.3.3.2. 已签名并加密的电子邮件

有些电子邮件程序支持使用广泛接受的协议（称为安全多用途互联网邮件扩展(S/MIME)）进行数字签名和加密的电子邮件。使用 S/MIME 签名或加密电子邮件消息，要求消息的发件人具有 S/MIME 证书。

包含数字签名的电子邮件消息提供了一些保证，它是由在邮件标头中显示的名称的人员发送的，从而对发送者进行身份验证。如果电子邮件软件无法验证数字签名，则会警告用户。

数字签名对它所对应的消息是唯一的。如果收到的消息因发送的消息的任何方式不同，即使添加或删除单个字符，也无法验证数字签名。因此，签名的电子邮件还提供保证电子邮件没有被篡改。这种保证称为非缓解，这使得发件人难以拒绝发送邮件。这对业务通信非常重要。有关数字签名工作方式的详情，请参考第 1.2 节 “数字签名”。

s/MIME 还可以加密电子邮件消息，这对于某些业务用户来说非常重要。但是，对电子邮件使用加密需要仔细规划。如果加密的电子邮件邮件的接收者丢失了私钥并且无法访问密钥的备份副本，则加密的消息永远不会被解密。

1.3.3.3. 单点登录

网络用户通常需要记住他们所使用的各种服务的多个密码。例如，用户可能必须键入不同的密码来登录网络、收集电子邮件、使用目录服务、使用公司日历程序并访问各种服务器。对于用户和系统管理员，多个密码都是持续的难题。用户难以跟踪不同密码，往往选择不良密码，并且往往会将它们写在明显的位置。管理员必须跟踪每个服务器上的独立密码数据库，并处理与密码定期通过网络发送的事实相关的潜在安全问题。

解决此问题需要一些方法让用户使用单一密码登录一次，并获得对用户被授权使用的所有网络资源的访问权限，而无需通过网络发送任何密码。这个功能被称为单点登录。

客户端 SSL/TLS 证书和 S/MIME 证书都可以在全面的单点登录解决方案中扮演重要角色。例如，红帽产品支持的一个形式的单点登录依赖于 SSL/TLS 客户端身份验证。用户可以登录一次，使用单个密码到本地客户端的私钥数据库，并经过身份验证访问用户有权使用的所有支持 SSL/TLS 服务器，无需通过网络发送任何密码。这种方法简化了用户的访问权限，因为它们不需要为每个新的服务器输入密码。它还简化了网络管理，因为管理员可以通过控制证书颁发机构(CA)列表而不是更长的用户和密码列表来控制访问权限。

除了使用证书外，完整的单点登录解决方案还必须满足与企业系统（如底层操作系统）进行交互的需求，它们依赖于密码或其他形式的身份验证。

1.3.3.4. 对象签名

许多软件技术支持一组称为 对象签名 的工具。对象签名使用公钥加密的标准技术，让用户可以获得与其下载代码的可靠信息的方式与缩小软件相关的信息相同。

最重要的是，对象签名可帮助用户和网络管理员实施有关在内部网上分发的软件或互联网的决策，例如，是否允许由给定实体签名的 Java 小程序在特定用户机器上使用特定的计算机功能。

使用对象签名技术签名的对象可以是小程序或其他 Java 代码、JavaScript 脚本、插件或任何类型的文件。签名是一个数字签名。签名的对象及其签名通常存储在名为 JAR 文件的特殊文件中。

软件开发人员和希望使用对象签名技术为文件签名，必须首先获取对象签名证书。

1.3.4. 证书类型

证书系统能够为不同的格式和不同的格式生成不同类型的证书。规划需要哪些证书，并计划如何管理它们，包括确定需要哪些格式以及如何规划续订，对于管理 PKI 和证书系统实例非常重要。

此列表并不完整，存在用于 LDAP 目录、文件签名证书和其他子系统证书的双用证书的证书注册表单。这些形式通过证书管理器的最终城市页面（位于 ui'8443/ca/ee/ca' ）提供。

安装不同的证书系统子系统时，会生成基本所需的证书和密钥；例如，配置证书管理器为自签名根 CA 和内部 OCSP 签名、审计签名、SSL/TLS 服务器和代理用户证书生成 CA 签名证书。在 KRA 配置过程中，证书管理器会生成存储、传输、审计签名和代理证书。可以单独创建和安装其他证书。

表 1.1. 通用证书
证书类型	使用	示例
客户端 SSL/TLS 证书	用于通过 SSL/TLS 向服务器进行客户端身份验证。通常，假设客户端的身份与个人的身份相同，如员工。如需了解 SSL/TLS 客户端证书用于客户端身份验证的方式的描述，请参阅第 1.3.2.1 节 “基于证书的验证”。客户端 SSL/TLS 证书也可以用作单点登录的一部分。	银行为客户提供了 SSL/TLS 客户端证书，允许银行的服务器识别该客户并授权访问客户的帐户。公司为新员工提供一个 SSL/TLS 客户端证书，允许公司的服务器识别该员工并授权访问公司服务器。
服务器 SSL/TLS 证书	用于通过 SSL/TLS 向客户端进行服务器身份验证。在不进行客户端身份验证的情况下，可以使用服务器身份验证。加密 SSL/TLS 会话需要服务器身份验证。如需更多信息，请参阅第 1.3.3.1 节 “SSL/TLS”。	参与电子商业业的互联网通常会支持基于证书的服务器身份验证，以建立加密的 SSL/TLS 会话，并确保客户处理公司标识的网站。加密的 SSL/TLS 会话可确保通过网络发送的个人信息（如信用卡号）无法轻松截获。
s/MIME 证书	用于签名和加密的电子邮件。与 SSL/TLS 客户端证书一样，假设客户端的身份与个人的身份相同，如员工。单个证书可以用作 S/MIME 证书和 SSL/TLS 证书；请参阅第 1.3.3.2 节 “已签名并加密的电子邮件”。s/MIME 证书也可以用作单点登录的一部分。	公司部署组合 S/MIME 和 SSL/TLS 证书，以专门验证员工身份，从而允许签名的电子邮件和 SSL/TLS 客户端身份验证，但不加密电子邮件。另一个公司只发出 S/MIME 证书以签发和加密处理敏感财务或法律问题的电子邮件。
CA 证书	用于识别 CA。客户端和服务器软件使用 CA 证书来确定可信任哪些其他证书。如需更多信息，请参阅第 1.3.6 节 “CA 证书如何建立信任”。	Mozilla Firefox 中存储的 CA 证书确定可以验证哪些其他证书。管理员可以通过控制存储在 Firefox 每个用户副本中的 CA 证书来实施企业安全策略。
对象签名证书	用于识别 Java 代码、JavaScript 脚本或其他签名文件的签名者。	软件公司经常为通过互联网分发的软件签名，为用户提供一些保证，确保该软件是公司的合法产品。使用证书和数字签名也可以让用户识别和控制下载的软件对计算机的访问权限类型。

1.3.4.1. CA 签名证书

每个证书管理器都有一个带有公钥/私钥对的 CA 签名证书，用于签署证书和证书撤销列表(CRL)。安装证书管理器时，会创建并安装此证书。

注意

有关 CRL 的更多信息，请参阅第 2.4.4 节 “吊销证书并检查状态”。

证书管理器的状态作为根或下级 CA 决定，由其 CA 签名证书是自签名还是由另一个 CA 签名。自签名 root CA 设置他们用来发布证书的策略，如主题名称、可发布的证书类型，以及可以向谁签发证书。从属 CA 具有由另一个 CA 签名的 CA 签名证书，通常是 CA 层次结构中高于级别的 CA 签名证书（可能也可能不是 root CA）。如果证书管理器是 CA 层次结构中的从属 CA，则必须将 root CA 的签名证书导入到单独的客户端和服务器中，然后才能使用证书管理器向它们发布证书。

如果该 CA 发布的服务器或用户证书已安装在该客户端上，则必须将 CA 证书安装到客户端中。CA 证书确认服务器证书可以被信任。理想情况下，会安装证书链。

1.3.4.2. 其他签名证书

其他服务（如在线证书状态协议(OCSP)响应器服务和 CRL 发布）可以使用 CA 证书以外的签名证书。例如，单独的 CRL 签名证书可用于签署 CA 发布的撤销列表，而不使用 CA 签名证书。

注意

有关 OCSP 的详情，请参考第 2.4.4 节 “吊销证书并检查状态”。

1.3.4.3. SSL/TLS 服务器和客户端证书

服务器证书用于安全通信，如 SSL/TLS 和其他安全功能。服务器证书用于在操作期间和加密数据期间验证自己；客户端证书向服务器验证客户端。

注意

具有第三方发布的签名证书的 CA 可能无法发布服务器证书。第三方 CA 可能有规则，以禁止其从属者发出服务器证书。

1.3.4.4. 用户证书

最终用户证书是客户端证书的子集，用于识别用户到服务器或系统。可以为用户分配用于安全通信的证书，如 SSL/TLS 和其他功能，如加密电子邮件或单点登录。特殊用户（如证书系统代理）可以被授予客户端证书来访问特殊服务。

1.3.4.5. 双密钥对

双密钥对是一组两个私钥和公钥，其中一个集合用于签名，另一个用于加密。这些双密钥用于创建双证书。双证书注册表是证书管理器端点中列出的标准表单之一。

在生成双密钥对时，在为签名和加密生成单独的证书时，将证书配置文件设置为正常工作。

1.3.4.6. 跨对证书

证书系统可以发布、导入和发布跨对 CA 证书。使用跨对证书时，一个 CA 签署并签发对第二个 CA 的跨对证书，第二个 CA 签署并向第一个 CA 发布跨对证书。然后，两个 CA 将两个证书存储或发布为 跨证书 条目。

可以进行桥接证书来遵循不是由 CA 发布的证书，该证书没有串联到 root CA。通过跨对 CA 证书在证书系统 CA 和另一个 CA 之间建立信任，可以下载跨对证书并用来信任其他 CA 发布的证书。

1.3.5. 证书内容

证书内容根据 X.509 v3 证书规范进行组织，该规范由国际电信联合(ITU)推荐，这是一个国际标准正文。

用户通常不需要关注证书的确切内容。但是，使用证书的系统管理员可能需要一定了解它们中包含的信息。

1.3.5.1. 证书数据格式

证书请求和证书可以使用多种不同的格式创建、存储和安装。所有这些格式均符合 X.509 标准。

1.3.5.1.1. 二进制

可识别以下二进制格式：

DER 编码的证书.这是单个二进制 DER 编码的证书。
PKCS #7 证书链.这是一个 PKCS #7 SignedData 对象。SignedData 对象中唯一重要的字段是证书；例如，签名和内容将被忽略。PKCS #7 格式允许一次下载多个证书。
Netscape 证书序列.这是在 PKCS #7 ContentInfo 结构中下载证书链的简单格式，嵌套证书序列。contentType 字段的值应该是 netscape-cert-sequence，而 content 字段具有以下结构：
```
	CertificateSequence ::= SEQUENCE OF Certificate
```
此格式允许同时下载多个证书。

1.3.5.1.2. 文本

任何二进制格式都可以以文本形式导入。文本表单以以下行开头：

-----BEGIN CERTIFICATE-----

在此行之后，证书数据可以采用描述的任何二进制格式。这个数据应该采用 base-64 编码，如 RFC 1113 所述。证书信息后跟这一行：

-----END CERTIFICATE-----

1.3.5.2. 可区分的名称

X.509 v3 证书将区分名称(DN)绑定到公钥。DN 是一系列名称值对，如 uid=doe，用于唯一标识一个实体。这也称为证书 主题名称。

这是 Example Corp 的员工的 DN 示例：

uid=doe, cn=John Doe,o=Example Corp.,c=US

在此 DN 中，uid 是用户名，cn 是用户的通用名称，o 是机构或公司名称，c 是国家。

DNS 可能包括各种其他名称值对。它们用于识别支持轻量级目录访问协议(LDAP)的目录中的证书主题和条目。

监管 DN 结构的规则可能比较复杂；有关 DN 的综合信息，请参阅 http://www.ietf.org/rfc/rfc4514.txt 处 的可辨识名称 的字符串。

1.3.5.3. 典型的证书

每个 X.509 证书由两个部分组成：

data 部分

本节包括以下信息：

证书支持的 X.509 标准的版本号。
证书的序列号。CA 发布的每个证书都有一个序列号，该序列号在该 CA 发布的证书之间是唯一的。
有关用户公钥的信息，包括使用的算法和密钥本身的表示。
发布证书的 CA 的 DN。
证书有效的期间；例如，2004 年 11 月 15 日下午 1:00 到 1:00 p.m 之间的时段。2022 年 11 月 15 日。
证书主题的 DN，也称为主题名称；例如，在 SSL/TLS 客户端证书中，这是用户的 DN。
可选 的证书扩展，可提供客户端或服务器使用的额外数据。例如：
- Netscape 证书类型扩展表示证书类型，如 SSL/TLS 客户端证书、SSL/TLS 服务器证书或签名电子邮件的证书
- 主题备用名称(SAN)扩展将证书链接到一个或多个主机名

证书扩展也可以用于其他目的。

签名部分

本节包括以下信息：

发布 CA 用来创建自己的数字签名的加密算法或密码。
CA 的数字签名，通过对证书中的所有数据进行哈希处理，并使用 CA 的私钥加密。以下是以可读用户友善格式显示的证书的数据和签名部分：

Certificate:
Data:
   Version: v3 (0x2)
   Serial Number: 3 (0x3)
   Signature Algorithm: PKCS #1 MD5 With RSA Encryption
   Issuer: OU=Example Certificate Authority, O=Example Corp, C=US
   Validity:
    Not Before: Fri Oct 17 18:36:25 1997
    Not  After: Sun Oct 17 18:36:25 1999
   Subject: CN=Jane Doe, OU=Finance, O=Example Corp, C=US
   Subject Public Key Info:
    Algorithm: PKCS #1 RSA Encryption
    Public Key:
       Modulus:
          00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
          ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
          43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
          98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
          73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
          9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
          7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
          91:f4:15
       Public Exponent: 65537 (0x10001)
   Extensions:
    Identifier: Certificate Type
      Critical: no
      Certified Usage:
      TLS Client
    Identifier: Authority Key Identifier
      Critical: no
      Key Identifier:
        f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
        26:c9
   Signature:
    Algorithm: PKCS #1 MD5 With RSA Encryption
   Signature:
 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
 f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
 b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
 d:c4

以下是 base-64 编码格式的相同证书：

1.3.6. CA 证书如何建立信任

CA 验证身份和发布证书。它们可以是独立的第三方，也可以是运行自己的证书的组织，如证书系统。

支持证书的任何客户端或服务器软件均维护可信 CA 证书的集合。这些 CA 证书决定了软件可以信任或验证哪些证书签发者。在最简单的情形中，软件只能验证其具有证书的 CA 发布的证书。可信 CA 证书也可以作为 CA 证书链的一部分，每个证书都由 CA 在证书层次结构中的上面发布的。

以下章节解释了证书层次结构和证书链如何确定软件可以信任哪些证书。

1.3.6.1. CA 层次结构

在大型机构中，发布证书的责任可以委派给多个不同的 CA。例如，为单个 CA 维护所需的证书数量可能太大；不同的机构单元可能具有不同的策略要求；或者，CA 可能需要物理位于与发出证书的人员相同的地理位置。

这些证书职责可以划分到从属的 CA 中。X.509 标准包括设置 CA 层次结构的模型，如图 1.6 “证书颁发机构层次结构示例” 所示。

图 1.6. 证书颁发机构层次结构示例

root CA 位于层次结构的顶部。root CA 的证书是 自签名证书 ；也就是说，证书由证书标识的同一实体进行数字签名。直接分配给 root CA 的 CA 具有由 root CA 签名的 CA 证书。层次结构中从属 CA 下的 CA 具有其由更高级别的从属 CA 签名的 CA 证书。

机构具有大量如何设置 CA 层次结构的灵活性，图 1.6 “证书颁发机构层次结构示例” 仅显示一个示例。

1.3.6.2. 证书链

CA 层次结构反映在证书链中。证书链 是由连续 CA 发布的一组证书。图 1.7 “证书链示例” 根据图 1.6 “证书颁发机构层次结构示例” 中显示的 CA 层次结构，显示从证书通过两个下级 CA 证书标识到根 CA 的 CA 证书的证书链。

图 1.7. 证书链示例

证书链跟踪层次结构中从分支到层次结构根目录的证书路径。在证书链中，会出现以下情况：

每个证书后跟其签发者的证书。
每个证书都包含该证书签发者的名称(DN)，它与链中下一证书的主题名称相同。
在图 1.7 “证书链示例” 中，工程 CA 证书包含签发 该证书的 CA 的 DN。美国 CA 的 DN 也是链中下一个证书的主题名称。
每个证书都使用其签发者的私钥签名。可以使用签发者证书中的公钥验证签名，这是链中的下一个证书。
在图 1.7 “证书链示例” 中，美国 CA 证书中的 公钥可用于验证 Engineering CA 的证书上的美国 CA 的数字签名。

1.3.6.3. 验证证书链

证书链验证可确保给定证书链得到良好格式、有效、正确签名和可信。以下过程描述涵盖了组成和验证证书链的最重要步骤，从提供的证书进行验证开始：

根据验证器的系统时钟提供的当前时间检查证书有效期周期。
签发者的证书位于。源可以是该客户端或服务器上的 verifier 的本地证书数据库，也可以是由主题提供的证书链，如 SSL/TLS 连接。
证书签名使用签发者证书中的公钥进行验证。
将服务的主机名与 Subject Alternative Name (SAN)扩展进行比较。如果证书没有这样的扩展，则主机名与主题的 CN 进行比较。
系统会验证证书的基本约束要求，即证书是 CA 以及允许它签名的子公司数量。
如果签发者的证书由验证器的证书数据库中的 verifier 信任，验证可以成功停止。否则，会检查签发者的证书，以确保它包含证书扩展中指示的适当下级 CA，并使用此新证书开始链验证。图 1.8 “验证证书链到 root CA” 显示了此过程的示例。

图 1.8. 验证证书链到 root CA

图 1.8 “验证证书链到 root CA” 演示了当只有 verifier 的本地数据库中包括 root CA 时会发生什么。如果验证器的本地数据库（如 Engineering CA ）之一中间 CA 的证书位于 verifier 的本地数据库中，验证会停止，如图 1.9 “验证证书链到中间 CA” 所示。

图 1.9. 验证证书链到中间 CA

过期的有效期日期、无效签名或在证书链的任意点上发布 CA 的证书会导致身份验证失败。图 1.10 “无法验证的证书链” 当 verifier 的本地数据库中都不包含 root CA 证书或任何中间 CA 证书时，验证会失败。

图 1.10. 无法验证的证书链

1.3.7. 证书状态

有关证书撤销列表(CRL)的更多信息，请参阅第 2.4.4.2.1 节 “CRL”

有关在线证书状态协议(OCSP)的更多信息，请参阅第 2.4.4.2.2 节 “OCSP 服务”