

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 设计 CA 层次结构
<a name="ca-hierarchy"></a>

使用 Amazon 私有 CA，您可以创建最多五个级别的证书颁发机构层次结构。位于层次结构树顶部的根 CA 可以有任意数量的分支。根 CA 的每个分支 CAs 上最多可以有四个从属级别。您还可以创建多个层次结构，每个层次结构都有自己的根。

良好设计的 CA 层次结构提供以下优势：
+ 适用于每个 CA 的精细安全控制
+ 划分管理任务以实现更好的负载平衡和安全性
+ 在有限的 CAs 、可撤销的信任下使用，用于日常运营
+ 有效期和证书路径限制

下图说明了简单的三级 CA 层次结构。

![\[简单的三级 CA 层次结构示意图。\]](http://docs.amazonaws.cn/privateca/latest/userguide/images/simple-ca-tree.png)


树中的每个 CA 都由具有签名权限的 X.509 v3 证书支持（由图标表示）。 pen-and-paper这意味着 CAs，他们可以签署从属于他们的其他证书。当 CA 对较低级别的 CA 证书签名时，它会授予对签名证书的有限、可吊销的权限。级别 1 中的根 CA 签署级别 2 中的高级别从属 CA 证书。反过来 CAs，它们会签署管理终端实体证书的 PKI（公钥基础架构）管理员使用的第 3 级证书。 CAs 

CA 层次结构中的安全性应在树顶部配置为最强。此设置保护根 CA 证书及其私有密钥。根 CA 将所有从属证书 CAs 和终端实体证书的信任锚定在其下面。虽然终端实体证书的受损会导致本地损坏，但根目录的受损会破坏整个 PKI 中的信任。根证书和高级从属证书 CAs 很少使用（通常用于签署其他 CA 证书）。因此，它们受到严格的控制和审计，以确保降低受损风险。在层次结构的较低级别，安全性的限制性较小。此方法允许为用户、计算机主机和软件服务执行例行管理任务，包括颁发和吊销终端实体证书。

**注意**  
使用根 CA 对从属证书签名是一种罕见的事件，仅在少数情况下发生：  
创建 PKI 时
需要替换高级证书颁发机构时
需要配置证书吊销列表 (CRL) 或联机证书状态协议 (OCSP) 响应程序时
Root 和其他高级用户 CAs 需要高度安全的操作流程和访问控制协议。

**Topics**
+ [验证最终实体证书](#end-entity-validation)
+ [规划 CA 层次结构的结构](#ca-layers)
+ [在认证路径上设置长度限制](#length-constraints)

## 验证最终实体证书
<a name="end-entity-validation"></a>

终端实体证书的信任源于一条从属证书路径返回 CAs 到根 CA。向 Web 浏览器或其他客户端呈现了终端实体证书时，它会尝试构建信任链。例如，它可能会检查证书的*颁发者可分辨名称* 和*主题可分辨名称* 是否与颁发 CA 证书的相应字段匹配。匹配将在层次结构上的每个后续级别继续进行，直到客户端到达其信任存储中包含的受信任根。

信任存储库是浏览器或操作系统包含的可 CAs 信库。对于私有 PKI，组织的 IT 部门必须确保每个浏览器或系统之前已将私有根 CA 添加到其信任存储中。否则将无法验证证书路径，导致客户端错误。

下图显示了在向浏览器提供终端实体 X.509 证书时，浏览器遵循的验证路径。请注意，终端实体证书缺乏签名颁发机构，仅用于对拥有该证书的实体进行身份验证。

![\[通过 Web 浏览器进行验证检查。\]](http://docs.amazonaws.cn/privateca/latest/userguide/images/chain-of-trust.png)


浏览器检查终端实体证书。浏览器发现证书提供了来自从属 CA（级别 3）的签名作为其信任凭证。从属证书 CAs 必须包含在同一 PEM 文件中。或者，它们也可以位于包含构成信任链的证书的单独文件中。找到这些内容后，浏览器会检查从属 CA（级别 3）的证书，并发现它提供了来自从属 CA（级别 2）的签名。接下来，从属 CA（级别 2）提供了来自根 CA（级别 1）的签名作为其信任凭证。如果浏览器发现其信任存储中预装的私有根 CA 证书的副本，它会确认终端实体证书可信。

通常，浏览器还会根据证书吊销列表 (CRL) 检查每个证书。已过期、已吊销或配置错误的证书将被拒绝，验证失败。

## 规划 CA 层次结构的结构
<a name="ca-layers"></a>

通常，CA 层次结构应反映组织的结构。*路径深度*（即 CA 的级别数）的目标是不超过委派管理和安全角色所需的级数。将 CA 添加到层次结构意味着增加证书路径中的证书数量，这会增加验证时间。将路径长度保持在最短水平还可以减少验证终端实体证书时从服务器发送到客户端的证书数量。

从理论上讲，没有[pathLenConstraint](PcaTerms.md#terms-pathlength)参数的根 CA 可以授权无限级别的下属 CAs。从属 CA 可以拥有其内部配置 CAs 所允许的任意数量的子从属机构。 Amazon 私有 CA 托管层次结构支持多达五个级别的 CA 认证路径。

良好设计的 CA 结构有几个优势：
+ 为不同组织部门分离管理控制
+ 能够将访问权限委托给下属 CAs
+ 一种分层结构，可通过额外的安全控制来保护更高级别 CAs 的安全 

两种常见的 CA 结构可以实现所有这些优势：
+ **两个 CA 级别：根 CA 和从属 CA**

  这是最简单的 CA 结构，允许对根 CA 和从属 CA 实施单独的管理、控制和安全策略。您可以为根 CA 维护限制性控制和策略，同时为从属 CA 允许更多的访问权限。后者用于批量颁发终端实体证书。
+ **三个 CA 级别：根 CA 和两个从属 CA级别**

  与上述内容类似，此结构添加了一个额外的 CA 级别，以进一步将根 CA 与低级 CA 操作分开。中间的 CA 层仅用于签发终端实体证书的下属 CAs 机构。

较不常见的 CA 结构如下：
+ **四个或更多 CA 级别**

  虽然相比三级层次结构不太常见，但具有四个或更多级别的 CA 层次也存在，并且可能需要允许管理委派。
+ **一个 CA 级别：仅根 CA**

  此结构通常用于不需要完整信任链的开发和测试。用于生产是不合规则的。此外，它违反了为根 CA 和颁发终端实体证书的 CA 分别维护安全策略的最佳实践。 CAs 

  但是，如果您已经直接从根 CA 颁发证书，则可以迁移到 Amazon 私有 CA。与使用 [OpenSSL](https://www.openssl.org/) 或其他软件管理的根 CA 相比，这样做具有安全和控制优势。

### 制造商的私有 PKI 示例
<a name="sample-hierarchy"></a>

在此示例中，一家虚构的技术公司生产两种物联网 (IoT) 产品：智能灯泡和智能烤面包机。在生产过程中会向每台设备颁发终端实体证书，以便它可以通过 Internet 与制造商安全地通信。该公司的 PKI 还保护其计算机基础设施，包括内部网站和各种自行托管的计算机服务，负责财务和业务运营。

因此，CA 层次结构将密切围绕业务的这些管理和运营层面建模。

![\[更复杂的 CA 层次结构示意图。\]](http://docs.amazonaws.cn/privateca/latest/userguide/images/multilevel-ca-tree.png)


此层次结构包含三个根，一个用于内部运营，两个用于外部运营（每个产品线一个根 CA）。它还展示了多种认证路径长度，其中两个 CA 级别用于内部运营，三个级别用于外部运营。

在外部操作端使用独立的根 CAs 和额外的从属 CA 层是一项满足业务和安全需求的设计决策。采用多个 CA 树，PKI 可以适应未来的企业重组、剥离或收购。发生更改时，整个根 CA 层次结构可以随其保护的部门彻底移动。而且，由于 CAs 有两个级别的下属 CA，根目录与负责批量签署成千上万个制成品证书的 3 CAs 级有很高的隔离度。

在内部一端，企业 Web 和内部计算机操作构成了两个层次结构。这些级别允许 Web 管理员和运营工程师为自己的工作域独立管理证书颁发。将 PKI 划分为不同的功能域是一种最佳安全实践，可保护每个领域免受可能影响对方的损坏。Web 管理员颁发终端实体证书，供整个公司的 Web 浏览器使用，对内部网站上的通信进行身份验证和加密。运营工程师颁发终端实体证书，用于对数据中心主机和计算机服务彼此进行身份验证。该系统对局域网上的敏感数据进行加密，有助于保护敏感数据的安全。

## 在认证路径上设置长度限制
<a name="length-constraints"></a>

CA 层次结构的结构由每个证书包含的*基本约束扩展*定义和强制实施。扩展定义了两个约束：
+ `cA` – 证书是否定义 CA。如果此值为 *false*（默认值），则证书是终端实体证书。
+ `pathLenConstraint`— 有效信任链中可以 CAs 存在的最大下级下属人数。终端实体证书不计入，因为它不是 CA 证书。

根 CA 证书需要最大的灵活性，不包括路径长度约束。这允许根定义任意长度的证书路径。

**注意**  
Amazon 私有 CA 将认证路径限制为五个级别。

从属`pathLenConstraint`服务器 CAs 的值等于或大于零，具体取决于层次结构中的位置和所需的要素。例如，在包含三个的层次结构中 CAs，没有为根 CA 指定路径约束。第一个从属 CA 的路径长度为 1，因此可以签名子级 CAs。每个孩子的`pathLenConstraint`值都 CAs 必须为零。这意味着它们可以签署终端实体证书，但无法颁发其他 CA 证书。限制创建新内容的权力 CAs 是一项重要的安全控制措施。

下图说明了这种有限权限在层次结构中向下传播的情况。

![\[简单的三级 CA 层次结构示意图。\]](http://docs.amazonaws.cn/privateca/latest/userguide/images/path-length.png)


在这个四级层次结构中，根不受约束（一如既往）。但是第一个从属 CA 的`pathLenConstraint`值为 2，这限制了其子 CAs 级的深度不能超过两个等级。因此，对于有效的证书路径，约束值必须在接下来的两级中减少为零。如果 Web 浏览器遇到来自此分支的终端实体证书的路径长度大于 4，验证将失败。此类证书可能是由于意外创建的 CA、错误配置的 CA 或未授权颁发造成的。

### 使用模板管理路径长度
<a name="template-path-length"></a>

Amazon 私有 CA 提供用于颁发根证书、从属证书和终端实体证书的模板。这些模板封装了基本约束值的最佳实践，包括路径长度。模板包括以下内容：
+ root CACertificate /V1
+ 下属 CACertificate \$1 PathLen 0/V1
+ 下属 CACertificate \$1 PathLen 1/V1
+ 下属 CACertificate \$1 PathLen 2/V1
+ 下属 CACertificate \$1 PathLen 3/V1
+ EndEntityCertificate/V1

如果您尝试创建的 CA，其路径长度大于或等于其颁发证书 CA 的路径长度，`IssueCertificate` API 将返回错误。

有关证书模板的详细信息，请参阅[使用 Amazon 私有 CA 证书模板](UsingTemplates.md)。

### 使用自动设置 CA 层次结构 Amazon CloudFormation
<a name="using-cloudformation"></a>

当你确定了 CA 层次结构的设计后，你可以使用 Amazon CloudFormation 模板对其进行测试并投入生产。有关此类模板的示例，请参阅《Amazon CloudFormation 用户指南》**中的[声明私有 CA 层次结构](https://docs.amazonaws.cn/AWSCloudFormation/latest/UserGuide/aws-resource-acmpca-certificateauthority.html#aws-resource-acmpca-certificateauthority--examples)。