2.4. 使用证书系统的 PKI
证书系统由子系统组成，它们各自贡献了公钥基础架构的不同功能。通过为子系统实施不同的功能和功能，可以自定义 PKI 环境，以满足各个需求。
注意
传统 PKI 环境提供基本框架来管理软件数据库中存储的证书。这是一个 非 TMS 环境，因为它不管理智能卡上的证书。TMS 环境管理智能卡上的证书。
非TMS 至少需要一个 CA，但非TMS 环境也可以使用 OCSP 响应器和 KRA 实例。
2.4.1. 发布证书
如前文所述，证书管理器是证书系统的核心。它在每个阶段，通过注册（颁发）、续订和吊销请求来管理证书。
证书系统支持从各种端实体（如 Web 浏览器、服务器和虚拟专用网络(VPN)客户端）注册和处理证书请求。发布的证书符合 X.509 版本 3 标准。
如需更多信息，请参阅 Red Hat Certificate System Administration Guide 中的 About rolling and Renewing Certificates 部分。
2.4.1.1. 注册过程
最终实体通过最终用户界面提交注册请求，从而在 PKI 环境中注册。有很多使用不同注册方法的注册，或者需要不同的身份验证方法。不同的接口也可以接受不同类型的证书签名请求(CSR)。
证书管理器支持不同的方法来提交 CSR，如使用图形界面和命令行工具。
2.4.1.1.1. 使用用户界面注册
对于用户界面的每个注册，创建一个单独的注册页面，该页面特定于注册类型、身份验证类型以及与证书类型关联的证书配置文件。可以为外观和内容自定义与注册相关的表单。或者，可以通过为每个注册类型创建证书配置文件来自定义注册过程。证书配置文件通过配置与证书配置文件关联的输入来动态自定义这些表单。不同的接口也可以接受不同类型的证书签名请求(CSR)。
当端点通过请求证书注册到 PKI 时，可能会发生以下事件，具体取决于 PKI 和安装的子系统的配置：
- 最终实体以其中一个注册表提供信息并提交请求。从最终实体收集的信息可以自定义表单，具体取决于收集以存储在证书中的信息，或针对与表单关联的身份验证方法进行身份验证。该表单会创建一个请求，然后提交到证书管理器。
- 注册表单会触发公钥和私钥的创建，或为请求创建双密钥对。
- 最终实体在提交请求前提供身份验证凭据，具体取决于身份验证类型。这可以是 LDAP 身份验证、基于 PIN 的身份验证或基于证书的身份验证。
- 请求提交至代理批准的注册过程或自动过程。
- 代理批准的进程（不包括最终用户身份验证）将请求发送到代理服务接口中的请求队列，其中代理必须处理请求。然后，代理可以修改请求的部分，更改请求的状态、拒绝请求或批准请求。可以设置自动通知，以便在请求出现在队列中时将电子邮件发送到代理。另外，可以将自动化作业设置为发送队列内容列表，以便在预配置的调度时代理。
- 涉及最终用户身份验证的自动化过程（涉及最终用户身份验证）会在端点实体成功验证后立即处理证书请求。
- 表单在提交表单时从 LDAP 目录中收集有关末尾实体的信息。对于基于证书的注册，可以使用表单的默认值来收集用户 LDAP ID 和密码。
- 与表单关联的证书配置文件决定了要发布的证书的各个方面。根据证书配置文件，评估请求来确定请求是否满足约束集、是否提供了所需信息以及新证书的内容。
- 表单也可以请求用户导出私钥。如果使用此 CA 设置 KRA 子系统，则会请求最终用户的密钥，并将归档请求发送到 KRA。此过程通常不需要来自端点实体的交互。
- 证书请求可能被拒绝，因为它不符合证书配置文件或身份验证要求，或者发布证书。
- 证书被传送到最终实体。
- 在自动注册中，证书会立即发送给用户。由于注册通常通过 HTML 页面，因此证书将返回为对另一个 HTML 页面的响应。
- 在代理批准的注册中，证书可以通过序列号或最终用户接口上请求 Id 来检索。
- 如果设置了通知功能，则可获取证书的链接将发送到最终用户。
- 当证书发布或被拒绝时，可以向最终实体发送自动通知。
- 新证书存储在证书管理器的内部数据库中。
- 如果为证书管理器设置了发布，则证书将发布到文件或 LDAP 目录中。
- 内部 OCSP 服务在收到证书状态请求时检查内部数据库中的证书状态。
最终用户接口具有搜索表单，用于发布的证书和 CA 证书链。
默认情况下，用户界面支持 PKCS #10 和证书请求消息格式(CRMF)中的 CSR。
2.4.1.1.2. 使用命令行注册
本节论述了使用命令行注册证书时的一般工作流。
2.4.1.1.2.1. 使用 pki 实用程序注册
详情请查看：
- pki-cert(1) man page
- Red Hat Certificate System Administration Guide 中的 命令行界面 部分。
2.4.1.1.2.2. 使用 CMC 注册
要将证书注册到 CMC，请按如下所示操作：
- 使用工具（如
PKCS10Client或CRMFPopClient）生成 PKCS #10 或 CRMF 证书签名请求(CSR)。注意如果在密钥恢复代理(KRA)中启用了密钥归档，请使用带有 KRA 的 Privacy Enhanced Mail (PEM)格式的 KRA 的传输证书的CRMFPopClient工具，格式为kra.transport文件。 - 使用
CMCRequest工具将 CSR 转换为 CMC 请求。CMCRequest工具使用配置文件作为输入。例如，此文件包含到 CSR 的路径和 CSR 格式。详情请查看 CMCRequest(1) man page。 - 使用
HttpClient实用程序将 CMC 请求发送到 CA。httpclient 使用带有设置的配置文件，如 CMC 请求文件的路径和 servlet。如果 HttpClient 命令成功，工具会从 CA 接收一个 PKCS #7 链，其中包含 CMC 状态控制。如需有关实用程序提供哪些参数的详细信息，请输入不带任何参数的 HttpClient 命令。 - 使用
CMCResponse工具检查由HttpClient生成的 PKCS #7 文件的颁发结果。如果请求成功，CMCResponse以可读格式显示证书链。详情请查看 CMCResponse(1) man page。 - 将新证书导入到应用程序中。详情请参阅您要导入证书的应用程序的说明。注意
HttpClient检索的证书采用 PKCS #7 格式。如果应用程序只支持 Base64 编码的证书，请使用BtoA实用程序转换证书。此外，某些应用程序需要以 Privacy Enhanced Mail (PEM)格式的证书标头和页脚。如果需要它们，请在转换证书后手动将它们添加到 PEM 文件中。
2.4.1.1.2.2.1. 没有 POP 的 CMC 注册
当缺少 proof Of Possession (POP)时，
HttpClient 工具会收到 EncryptedPOP CMC 状态，该状态由 CMCResponse 命令显示。在这种情况下，再次输入 CMCRequest 命令，在配置文件中使用不同的参数。
详情请查看 Red Hat Certificate System Administration Guide 中的 CMC Enrollment Process 部分。
2.4.1.1.2.2.2. 签名的 CMC 请求
CMC 请求可以由用户或 CA 代理签名：
- 如果代理为请求签名，请将配置集中的验证方法设置为 CMCAuth。
- 如果用户为请求签名，请将配置集中的验证方法设置为 CMCUserSignedAuth。
详情请查看 Red Hat Certificate System Administration Guide 中的 CMC 身份验证插件 部分。
2.4.1.1.2.2.3. 未签名的 CMC 请求
当在配置集中配置
CMCUserSignedAuth 身份验证插件时，您必须使用未签名的 CMC 请求与 Shared Secret 身份验证机制结合使用。
注意
未签名的 CMC 请求也称为
自签名 CMC 请求。
详情请查看 Red Hat Certificate System Administration Guide 中的 CMC Authentication Plug-ins 部分，和 第 14.8.3 节 “启用 CMC 共享 Secret 功能”。
2.4.1.1.2.2.5. 简单的 CMC 请求
证书系统允许简单的 CMC 请求。但是，这个过程不支持与完整 CMC 请求相同的安全要求，因此只能在安全环境中使用。
使用简单的 CMC 请求时，请在
HttpClient 工具的配置文件中设置以下内容：
servlet=/ca/ee/ca/profileSubmitCMCSimple?profileId=caECSimpleCMCUserCert
2.4.1.2. 证书配置文件
证书系统使用证书配置文件来配置证书的内容、发布证书的约束、使用的注册方法以及该注册的输入和输出表单。单个证书配置文件与签发特定类型的证书相关联。
为最常见的证书类型包括一组证书配置文件 ; 可修改配置集设置。证书配置文件由管理员配置，然后发送到代理服务页面进行代理批准。批准证书配置文件后，它就被启用以供使用。如果注册 UI，则在终端实体页面中使用动态生成的 HTML 表单进行证书注册，该表单会调用证书配置文件。如果是基于命令行的注册，则在 上调用证书配置文件来执行相同的处理，如身份验证、授权、输入、输出、默认值和约束。在对请求执行前，服务器会验证证书配置文件中设置的默认值和限制，并使用证书配置文件来确定发布的证书的内容。
证书管理器可使用以下任何特征发布证书，具体取决于配置集和提交的证书请求：
- X.509 版本 3 兼容的证书
- Unicode 支持证书主题名称和签发者名称
- 支持空证书主题名称
- 支持自定义主题名称组件
- 支持自定义扩展
默认情况下，证书注册配置文件以 <
profile id > ; .cfg格式存储在 <instance 目录>/ca/profiles/ca 中。可以使用正确的 pkispawn 配置参数进行基于 LDAP 的配置集。
2.4.1.3. 证书注册身份验证
证书系统提供证书注册的验证选项。这包括代理批准的注册（代理处理请求）和自动注册，用于验证端点，然后 CA 会自动发布证书。CMC 注册也被支持，它会自动处理代理批准的请求。
2.4.1.4. 跨证书
通过在这两个 CA 之间发布和存储跨签名证书，可以在两个独立 CA 之间创建可信关系。通过使用跨签名证书对，可在系统内信任在组织的 PKI 外部发布的证书。
2.4.2. 续订证书
当证书达到其过期日期时，可以允许它们释放，或者可以续订它们。
续订 使用该证书的现有密钥对重新生成证书请求，然后将请求重新提交到证书管理器。续订的证书与原始证书相同（因为是使用同一密钥材料的同一配置文件创建），但有一个例外 - 它具有不同的过期日期。
续订可以使用户和服务器之间的证书和关系更加平稳地管理，因为续订的证书功能会精确作为旧证书功能。对于用户证书，续订允许在不丢失任何丢失的情况下访问加密数据。
2.4.3. 发布证书和 CRL
证书可以发布到文件和 LDAP 目录，以及 CRL 到文件、LDAP 目录和 OCSP 响应程序。发布框架提供了一组强大的工具，用于发布到所有这三个位置，并设置规则来定义什么类型的证书或 CRL 在哪里发布。
2.4.4. 撤销证书和检查状态
最终实体可以请求撤销自己的证书。当终端实体发出请求时，必须将证书提供给 CA。如果证书和密钥可用，则请求将处理并发送到证书管理器，证书将被撤销。证书管理器在其数据库中将证书标记为已撤销，并将其添加到任何适用的 CRL 中。
代理可以通过在代理服务界面中搜索证书，然后标记它来撤销证书。证书被撤销后，它将标记为在数据库中和发布目录中撤销（如果为发布证书）。
如果配置了内部 OCSP 服务，该服务可以通过在内部数据库中查找证书来确定证书的状态。
通过启用和配置证书撤销时，可以将自动通知设置为将电子邮件消息发送到最终实体。
2.4.4.1. 吊销证书
用户可以使用以下方法撤销其证书：
- 最终用户页面。详情请查看 Red Hat Certificate System Administration Guide 中的 Certificate Revocation Pages 部分。
- 命令行上的
CMCRequest工具。详情请参阅 Red Hat Certificate System Administration Guide 中的 执行 CMC Revocation 部分。 - 命令行中的
pki工具。详情请查看 pki-cert(1) man page。
2.4.4.2. 证书状态
2.4.4.2.1. CRL
证书系统可以从可配置的框架创建证书撤销列表(CRL)，允许用户定义的发布点，以便为每个发出点创建 CRL。也可以为定义的任何发出点创建 delta CRL。可以为每种类型的证书发布 CRL，适用于特定类型的证书，或针对根据配置集或配置文件列表生成的证书。发布 CRL 时可使用的扩展以及可以配置 CRL 的频率和间隔。
2.4.4.2.2. OCSP 服务
证书系统 CA 支持 PKIX 标准 RFC 2560 中定义的在线证书状态协议(OCSP)。OCSP 协议可让 OCSP 兼容应用程序来确定证书的状态，包括撤销状态，而无需直接检查 CA 发布的 CRL 到验证机构。验证授权（也称为 OCSP 响应器 ）检查应用程序。
- 将 CA 设置为发布包含授权信息访问扩展的证书，用于标识可查询证书状态的 OCSP 响应程序。
- CA 定期向 OCSP 响应程序发布 CRL。
- OCSP 响应器维护它从 CA 接收的 CRL。
- 兼容 OCSP 的客户端会发送请求，其中包含将证书标识到 OCSP 响应程序以进行验证所需的所有信息。应用程序从被验证的证书中的授权信息访问扩展值确定 OCSP 响应器的位置。
- OCSP 响应器确定请求是否包含处理它所需的所有信息。如果没有或未为请求的服务启用它，则会发送拒绝通知。如果它有足够的信息，它会处理请求并发回一个报告，说明证书的状态。
2.4.4.2.2.1. OCSP 响应签名
客户端收到的每个响应（包括拒绝通知）都由响应者进行数字签名；客户端应验证签名，以确保响应来自提交请求的响应者。响应者用来签署消息的键取决于 PKI 设置中如何部署 OCSP 响应程序。RFC 2560 建议用于为响应签名的密钥属于以下之一：
- 签发正在检查其状态的证书的 CA。
- 带有客户端信任的公钥的响应程序。这样的响应者称为 可信响应器。
- 一个响应程序，包含由 CA 直接向它发布的证书，用于撤销证书并发布 CRL。此证书由响应者拥有此证书，表示 CA 已授权响应者为 CA 撤销的证书发布 OCSP 响应。此类响应程序称为 CA 设计的响应程序或 CA 授权响应器。
证书管理器的端点页面包括用于为 OCSP 响应程序手动请求证书的表单。默认注册表包括将证书识别为 OCSP 响应器证书的所有属性。提交证书请求时，可以将所需的证书扩展（如 OCSPNoCheck 和 Extended Key Usage）添加到证书中。
2.4.4.2.2.2. OCSP 响应
客户端接收的 OCSP 响应指示证书的当前状态，由 OCSP 响应器决定。响应可以是以下任意一种：
- 良好或验证的 .指定对状态查询的正响应，这意味着证书尚未被撤销。它不一定意味着签发证书，或者在证书的有效性间隔内。响应扩展可用于传达由响应者有关证书状态的断言的附加信息。
- 已撤销 .指定证书已被撤销，可以是永久或临时撤销。
根据状态，客户端决定是否验证证书。
注意
OCSP 响应器永远不会返回 Unknown 的响应。响应始终为 Good 或 Revoked。
2.4.4.2.2.3. OCSP 服务
设置 OCSP 服务的方法有两种：
- 内置在证书管理器中的 OCSP
- 在线证书状态管理器子系统
除了内置的 OCSP 服务外，证书管理器还可以将 CRL 发布为兼容 OCSP 的验证机构。CA 可以被配置为将 CRL 发布到证书系统在线证书状态管理器。在线证书状态管理器将每个证书管理器的 CRL 存储在其内部数据库中，并使用适当的 CRL 在由 OCSP 兼容客户端查询时验证证书的撤销状态。
每当证书被撤销和按指定间隔撤销时，证书管理器都可以生成并发布 CRL。由于 OCSP 响应器的目的是有助于立即验证证书，因此每次撤销证书时，证书管理器都应该将 CRL 发布到在线证书状态管理器。仅按间隔发布意味着 OCSP 服务正在检查过时的 CRL。
注意
如果 CRL 较大，则证书管理器可能需要很长时间才能发布 CRL。
在线证书状态管理器将每个证书管理器的 CRL 存储在其内部数据库中，并将其用作 CRL 来验证证书。在线证书状态管理器也可以使用发布到 LDAP 目录的 CRL，这意味着证书管理器不必直接将 CRL 更新至在线证书状态管理器。
2.4.5. 归档、恢复和轮转密钥
在 PKI 世界中，私钥存档允许各方在私钥丢失时恢复加密的数据。由于硬件故障，可能会丢失私钥，如硬件故障，忘记密码丢失，智能卡丢失，受损密码持有者、et caetera 等。此类归档和恢复功能由 RHCS 的密钥恢复授权(KRA)子系统提供。
只有专门用于加密数据的密钥才应存档；特定中的签名密钥永远不会存档。拥有两个签名密钥副本会导致无法识别使用密钥的某些人；第二个存档副本可用于模拟原始密钥所有者的数字身份。
2.4.5.1. 归档密钥
KRA 提供两种关键归档机制：
- 客户端密钥生成 ：使用此机制，客户端将以 CRMF 格式生成 CSR，并将请求提交到 CA （具有正确的 KRA 设置），以进行注册和密钥存档。请参阅 Red Hat Certificate System Administration Guide 中的使用 CRMFPopClient 创建 CSR 部分。
- 服务器端密钥生成 ：使用此机制，正确配备证书注册配置文件将触发 KRA 上生成的 PKI 密钥，从而可以选择与新发布的证书一起存档。请参阅 Red Hat Certificate System Administration Guide 中的使用 Server-Side Key Generation 生成 CSR 部分。
密钥的归档副本与 KRA 的存储密钥一起嵌套。它只能通过使用存储证书的对应私钥对来解密或解压缩。一个或多个密钥恢复（或 KRA）代理的证书组合授权 KRA 完成密钥恢复，以检索其私钥并使用它来解密/恢复归档的私钥。请参阅 第 17.3.1 节 “在命令行中配置代理批准密钥恢复”。
- 当密钥恢复代理根据密钥 ID 搜索时，只返回与该 ID 对应的键。
- 当代理根据用户名搜索时，所有属于该所有者的存储密钥都会被返回。
- 当代理根据证书中的公钥搜索时，仅返回对应的私钥。
当证书管理器收到包含密钥归档选项的证书请求时，它会自动将请求转发到 KRA 以归档加密密钥。私钥由传输密钥加密，KRA 接收加密的副本，并将密钥存储在其密钥存储库中。要归档密钥，KRA 使用两个特殊密钥对：
- 传输密钥对和对应的证书。
- 存储密钥对。
图 2.2 “Client-Side Key Generation 中的 Key Archival Process Works” 演示了当最终用户在客户端密钥生成时请求证书时，密钥归档过程如何进行。
图 2.2. Client-Side Key Generation 中的 Key Archival Process Works
- 客户端生成 CRMF 请求，并通过 CA 的注册门户提交它。
- 客户端的私钥嵌套在 CRMF 请求中，只能由 KRA 解封。
- 检测它是带有密钥归档选项的 CRMF 请求，CA 会将请求转发到 KRA 的私钥存档。
- KRA 解密 / 取消打包用户私钥，并在确认私钥与公钥对应后，KRA / 在将其存储在其内部 LDAP 数据库中之前再次加密 /。
- 成功存储私钥后，KRA 会对 CA 响应，确认密钥已成功存档。
- CA 会向请求发送 Enrollment Profile Framework，以进行证书信息内容创建和验证。当一切通过后，都会发出证书并将其发回到其响应中的后端实体。
2.4.5.2. 恢复密钥
KRA 支持 代理发起的密钥恢复。代理初始化的恢复是指定的恢复代理使用 KRA 代理服务门户上的密钥恢复表单来处理和批准密钥恢复请求。批准指定数量的代理后，组织可以在密钥所有者不可用时或者密钥丢失时恢复密钥。
在密钥恢复授权中，其中一个关键恢复代理会通知所有必需的恢复代理有关即将进行密钥恢复的情况。所有恢复代理都访问 KRA 密钥恢复门户。其中一个代理启动密钥恢复过程。KRA 向代理返回通知包括恢复授权引用号，用于标识代理需要的特定密钥恢复请求。每个代理都使用引用号并单独授权密钥恢复。
KRA 支持 异步恢复，这意味着恢复过程的每个步骤（初始请求和后续批准或拒绝）都存储在 KRA 的内部 LDAP 数据库中。即使原始浏览器会话关闭或 KRA 关闭，也可以检索恢复过程的状态数据。代理可以搜索要恢复的密钥，而无需使用参考号。
这个异步恢复选项在 图 2.3 “异步恢复” 中进行了说明。
图 2.3. 异步恢复
KRA 告知代理启动授权状态的密钥恢复过程。
输入所有授权后，KRA 会检查信息。如果显示的信息正确，它会检索请求的密钥，并以 PKCSGRESS 软件包的形式返回对应的证书，到启动密钥恢复过程的代理。
警告
PKCSRG 软件包包含加密的私钥。为最大程度降低密钥威胁的风险，恢复代理必须使用安全方法向密钥接收者提供 PKCSRG 软件包和密码。代理应该使用很好的密码来加密 PKCSRG 软件包并设置适当的交付机制。
密钥恢复代理方案 将 KRA 配置为识别密钥恢复代理所属的组，并指定在恢复归档密钥前授权密钥恢复请求所需的数量。
重要
以上信息指的是使用 Web 浏览器，如 Firefox。但是，在 Red Hat Enterprise Linux 7 平台上发布的 Firefox 版本 31.6 中不再包括 KRA 使用的功能。在这种情况下，需要使用
pki 工具来复制此行为。如需更多信息，请参阅 pki(1) 和 pki-key(1) man page 或运行 CRMFPopClient --help 和 man CMCRequest。
除了存储非对称密钥外，KRA 还可以存储与对称密钥类似的对称密钥或机密，如卷加密 secret，甚至密码和密码短语。
pki 工具支持启用存储和检索这些其他类型的 secret 的选项。
2.4.5.3. KRA 传输密钥轮转
KRA 传输轮转允许使用当前和新的传输密钥在 CA 和 KRA 子系统实例之间进行无缝转换。这允许定期轮转 KRA 传输密钥，方法是允许旧的和新的传输密钥在转换期间运行；单个子系统实例在其他克隆继续不停机的情况下进行配置。
在 KRA 传输密钥轮转过程中，会生成一个新的传输密钥对，提交证书请求，并检索新的传输证书。新的传输密钥对和证书必须包含在 KRA 配置中，以支持第二个传输密钥。KRA 支持两种传输密钥后，管理员可以开始将 CA 转换到新的传输密钥。所有 CA 移至新传输密钥后，可以删除对旧传输密钥的 KRA 支持。
配置 KRA 传输密钥轮转：
- 生成新的 KRA 传输密钥和证书
- 将新传输密钥和证书传输到 KRA 克隆
- 使用新的 KRA 传输证书更新 CA 配置
- 更新 KRA 配置，使其仅使用新的传输密钥和证书
之后，KRA 传输证书轮转已完成，所有受影响的 CA 和 KRA 都使用新的 KRA 证书。有关如何执行上述步骤的更多信息，请参阅以下步骤。
- 生成新的 KRA 传输密钥和证书
- 请求 KRA 传输证书。
- 停止 KRA：
# pki-server stop pki-kra
或（如果使用nuxwdog watchdog）# systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
- 进入 KRA NSS 数据库目录：
# cd /etc/pki/pki-kra/alias
- 创建 子目录并将所有 NSS 数据库文件保存到其中。例如：
mkdir nss_db_backup cp *.db nss_db_backup
- 使用
PKCS10Client工具创建新请求。例如：# PKCS10Client -p password -d '.' -o 'req.txt' -n 'CN=KRA Transport 2 Certificate,O=example.com Security Domain'
或者，使用certutil工具。例如：# certutil -d . -R -k rsa -g 2048 -s 'CN=KRA Transport 2 Certificate,O=example.com Security Domain' -f password-file -a -o transport-certificate-request-file
- 在 CA End-Entity 页面的 Manual Data Recovery Manager 传输证书注册 页中提交传输证书请求。
- 通过检查 End-Entity 检索页面中的请求状态，等待提交请求的代理批准检索证书。
- 通过 CA Agent Services 接口批准 KRA 传输证书。
- 检索 KRA 传输证书。
- 进入 KRA NSS 数据库目录：
# cd /etc/pki/pki-kra/alias
- 通过检查 End-Entity 检索页面中的请求状态，等待提交请求的代理批准检索证书。
- 新的 KRA 传输证书可用后，将其 Base64 编码的值粘贴到文本文件中，例如名为
cert-serial_number.txt的文件。不要包括标头(-----BEGIN CERTIFICATE-----)或页脚(-----END CERTIFICATE-----)。
- 导入 KRA 传输证书。
- 进入 KRA NSS 数据库目录：
# cd /etc/pki/pki-kra/alias
- 将传输证书导入到 KRA NSS 数据库中：
# certutil -d . -A -n 'transportCert-serial_number cert-pki-kra KRA' -t 'u,u,u' -a -i cert-serial_number.txt
- 更新 KRA 传输证书配置。
- 进入 KRA NSS 数据库目录：
# cd /etc/pki/pki-kra/alias
- 验证新的 KRA 传输证书是否已导入：
# certutil -d . -L # certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
- 打开
/var/lib/pki/pki-kra/kra/conf/CS.cfg文件并添加以下行：kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
- 将新传输密钥和证书传播到 KRA 克隆
- 启动 KRA：
# pki-server start pki-kra
或（如果使用nuxwdog watchdog）# systemctl start pki-tomcatd-nuxwdog@pki-kra.service
- 提取新的传输密钥和证书以传播到克隆。
- 进入 KRA NSS 数据库目录：
# cd /etc/pki/pki-kra/alias
- 停止 KRA：
# pki-server stop pki-kra
或（如果使用nuxwdog watchdog）# systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
- 验证新的 KRA 传输证书是否存在：
# certutil -d . -L # certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
- 导出 KRA 新传输密钥和证书：
# pk12util -o transport.p12 -d . -n 'transportCert-serial_number cert-pki-kra KRA'
- 验证导出的 KRA 传输密钥和证书：
# pk12util -l transport.p12
- 在每个 KRA 克隆中执行这些步骤：
- 将
transport.p12文件（包括传输密钥和证书）复制到 KRA 克隆位置。 - 进入克隆 NSS 数据库目录：
# cd /etc/pki/pki-kra/alias
- 停止 KRA 克隆：
# pki-server stop pki-kra
或（如果使用nuxwdog watchdog）# systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
- 检查克隆 NSS 数据库的内容：
# certutil -d . -L
- 导入克隆的新传输密钥和证书：
# pk12util -i transport.p12 -d .
- 在克隆上的
/var/lib/pki/pki-kra/kra/conf/CS.cfg文件中添加以下行：kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
- 启动 KRA 克隆：
# pki-server start pki-kra
或（如果使用nuxwdog watchdog）# systemctl start pki-tomcatd-nuxwdog@pki-kra.service
- 使用新的 KRA 传输证书更新 CA 配置
- 格式化新的 KRA 传输证书以包含在 CA 中。
- 获取在前面的过程中获取 KRA 传输证书时创建的
cert-serial_number.txtKRA 传输证书文件。 - 将
cert-serial_number.txt中包含的 Base64 编码的证书转换为单行文件：# tr -d '\n' < cert-serial_number.txt > cert-one-line-serial_number.txt
- 对 CA 及其所有与上述 KRA 对应的克隆执行以下操作：
- 停止 CA：
# pki-server stop pki-ca
或（如果使用nuxwdog watchdog）# systemctl stop pki-tomcatd-nuxwdog@pki-ca.service
- 在
/var/lib/pki/pki-ca/ca/conf/CS.cfg文件中，找到以下行中包含的证书：ca.connector.KRA.transportCert=certificate
将该证书替换为cert-one-line-serial_number.txt中包含的证书。 - 启动 CA：
# pki-server start pki-ca
或（如果使用nuxwdog watchdog）# systemctl start pki-tomcatd-nuxwdog@pki-ca.service
注意虽然 CA 及其克隆都使用新的 KRA 传输证书更新，但完成转换的 CA 实例使用新的 KRA 传输证书，但尚未更新的 CA 实例继续使用旧的 KRA 传输证书。由于对应的 KRA 及其克隆已更新为同时使用这两个传输证书，因此不会停机。- 更新 KRA 配置，使其仅使用新的传输密钥和证书
- 对于 KRA 及其每个克隆，请执行以下操作：
- 进入 KRA NSS 数据库目录：
# cd /etc/pki/pki-kra/alias
- 停止 KRA：
# pki-server stop pki-kra
或（如果使用nuxwdog watchdog）# systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
- 验证新的 KRA 传输证书是否已导入：
# certutil -d . -L # certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
- 打开
/var/lib/pki/pki-kra/kra/conf/CS.cfg文件，并查找以下行中包含的nickName值：kra.transportUnit.nickName=transportCert cert-pki-kra KRA将nickName值替换为以下行中包含的newNickName值：kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA因此，CS.cfg文件包含这一行：kra.transportUnit.nickName=transportCert-serial_number cert-pki-kra KRA - 从
/var/lib/pki/pki-kra/kra/conf/CS.cfg中删除以下行：kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
- 启动 KRA：
# pki-server start pki-kra
或（如果使用nuxwdog watchdog）# systemctl start pki-tomcatd-nuxwdog@pki-kra.service
