2.7. 克隆
2.7.1. 关于 Cloning
通过提供一个或多个子系统克隆，规划 高可用性 可减少计划外中断和其他问题。当主机停机时，克隆的子系统可以处理请求和执行服务，同时从主（原始）子系统无缝处理并保持不间断的服务。
使用克隆的子系统还允许系统离线进行修复、故障排除或其他管理任务，而不中断整体 PKI 系统的服务。
注意
除可克隆 TPS 外的所有子系统。
克隆是一种为 PKI 提供可扩展性的方法，方法是将相同的任务（如处理证书请求）分配给不同计算机上的单独的实例。master 及其克隆的内部数据库会相互复制，因此一个子系统上的证书请求或存档密钥的信息可在所有其他子系统上可用。
通常，master 和克隆的实例安装在不同的计算机上，这些计算机则放置在 负载均衡器后面。负载平衡器接受对证书系统子系统发出的 HTTP 和 HTTPS 请求，并在主控和克隆的实例之间正确定向这些请求。如果一台机器失败，负载均衡器会透明地将所有请求重定向到仍在运行的机器，直到其他机器重新上线为止。
图 2.5. 克隆示例
证书系统子系统前面的负载均衡器是在高可用性系统中提供实际故障转移支持。负载均衡器也可以作为证书系统子系统的一部分提供：
- DNS 循环(round-robin)，一种用于管理在多个不同服务器间分布负载的网络拥塞功能。
- 粘性 SSL/TLS，这使得返回到系统的用户能够路由之前使用的相同主机。
通常，当克隆系统时，配置 servlet 会在内部 LDAP 数据库之间设置复制协议。但是，有些用户可能希望建立和管理自己的复制协议。pkispawn 可执行文件已被修改，通过在 PKI 实例覆盖配置文件中添加
[Tomcat] 部分并在该部分中添加以下 name=value 对：
[Tomcat] pki_clone_setup_replication=False pki_clone_reindex_data=False
重要
在指定这类安装时，必须先复制数据，然后才能 调用 pkispawn。
2.7.2. 准备克隆
您需要将证书导出到
p12 文件，然后在安装克隆子系统时使用该文件。此命令不安装或设置克隆子系统，而是为安装准备它。以下是如何使用 pki-server SUBSYSTEM-clone-prepare 命令导出子系统证书的示例。
例 2.3. 导出子系统证书
[root@pki1 ~]$ 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 的输出返回四个证书：
[root@pki1 ~]$ 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 文件，您现在可以设置克隆子系统。
2.7.3. 为 CA 克隆
克隆的实例具有与 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 的说明，请参阅 第 10.7.1 节 “转换 CA 克隆和 Master”。
主 CA 还通过监控对内部数据库的复制更改来管理克隆的 CA 之间的关系和信息共享。
注意
如果克隆了安全域 master 的 CA，则该克隆的 CA 也是安全域 master。在这种情况下，原始 CA 及其克隆都共享相同的安全域配置。
重要
如 第 2.7.9 节 “自定义配置和克隆” 中所述，LDAP 数据库中的数据会在主控机和克隆之间复制，但不会复制不同实例 的配置文件。这意味着，如果在克隆创建后发生更改，则影响
CS.cfg 文件的任何更改（如添加 KRA 连接或创建自定义配置集）都不会复制到克隆的配置中。
在创建克隆 前，对 CA 配置的任何更改都应进行（因此自定义更改包含在克隆过程中），或者必须在创建后手动复制任何配置更改到克隆实例。
2.7.4. 克隆 KRA
使用 KRA，一个 KRA 中存档的所有密钥都会复制到其他 KRA 的内部数据库。这允许在任何克隆 KRA 上启动密钥恢复，无论最初存档密钥的 KRA。
处理密钥恢复后，恢复的记录将存储在所有克隆的 KRA 的内部数据库中。
通过同步密钥恢复，虽然可以在任何克隆上启动恢复过程，但它必须在启动它的同一单一 KRA 上完成。这是因为在从 KRA 代理获取适当数量的批准后，才会在复制数据库中记录恢复操作。在此之前，启动恢复的 KRA 是唯一知道恢复操作的 KRA。
重要
存在一个在 Red Hat Certificate System 9 中弃用的同步密钥恢复机制，它不在本文档中讨论。红帽建议使用异步密钥恢复。
2.7.5. 克隆其他子系统
复制的 TKS 之间没有实际操作差异；在单个服务器上创建或维护的信息将与其他服务器一起复制。
对于 OCSP，只有一个复制的 OCSP 接收 CRL 更新，然后发布的 CRL 复制到克隆。
2.7.6. 克隆和密钥存储
克隆子系统创建两个执行相同功能的服务器进程：创建子系统的另一个新实例，并配置为使用相同密钥和证书来执行其操作。根据为主克隆存储密钥的位置，克隆访问密钥的方法非常不同。
如果密钥和证书存储在内部软件令牌中，那么首次配置时必须从主子系统导出它们。在配置 master 实例时，可以通过在
pkispawn 配置文件中指定 pki_backup_keys 和 pki_backup_password 参数，将系统密钥和证书备份到 PKCS detailed 文件。详情请查看 pki_default.cfg(5) man page 中的 BACKUP PARAMETERS 部分。
如果在初始配置过程中没有备份密钥，您可以使用
PKCS12Export 工具将其提取到 PKCSall 文件中，如 第 10.1 节 “从软件数据库备份子系统密钥” 所述。
然后，将 PKCSbusybox 文件复制到克隆子系统，并使用 pki_clone_pkcs12_
password 和 pki_clone_pkcs12 _path 参数在 pkispawn 配置文件中定义其位置和密码，请参阅 pkispawn(8) man page 中的 安装克隆 部分。特别是，请确保 pkiuser 用户可以访问 PKCScriu 文件，并且它具有正确的 SELinux 标签。
如果密钥和证书存储在硬件令牌中，则必须使用硬件令牌特定实用程序复制密钥和证书，或者直接在令牌中引用：
- 复制所有必需的密钥和证书，但 SSL/TLS 服务器密钥和证书除外。保留这些证书的 nickname。此外，将 master 实例中的所有必要可信根证书复制到克隆实例，如链或交叉对证书。
- 如果令牌基于网络，那么令牌只需要使用密钥和证书；不需要复制密钥和证书。
- 在使用基于网络的硬件令牌时，请确保在硬件令牌上启用高可用性功能，以避免出现单点故障。
2.7.7. LDAP 和端口注意事项
如 第 2.7.1 节 “关于 Cloning” 所述，克隆行为的一部分是在复制子系统之间复制信息，以便它们处理同一组数据和记录。这意味着复制子系统的 LDAP 服务器需要能够进行通信。
如果 Directory 服务器实例位于不同的主机上，请确保有适当的防火墙访问权限来允许目录服务器实例相互连接。
注意
克隆的子系统及其 master 必须使用单独的 LDAP 服务器，但它们在通用后缀之间复制数据。
子系统可以通过 LDAPS 端口或通过 LDAP 端口的标准连接，使用 SSL/TLS 连接到其内部数据库。克隆子系统时，克隆实例使用与 master 连接数据库相同的连接方法(SSL/TLS 或标准)。通过克隆，还需要额外的数据库连接：主目录服务器数据库到克隆目录服务器数据库。对于那个连接，有三个 连接选项：
- 如果 master 使用 SSL/TLS 连接到其数据库，则克隆使用 SSL/TLS，并且 master/clone 目录服务器数据库使用 SSL/TLS 连接进行复制。
- 如果 master 使用标准连接到其数据库，则克隆必须使用标准连接，而目录服务器数据库 可以使用 未加密的连接进行复制。
- 如果 master 使用标准连接到其数据库，则克隆必须使用标准连接，但 可以选择将 Start TLS 用于 master/clone Directory Server 数据库进行复制。启动 TLS，通过标准端口打开安全连接。注意要使用 Start TLS，目录服务器仍必须配置为接受 SSL/TLS 连接。这意味着，在配置克隆前，必须在 Directory Server 上安装服务器证书和 CA 证书，且必须启用 SSL/TLS。
master 使用的任何连接方法（安全或标准）都必须由克隆使用，且必须在配置克隆前为目录服务器数据库正确配置。
重要
即使克隆通过安全连接连接到 master，标准 LDAP 端口（默认为 389）必须在 LDAP 服务器上打开并启用，同时配置克隆。
对于安全环境，在配置了克隆后，可以在主目录服务器实例上禁用标准 LDAP 端口。
2.7.8. 副本 ID 号
克隆基于为 master 实例在 Directory 服务器之间设置复制协议，以及用于克隆的实例的目录服务器。
涉及复制的服务器位于同一 复制拓扑 中。每次克隆子系统实例时，都会将其添加到整个拓扑中。目录服务器根据 副本 ID 号，在拓扑中的不同服务器间识别不同的服务器。这个副本 ID 在拓扑中的所有服务器中必须是唯一的。
与用于请求和证书的序列号范围一样（在 第 2.7.3 节 “为 CA 克隆”中覆盖），每个子系统都会被分配一个允许的副本 ID 范围。克隆子系统时，它会将一个副本 ID 从其范围分配给新的克隆实例。
dbs.beginReplicaNumber=1 dbs.endReplicaNumber=95
如果实例开始耗尽其当前范围，则可以使用新数字刷新副本 ID 范围。
2.7.9. 自定义配置和克隆
创建克隆后，克隆之间或主控机和克隆之间不会复制 配置更改。实例配置位于复制的数据库外的
CS.cfg 文件中。
例如，有两个 CA，一个 master 和一个克隆。安装了一个新的 KRA，它将在其配置上与主 CA 一起关联。CA-KRA 连接器信息存储在 master CA 的
CS.cfg 文件中，但不会将这个连接器信息添加到克隆 CA 配置中。如果包含密钥归档的证书请求提交到 master CA，则使用 CA-KRA 连接器信息将密钥归档转发到 KRA。如果请求提交到克隆 CA，则不会识别 KRA，并且禁止密钥存档请求。
对主服务器配置或克隆服务器所做的更改不会复制到其他克隆的实例。任何关键设置都必须手动添加到克隆。
注意
在配置任何克隆前，您可以为 master 服务器设置所有必需的自定义配置。例如，安装所有 KRA，以便所有连接器信息都位于主 CA 配置文件中，创建任何自定义配置集，或者为 master OCSP 响应程序配置所有发布点。请注意，如果 LDAP 配置文件存储在 Directory 服务器中，则它们会被复制并跨服务器保持同步。
master 实例中的任何自定义设置都会在克隆实例 时 包含在克隆的实例中（但不在之后）。
