该Authority Information Access扩展用于在给定的证书中发布：

• 可以下载发行人证书副本的地方；
• 在哪个地址/URL 可以找到 OCSP 服务器，这将在包含 AIA 的证书上产生新的撤销信息。

请参阅RFC 5280的第 4.2.2.1 节。

这两种用法仅在具有颁发者的证书中才有意义，即不是验证路径中的第一个证书的证书。路径中的第一个证书是“信任锚”，也就是“根 CA”：这是您“根据定义”信任的名称+密钥，而不是因为某个颁发者的委托。因此，信任锚没有颁发者，也没有撤销状态（它们不能被某些上层 CA 撤销；充其量，您可以手动决定停止信任它们）。信任锚（根 CA）被表示为传统的证书，但根 CA 中的扩展几乎没有意义（当使用此类扩展时，这通常具有与扩展通常体现的完全不同的语义）。

您必须学会避免可能出现的混淆：CA与CA 证书不同。证书颁发机构是具有名称（X.500 可分辨名称）和密钥的实体。该名称和该公钥可以复制到几个不同的证书中。这在两个分层 PKI 决定“相互信任”的情况下很常见。考虑两个 PKI，称为（难以想象的）“A”和“B”。每个 PKI 包括：

• 一个根 CA（分别称为“root_A”和“root_B”），我们可以将其想象为具有硬件安全模块的离线系统；
• 一个从属 CA（分别称为“sub_A”和“sub_B”），它是一个在线系统，可能还带有 HSM，并颁发最终实体证书；
• 最终实体证书。

每个 CA，无论是在线的还是离线的，都必须定期发布撤销信息，因此我们必须假设即使对于离线 CA，在某处也有一个在线服务器，其中通过一些手动过程（或者可能是自动如果存在从根到在线服务器的单向网络链接——链接的单向性允许保持 CA 的离线性）。

在 PKI A 和 B 决定相互信任之前，存在一些证书，具有以下特征：

• root_A 的名称和密钥作为自签名证书发布，该证书的副本可在以下位置获得： http://serverA.com/root_A.cer
• sub_A 的名称和密钥作为证书发布，由 root_A 签名，AIA 指向root_A.cer可用的 URL。sub_A 的证书副本可在以下位置获得：http://serverA.com/sub_A.cer
• 在 sub_A 发布的每个终端实体证书中，都有一个 AIA，其中包含sub_A.cer驻留的 URL。
• PKI B 也是如此。

因此，想要验证来自 PKI A 的最终实体证书的验证者遵循 AIA 扩展来下载所有必需的证书，即sub_A.cer. 验证者也可以下载root_A.cer，但这几乎没有必要，因为为了验证成功，验证者必须已经拥有这个自签名证书的副本。指向 OCSP 服务器（也在 AIA 中）和指向 CRL（作为 CRL 分发点扩展）的指针遵循相同的模式，尽管在这种情况下，从 root_A 指向 CRL/OCSP 的指针并不是多余的（验证者必须检查 sub_A未撤销）。

现在，A 和 B 决定缔结自己的命运，融合他们的血脉，并成为永远最好的朋友。为此，PKI A 和 B 将“合并”，或者至少与通常称为“桥 CA”的东西链接。关键是允许信任 root_A 的人自动接受来自 PKI B 的最终实体证书为有效。实现这一目标的方法主要有四种：

1. Root_A 为 root_B 颁发新证书：证书包含 root_B 的名称和密钥，但该证书不是自签名的；相反，它由 root_A 签名。我们称之为bridge_AB.cer新证书。该证书由 root_A 颁发，包含指向的 AIAroot_A.cer和维护 root_A 颁发的证书的撤销状态的 OCSP 服务器。

   由于没有以任何方式更改、撤销或弃用现有证书，因此信任 root_B（作为信任锚）的人可以像以前一样继续从 PKI B 验证 EE 证书。对于这样的 EE 证书，验证路径将是 root_B->sub_B.cer->EE 对于以 root_B 作为信任锚的人；对于只有 root_A 作为信任锚的人，路径将是 root_A->bridge_AB.cer->sub_B.cer->EE。

   为了使此过程自动运行，所涉及的证书应包含允许重建两条链的 AIA 扩展。root_B.cer在这种情况下，将（在serverB.com服务器上）替换为 的副本就足够了bridge_AB.cer，但在名称下root_B.cer。因此，sub_B.cer现在的 AIA 指向bridge_AB.cer，而无需更改 的任何一位sub_B.cer。信任root_B的人可以直接用，连AIA里面都不看sub_B.cer（至少路径重构）；信任 root_A 的人只遵循 AIA 并重建以 root_A 开头的路径。一切都好。

   root_B.cer仅当只有两个 PKI 时，才能使用桥接证书替换。如果第三个 PKI C 将它们加入到 ménage-à-trois 中，则必须采用更通用的方法：为 sub_B 颁发新证书：该证书将包含指向 root_B 的所有证书的 AIA：旧的 self-签名证书、bridge_AB.cer、bridge_CB.cer等。AIA 格式允许包含多个 URI。sub_B 的新证书可以发布为sub_B.cer，替换之前的证书。

2. Root_A 为 sub_B 颁发新证书。由于这个新证书是由 root_A 颁发的，它包含一个指向root_A.cer. 我们称之为sub_AB.cer新证书。

   那时，我们在路径构建方面遇到了问题。来自 PKI B 的 EE 证书仍然包含指向sub_B.cer服务器的 AIA serverB.com。如果我们用sub_B.cerroot_A ( ) 颁发的新证书替换sub_AB.cer，那么在 root_A 上的路径构建完成，不可能插入到 root_B：只信任 root_B 的人的验证现在被破坏。通用解决方案是重新颁发所有EE 证书，新的 AIA 指向 sub_B 的两个证书（由 root_B 颁发的证书和由 root_A 颁发的证书）。然而，大规模重新发行是昂贵的。另一种方法是“提供”sub_AB.cer给想要验证证书的人。Windows 中有一个专门用于此目的的证书存储（称为“中间 CA”）。尽管 AIA 不会引用此证书，但软件应该足够聪明，以便在必要时使用它。由于中间 CA 不是先验可信的，因此大规模部署此类证书的问题比部署新的信任锚要小。

3. Sub_A 为 root_B 颁发证书。治疗与病例1相似。

4. Sub_A 为 sub_B 颁发证书。治疗与病例 2 类似。

这四种方法是为了将信任从 PKI A 委托给 PKI B，允许信任 root_A 的人验证来自 PKI B 的 EE 证书。对于全桥，还必须做另一个方向（信任 root_B 的人应该能够验证来自 PKI A 的 EE 证书）。两个网桥不必遵循相同的拓扑结构（但是你得到的越漂亮，整个事情就越混乱）。

重点是：

• 任何 CA 都可以有多个证书，其中包含相同的名称和密钥。给定的证书（EE 或 CA）只有一个颁发者（签署证书的实体），但任何包含该颁发者的名称和密钥的证书都可以插入路径中的该点。相应地，证书路径可能会合并（X.509 明确禁止完整循环）。

• AIA 扩展用于通过指向颁发者的潜在证书来帮助构建路径。这些证书的使用不是强制性的；大规模部署中间 CA 证书是一种可行的替代方案（至少在为此提供设施的有组织的网络中，例如 Active Directory 服务器）。

• 这些都不受策略映射的影响。反过来说：如果 PKI A 和 B 使用证书策略，并且都有自己不同的 OID，那么网桥必须包含一个映射，以便验证者可以通过可能构建的所有路径遵循策略。

自签名根证书不应该有 AIA——没有符合 PKIX 的实现将检查的 CRL。

如果您的服务使用您自己的根颁发的证书，但必须仅使用其他 CA 进行验证，则中间应具有 AIA 扩展——它不再是根证书。

为了说明（如果我理解您的架构错误，请纠正我）：

     +---------+ +----------+
     |SHA-1 CA | |套房-B CA|
     | | | |
     | 公共 | | 公共 |
     | 关键 | | 关键 |
     +----+-----+ +----+-----+
         | |
         | |
         | |
         | |
     +----+------+ +----+-----+
     |服务器 A | |服务器 B |
     | 证书 | | 证书 |
     | | | |
     |公钥| |公钥|
     +----------+ +----------+

现在，您希望客户端能够Server A在仅信任Suite-BCA时验证证书。Server B和_SHA-1 CA

为此，实际上，两个 CA 都必须拥有两个证书。第一个证书是自签名的，第二个证书是由另一个 CA 签名的。问题是，两者都必须具有相同的 DN 并使用相同的公钥。另一个问题是服务器可能不会向客户端提供 CA 证书，并且客户端必须在其存储中拥有 CA 证书（非常常见的情况）和其他 CA 证书的中间版本（非典型情况）。此中间证书应具有指向其他 CA CRL DP 的 AIA。

因此，对于Suite-B客户端，架构将如下所示：

                                +----------+
                                |套房-B CA|
                                | |
                                | 公共 |
                                | 关键 |
                                +----+-----+
                               ,,-~''|
                          ,--~' |
                 +--------~'--+ |
                 |SHA-1 CA | |
                 | （一个子CA）| |
                 | 公共 | |
                 | 关键 | |
                 +--,-'--+ |
                ,-~' |
             ,-' |
     +---,-~'---+ +----+-----+
     |服务器 A | |服务器 B |
     | 证书 | | 证书 |
     | | | |
     |公钥| |公钥|
     +----------+ +----------+

在这种情况下，SHA-1CA 证书将包含 CA 的 AIA 和颁发者信息Suite-B。从验证者的角度来看，这个 subCA 证书与第一张图中的证书完全不同。