2.7. 克隆

通过提供一个或多个子系统克隆，规划 高可用性 可减少计划外中断和其他问题。当主机停机时，克隆的子系统可以处理请求和执行服务，同时从主（原始）子系统无缝处理并保持不间断的服务。

使用克隆的子系统还允许系统离线进行修复、故障排除或其他管理任务，而不中断整体 PKI 系统的服务。

克隆是一种为 PKI 提供可扩展性的方法，方法是将相同的任务（如处理证书请求）分配给不同计算机上的单独的实例。master 及其克隆的内部数据库会相互复制，因此一个子系统上的证书请求或存档密钥的信息可在所有其他子系统上可用。

通常，master 和克隆的实例安装在不同的计算机上，这些计算机则放在 负载平衡器 后面。负载平衡器接受对证书系统子系统发出的 HTTP 和 HTTPS 请求，并在主控和克隆的实例之间正确定向这些请求。如果一台机器失败，负载均衡器会透明地将所有请求重定向到仍在运行的机器，直到其他机器重新上线为止。

图 2.5. 克隆示例

证书系统子系统前面的负载均衡器是在高可用性系统中提供实际故障转移支持。负载均衡器也可以作为证书系统子系统的一部分提供：

通常，当克隆系统时，配置 servlet 会在内部 LDAP 数据库之间设置复制协议。但是，有些用户可能希望建立和管理自己的复制协议。pkispawn 可执行文件已被修改，方法是将 [Tomcat] 部分添加到 PKI 实例覆盖配置文件中，并在该部分下添加以下两个 name=value 对：

[Tomcat]
pki_clone_setup_replication=False
pki_clone_reindex_data=False

您需要将证书导出到 p12 文件，然后在安装克隆子系统时使用该文件。此命令不安装或设置克隆子系统，而是为安装准备它。以下是如何使用 pki-server SUBSYSTEM-clone-prepare 命令导出子系统证书的示例。

pki-server ca-clone-prepare --i topology-02-CA --pkcs12-file /tmp/caclone.p12 --pkcs12-password SECret.123
-----------------------------------------------------
Added certificate "subsystemCert cert-topology-02-CA"
-----------------------------------------------------
--------------------------------------------------------
Added certificate "caSigningCert cert-topology-02-CA CA"
--------------------------------------------------------
----------------------------------------------------------
Added certificate "ocspSigningCert cert-topology-02-CA CA"
----------------------------------------------------------
-----------------------------------------------------------
Added certificate "auditSigningCert cert-topology-02-CA CA"
-----------------------------------------------------------

您可以验证导出的 p12 文件是否包含证书。在以下示例中，pki pkcs12-cert-find 的输出返回四个证书：

pki pkcs12-cert-find --pkcs12-file /tmp/caclone.p12 --pkcs12-password SECret.123
---------------
4 entries found
---------------
Certificate ID: 4649cef11b90c78d126874b91654de98ded54073
Serial Number: 0x4
Nickname: subsystemCert cert-topology-02-CA
Subject DN: CN=Subsystem Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,u
Has Key: true

Certificate ID: a304cf107abd79fbda06d887cd279fb02cefe438
Serial Number: 0x1
Nickname: caSigningCert cert-topology-02-CA CA
Subject DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: CTu,Cu,Cu
Has Key: true

Certificate ID: 4a09e057c1edfee40f412551db1959831abe117d
Serial Number: 0x2
Nickname: ocspSigningCert cert-topology-02-CA CA
Subject DN: CN=CA OCSP Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,u
Has Key: true

Certificate ID: 3f42f88026267f90f59631d38805cc60ee4c711a
Serial Number: 0x5
Nickname: auditSigningCert cert-topology-02-CA CA
Subject DN: CN=CA Audit Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org
Trust Flags: u,u,Pu
Has Key: true

使用导出的 p12 文件，您现在可以设置克隆子系统。

克隆的实例具有与 master 相同的私钥，因此其证书是相同的。对于 CA，这意味着 CA 签名证书与原始 master CA 及其克隆的 CA 相同。从客户端的角度来看，它们看起来像一个 CA。

每个克隆的 CA 和 master 都可能会发布证书并处理撤销请求。

管理复制 CA 的主要问题是如何为它们发布的证书分配序列号。不同的复制 CA 可以有不同的流量级别，使用不同速率的序列号，并且没有两个复制 CA 签发具有相同序列号的证书。这些序列号范围通过使用共享来动态分配和管理，复制条目定义每个 CA 的范围和下一个可用范围，以便在一个 CA 范围运行较低时重新分配。

克隆的 CA 的序列号范围是 fluid。所有复制 CA 共享一个通用配置条目，用于定义下一个可用范围。当一个 CA 在可用数字上开始运行较低时，它会检查此配置条目并声明下一个范围。该条目会自动更新，以便下一个 CA 获取新范围。

范围在 begin*Number 和 end*Number 属性中定义，并为请求和证书序列号定义单独的范围。例如：

 dbs.beginRequestNumber=1
 dbs.beginSerialNumber=1
 dbs.enableSerialManagement=true
 dbs.endRequestNumber=9980000
 dbs.endSerialNumber=ffe0000
 dbs.replicaCloneTransferNumber=5

只有一个复制 CA 才能生成、缓存和发布 CRL；这是 CRL CA。提交到其他复制 CA 的 CRL 请求会立即重定向到 CRL CA。虽然其他复制 CA 可以撤销、显示、导入和下载之前由 CRL CA 生成的 CRL，但如果生成了新的 CRL，则可能会出现同步问题。有关如何将 CRL 生成移到不同的复制 CA 的步骤，请参阅 第 9.5.1 节 “转换 CA 克隆和 master”。

主 CA 还通过监控对内部数据库的复制更改来管理克隆的 CA 之间的关系和信息共享。

使用 KRA，一个 KRA 中存档的所有密钥都会复制到其他 KRA 的内部数据库。这允许在任何克隆 KRA 上启动密钥恢复，无论最初存档密钥的 KRA。

处理密钥恢复后，恢复的记录将存储在所有克隆的 KRA 的内部数据库中。

通过同步密钥恢复，虽然可以在任何克隆上启动恢复过程，但它必须在启动它的同一单一 KRA 上完成。这是因为在从 KRA 代理获取适当数量的批准后，才会在复制数据库中记录恢复操作。在此之前，启动恢复的 KRA 是唯一知道恢复操作的 KRA。

复制的 TKS 之间没有实际操作差异；在单个服务器上创建或维护的信息将与其他服务器一起复制。

对于 OCSP，只有一个复制的 OCSP 接收 CRL 更新，然后发布的 CRL 复制到克隆。

克隆子系统创建两个执行相同功能的服务器进程：创建子系统的另一个新实例，并配置为使用相同密钥和证书来执行其操作。根据为主克隆存储密钥的位置，克隆访问密钥的方法非常不同。

如果密钥和证书存储在内部软件令牌中，那么首次配置时必须从主子系统导出它们。在配置 master 实例时，可以通过在 pkispawn 配置文件中指定 pki_backup_keys 和 pki_backup_password 参数将系统密钥和证书备份到 PKCSautomationhub 文件。详情请查看 pki_default.cfg (5) 手册页中的 BACKUP PARAMETERS 部分。

如果初始配置过程中没有备份密钥，您可以使用 PKCS12Export 工具将它们提取到 PKCS12Export 文件中，如 第 9.1 节 “从软件数据库备份子系统密钥” 所述。

然后，将 PKCSautomationhub 文件复制到克隆子系统，并使用 pki_clone_pkcs12_ password 和 pki_clone_pkcs12 _path 参数在 pkispawn 配置文件中定义位置和密码，请参阅 pkispawn (8) 手册页中的 Installing a Clone 部分。特别是，请确保 pkiuser 用户可以访问 PKCSGRESS 文件，并且具有正确的 SELinux 标签。

如果密钥和证书存储在硬件令牌中，则必须使用硬件令牌特定实用程序复制密钥和证书，或者直接在令牌中引用：

如 第 2.7 节 “克隆” 所述，克隆的一部分是在复制子系统之间复制信息，以便它们可从相同的数据和记录集中工作。这意味着复制子系统的 LDAP 服务器需要能够进行通信。

如果 Directory 服务器实例位于不同的主机上，请确保有适当的防火墙访问来允许目录服务器实例相互连接。

子系统可以通过 LDAPS 端口或通过 LDAP 端口的标准连接，使用 SSL/TLS 连接到其内部数据库。克隆子系统时，克隆实例使用与 master 连接数据库相同的连接方法(SSL/TLS 或标准)。使用克隆时，还有额外的数据库连接：主目录服务器数据库到克隆目录服务器数据库。对于那个连接，有三个 连接选项：

master 使用的任何连接方法（安全或标准）都必须由克隆使用，且必须在配置克隆前为 Directory Server 数据库正确配置。

克隆基于在 master 实例的目录服务器和克隆的实例的 Directory 服务器之间设置复制协议。

涉及复制的服务器位于同一 复制拓扑 中。每次克隆子系统实例时，都会将其添加到整个拓扑中。目录服务器根据 副本 ID 号 在拓扑中的不同服务器之间差异。这个副本 ID 在拓扑中的所有服务器中必须是唯一的。

与用于请求和证书的序列号范围一样（在 第 2.7.3 节 “为 CA 克隆” 中介绍），每个子系统被分配一个允许的副本 ID 范围。克隆子系统时，它会将一个副本 ID 从其范围分配给新的克隆实例。

dbs.beginReplicaNumber=1
dbs.endReplicaNumber=95

如果实例开始耗尽其当前范围，则可以使用新数字刷新副本 ID 范围。

创建克隆后，克隆之间或主控机和克隆之间不会复制 配置更改。实例配置位于复制数据库之外的 CS.cfg 文件中。

例如，有两个 CA，一个 master 和一个克隆。安装了一个新的 KRA，它将在其配置上与主 CA 一起关联。CA-KRA 连接器信息存储在 master CA 的 CS.cfg 文件中，但这个连接器信息不会添加到克隆 CA 配置中。如果包含密钥归档的证书请求提交到 master CA，则使用 CA-KRA 连接器信息将密钥归档转发到 KRA。如果请求提交到克隆 CA，则不会识别 KRA，并且禁止密钥存档请求。

对主服务器或克隆服务器配置所做的更改不会复制到其他克隆的实例。任何关键设置都必须手动添加到克隆。