Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.4. PKI 与证书系统

证书系统由子系统组成，它们各自贡献公钥基础架构的不同功能。通过为子系统实施不同的特性和功能，可以自定义 PKI 环境来满足个别需求。

注意

传统 PKI 环境提供基本的框架来管理存储在软件数据库中的证书。这是一个 非 TMS 环境，因为它不管理智能卡上的证书。TMS 环境管理智能卡上的证书。

至少，非TMS 只需要一个 CA，但非TMS 环境也可以使用 OCSP 响应者和 KRA 实例。

2.4.1. 发布证书
复制链接

如前文所述，证书管理器是证书系统的核心。它在每个阶段通过注册（颁发）、续订和撤销的请求管理证书。

证书系统支持注册和发布来自各种最终实体的证书请求，如 Web 浏览器、服务器和虚拟专用网络(VPN)客户端。发布的证书符合 X.509 版本 3 标准。

如需更多信息， 请参阅管理指南中的 5.1 关于注册和 续订证书（通用标准版）。

2.4.1.1. 注册过程
复制链接

最终实体通过最终用户接口提交注册请求，在 PKI 环境中注册。可以使用多种注册方式进行多种注册，或需要不同的身份验证方法。不同的接口也可以接受不同类型的证书签名请求(CSR)。

证书管理器支持不同的方式提交 CSR，如使用图形界面和命令行工具。

2.4.1.1.1. 使用用户界面注册
复制链接

对于每个通过用户界面注册，都会创建一个单独的注册页面，它们特定于注册类型、身份验证类型以及与证书类型关联的证书配置文件。对于外观和内容，可以自定义与注册关联的表单。或者，也可以通过为每个注册类型创建证书配置文件来自定义注册过程。证书配置文件动态生成表单，它们通过配置与证书配置文件关联的输入来自定义。不同的接口也可以接受不同类型的证书签名请求(CSR)。

当最终实体通过请求证书在 PKI 中注册时，可能会发生以下事件，具体取决于 PKI 的配置和安装的子系统：

  1. 最终实体以其中一个注册表格形式提供信息，并提交请求。

    从最终实体收集的信息可在表单中自定义，具体取决于收集到证书中的信息，或针对与表单关联的身份验证方法进行身份验证。表单会创建一个请求，然后提交到证书管理器。

  2. 注册表单会触发为请求创建公钥和私钥或双密钥对。
  3. 最终实体在提交请求之前提供身份验证凭据，具体取决于身份验证类型。这可以是 LDAP 身份验证、基于 PIN 的身份验证或基于证书的身份验证。

  4. 请求提交至代理批准的注册过程或自动过程。

    • agent-approved 进程（不包括最终用户身份验证）将请求发送到代理服务接口中的请求队列，其中代理必须处理请求。然后，代理可以修改请求的部分，更改请求的状态，拒绝请求或批准请求。

      可以设置自动通知，以便在队列中出现请求时向代理发送电子邮件。另外，还可以设置自动化作业，将队列的内容列表发送到之前配置的时间表上的代理。

    • 自动化流程（涉及最终用户身份验证）在最终实体成功进行身份验证后立即处理证书请求。
  5. 在提交表单时，表单会从 LDAP 目录收集有关最终实体的信息。对于基于证书配置文件的注册，可以使用表单的默认值来收集用户 LDAP ID 和密码。
  6. 与表单关联的证书配置文件决定了签发的证书的各个方面。根据证书配置文件，请求会被评估，以确定请求是否满足约束集，如果提供了所需信息，以及新证书的内容。
  7. 表单也可以请求用户导出私钥。如果 KRA 子系统使用这个 CA 设置，则会请求最终实体的密钥，并将 archival 请求发送到 KRA。此过程通常不需要与最终实体的交互。
  8. 证书请求被拒绝，因为它没有满足证书配置文件或身份验证要求，或者签发证书。

  9. 证书传送到最终实体。

    • 在自动注册中，证书会立即提供给用户。由于注册通常通过 HTML 页面，因此证书将返回为另一个 HTML 页面的响应。
    • 在 agent-approved 注册中，证书可以通过序列号或请求 Id 在最终用户接口中检索。
    • 如果设置了通知功能，则会将获取证书的链接发送到最终用户。
  10. 当证书被发布或被拒绝时，可以将自动通知发送到最终实体。
  11. 新证书存储在证书管理器的内部数据库中。
  12. 如果为证书管理器设置了发布，证书将发布到文件或 LDAP 目录。
  13. 当收到证书状态请求时，内部 OCSP 服务会检查内部数据库中证书的状态。

最终用户接口具有已发布的证书和 CA 证书链的搜索表单。

默认情况下，用户界面支持 PKCS #10 和证书请求消息格式(CRMF)中的 CSR。

2.4.1.1.2. 使用命令行注册
复制链接

本节论述了使用命令行注册证书时的一般工作流。

2.4.1.1.2.1. 使用 pki 工具注册
复制链接

详情请查看：

  • pki-cert (1) 手册页
  • 管理指南(Common Standard Edition) 中的 2.5 命令行界面。
2.4.1.1.2.2. 使用 CMC 注册
复制链接

要将证书注册到 CMC，请执行以下操作：

  1. 使用实用程序生成 PKCS #10 或 CRMF 证书签名请求(CSR)，如 certutil、PKCS10Client、CRMFPopClient 或 pki client-cert-request。详情请参阅管理指南中的 创建证书签名请求 (Common Standard Edition)。

    注意

    如果在密钥恢复代理(KRA)中启用密钥归档，请使用 CRMFPopClient 实用程序以及 KRA 的传输证书( Privacy Enhanced Mail (PEM)格式)，在 kra.transport 文件中设置。

  2. 使用 CMCRequest 程序将 CSR 转换为 CMC 请求。CMCRequest 工具使用配置文件作为输入。例如，此文件指定 CSR 的输入路径、CSR 格式、输出 CMC 请求文件或签名证书的 nickname。

    详情请查看 CMCRequest (1) 手册页。

  3. 使用 HttpClient 实用程序将 CMC 请求发送到 CA。httpclient 使用带有设置的配置文件，如输入 CMC 请求文件的路径、输出 CMC 响应文件的路径、TLS mutual 身份验证证书的别名，以及 servlet 完成注册配置文件。如果 HttpClient 命令成功，则实用程序会在 CA 的 CMC 响应中接收带有 CMC 状态控制的 PKCS #7 链。

    有关实用程序提供的参数的详细信息，请输入不带任何参数的 HttpClient 命令。

  4. 使用 CMCResponse 实用程序检查 HttpClient 生成的 CMC 响应文件的颁发结果。如果请求成功，CMCResponse 以可读格式显示证书链，以及状态信息。您还可以使用 -v 选项在链中显示每个证书的 PEM。

    详情请查看 CMCResponse (1) 手册页。

  5. 将新证书导入到应用程序中。详情请参阅您要将证书导入到的应用程序的说明。
注意

HttpClient 检索的证书采用 CMC 响应格式，其中包含 PKCS #7。如果应用程序只支持 Base64 编码的证书，请使用 -v 选项来显示链中每个证书的 PEM。

此外，某些应用程序需要以隐私增强邮件(PEM)格式的证书的标头和页脚。如果需要这些，请手动将它们添加到 PEM 文件中。

2.4.1.1.2.2.1. 没有 POP 的 CMC 注册
复制链接

出现缺少 Of Possession (POP)时，HttpClient 实用程序会收到 EncryptedPOP CMC 状态，该状态由 CMCResponse 命令显示。在这种情况下，使用配置文件中的不同参数再次输入 CMCRequest 命令。

详情请查看 Administration Guide (Common criteria Edition) 中的 5.3.1 CMC Enrollment Process。

2.4.1.1.2.2.2. 签名的 CMC 请求
复制链接

CMC 请求可由用户或 CA 代理签名：

  • 如果代理为请求签名，请将配置集中的身份验证方法设置为 CMCAuth。
  • 如果用户为请求签名，请将配置文件中的验证方法设置为 CMCUserSignedAuth。

详情请查看 管理指南中的 8.3 CMC 身份验证插件（通用标准版本）。

2.4.1.1.2.2.3. 未签名的 CMC 请求
复制链接

当在配置集中配置 CMCUserSignedAuth 身份验证插件时，您必须使用未签名的 CMC 请求与 Shared Secret 身份验证机制结合使用。

注意

未签名的 CMC 请求也称为 自签名 CMC 请求。

详情请查看 管理指南中的 8.3 CMC 身份验证插件（通用标准版本） 和 第 9.6.3 节 “启用 CMC Shared Secret 功能”。

2.4.1.1.2.2.4. Shared Secret 工作流
复制链接

证书系统根据 RFC 5272 为 CMC 请求提供 Shared Secret 身份验证机制。为了保护密码短语，必须使用 CMCSharedToken 命令提供颁发保护证书。颁发保护证书的工作方式与 KRA 传输证书类似。

注意

本节假设您已按照 第 9.6.3 节 “启用 CMC Shared Secret 功能” 启用了 CMC Shared Secret 功能。

最终用户创建的共享 Secret （首选）

下面描述了工作流（如果用户生成共享 secret）：

  1. 最终实体用户从 CA 管理员获取颁发保护证书。

  2. 最终实体用户使用 CMCSharedToken 工具来生成共享 secret 令牌。请参阅管理指南中的 创建共享 Secret 令牌 (Common Standard Edition)。

    注意

    -p 选项设置 CA 和用户之间共享的密码短语，而不是令牌的密码。

  3. 最终用户将 CMCSharedToken 实用程序生成的加密共享令牌发送到管理员。
  4. 管理员将共享令牌添加到用户的 LDAP 条目的 shrTok 属性中。请参阅管理指南中的 8.4.2 设置 CMC 共享 Secret。
  5. 最终实体用户使用密码短语在传递给 CMCRequest 程序的配置文件中设置 witness.sharedSecret 参数。请参阅 5.2.2.2 使用 PKCS10Client 为基于 SharedSecret 的 CMC 和 5.2.3.2 使用 CRMFPopClient 为基于 SharedSecret 的 CMC 创建 CSR （管理指南中的为基于 SharedSecret 的 CMC ）创建 CSR。

详情请查看 CMCSharedToken (1) 手册页。

CA 管理员创建的共享 Secret

下面描述了工作流，如果 CA 管理员为用户生成共享 secret：

  1. 管理员使用 CMCSharedToken 工具为用户生成共享机密令牌。请参阅管理指南中的 创建共享 Secret 令牌 (Common Standard Edition)。

    注意

    -p 选项设置 CA 和用户之间共享的密码短语，而不是令牌的密码。

  2. 管理员将共享令牌添加到用户的 LDAP 条目的 shrTok 属性中。请参阅管理指南中的 8.4.2 设置 CMC 共享 Secret。
  3. 管理员与用户共享密码短语。
  4. 最终实体用户使用密码短语在传递给 CMCRequest 程序的配置文件中设置 witness.sharedSecret 参数。请参阅 5.2.2.2 使用 PKCS10Client 为基于 SharedSecret 的 CMC 和 5.2.3.2 使用 CRMFPopClient 为基于 SharedSecret 的 CMC 创建 CSR （管理指南中的为基于 SharedSecret 的 CMC ）创建 CSR。
2.4.1.1.2.2.5. 简单的 CMC 请求
复制链接

证书系统允许简单的 CMC 请求。但是，这个过程不支持与完整 CMC 请求相同的安全要求，因此只能在安全环境中使用。

在使用简单的 CMC 请求时，在 HttpClient 实用程序的配置文件中设置以下内容： 

servlet=/ca/ee/ca/profileSubmitCMCSimple?profileId=caECSimpleCMCUserCert
Copy to Clipboard Toggle word wrap

2.4.1.2. 证书配置文件
复制链接

证书系统使用证书配置文件来配置证书的内容、发布证书的约束、使用的注册方法以及该注册的输入和输出表单。单个证书配置文件与签发特定类型的证书相关联。

最常见证书类型包括一组证书配置文件；可以修改配置文件设置。证书配置文件由管理员配置，然后发送到代理服务的代理服务页面，以进行代理批准。批准证书配置文件后，它将被启用以供使用。如果是 UI 注册，则会在证书注册的末尾使用动态生成的证书配置集 HTML 表单，该表格调用证书配置文件。如果是基于命令行的注册，则调用证书配置文件来执行相同的处理，如身份验证、授权、输入、输出、默认值和约束。在对请求进行操作之前，服务器会验证证书配置文件中设置的默认值和约束是否满足，并使用证书配置文件来确定发布的证书的内容。

证书管理器可以根据配置集中的配置和提交的证书请求，发布具有以下特征的证书：

  • X.509 版本 3 兼容的证书
  • 对证书主题名称和签发者名称的 Unicode 支持
  • 支持空证书主题名称
  • 支持自定义主题名称组件
  • 支持自定义扩展

默认情况下，证书注册配置集保存在 < instance 目录>/ca/profiles/ca 中，其名称格式为 < profile id>.cfg。正确的 pkipawn 配置参数 可以基于 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. 吊销证书
复制链接

用户可以使用以下方法撤销其证书：

2.4.4.2. 证书状态
复制链接

2.4.4.2.1. CRLs
复制链接

证书系统可以从可配置的框架创建证书撤销列表(CRLs)，以便可以为每个发布点创建一个 CRL。也可以为定义的任何问题点创建 delta CRL。CRL 可以针对每种类型的证书、证书类型的特定子集发布，或针对根据配置集或配置文件列表生成的证书进行发布。发布 CRL 时所使用的扩展以及频率和间隔均可配置。

证书管理器发布 X.509-standard CRL。每当证书被撤销或指定间隔时，都可自动更新 CRL。

2.4.4.2.2. OCSP 服务
复制链接

证书系统 CA 支持 PKIX 标准 RFC 6960 中定义的在线证书状态协议(OCSP)。OCSP 协议可让与 OCSP 兼容的应用程序决定证书的状态，包括撤销状态，而无需直接检查 CA 向验证机构发布的 CRL。验证授权机构（也称为 OCSP 响应程序 ）检查应用程序。

  1. 将 CA 设置为发布包含授权信息访问扩展的证书，它标识可查询证书状态的 OCSP 响应者。
  2. CA 定期将 CRL 发布到 OCSP 响应程序。
  3. OCSP 响应程序维护它从 CA 接收的 CRL。
  4. 与 OCSP 兼容的客户端发送包含所有所需信息的请求，以便向 OCSP 响应者验证。应用程序从正在验证的证书中的授权信息访问扩展的值决定 OCSP 响应者的位置。
  5. OCSP 响应器决定请求是否包含处理它所需的所有信息。如果没有或者没有为请求的服务启用它，则会发送拒绝通知。如果有足够的信息，它会处理请求并发回报告，指出证书的状态。
2.4.4.2.2.1. OCSP 响应签名
复制链接

客户端收到的每个响应（包括拒绝通知）都由响应器数字签名；客户端应该验证签名，以确保响应来自提交请求的响应。响应者用来为消息签名的密钥取决于在 PKI 设置中部署 OCSP 响应器的方式。RFC 6960 建议用于为响应签名的密钥属于以下之一：

  • 发布状态正在检查的证书的 CA。
  • 由客户端信任的公钥的响应者。此类响应器称为 受信任的响应器。
  • 一个响应者，其中包含直接由撤销证书并发布 CRL 的 CA 签发的证书。通过响应者拥有此证书，表示 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 到证书系统在线证书状态管理器。Online Certificate Status Manager 将每个证书管理器的 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 设置）进行注册和密钥归档。请参阅管理指南中的 使用 CRMFPopClient 创建 CSR。
  • 服务器端密钥生成 ：通过这种机制，正确提供的证书注册配置文件将触发 PKI 密钥在 KRA 上生成，因此可以选择与新发布的证书一同存档。请参阅管理指南中的 使用 Server-Side Key Generation (Common criteria Edition) 生成 CSR。

如果配置了归档，则 KRA 会自动归档私钥。

KRA 将私钥存储在安全密钥存储库中；每个密钥都是加密并存储为密钥记录，并被授予一个唯一的密钥标识符。

归档的密钥副本使用 KRA 的存储密钥进行嵌套。它只能通过使用对应存储证书的私钥对解密或未打包。一个或多个密钥恢复（或 KRA）代理的组合授权 KRA 完成密钥恢复，以检索其私钥，并使用它来解密/恢复存档的私钥。请参阅 第 12.3.1 节 “在命令行中配置 agent-approved 密钥恢复”。

KRA 索引根据密钥号、所有者名称和公钥的哈希值来存储密钥，从而提高搜索。密钥恢复代理具有插入、删除和搜索密钥记录的特权。

  • 当密钥 ID 搜索密钥恢复代理时，只返回与该 ID 对应的键。
  • 当代理按用户名搜索时，将返回属于该所有者的所有存储密钥。
  • 当代理根据证书中的公钥搜索公钥时，只返回对应的私钥。

当证书管理器收到包含 key Archive 选项的证书请求时，它会自动将请求转发到 KRA，以归档加密密钥。私钥由传输密钥加密，KRA 接收加密的副本，并将密钥存储在其密钥存储库中。要归档密钥，KRA 使用两个特殊密钥对：

  • 传输密钥对和对应证书。
  • 存储密钥对。

图 2.2 “密钥存档过程如何在客户端密钥生成中工作” 演示了当最终实体在客户端密钥生成时请求证书时，密钥归档过程是如何发生的。

图 2.2. 密钥存档过程如何在客户端密钥生成中工作

KRA arc
View larger image
KRA arc

  1. 客户端生成 CRMF 请求，并通过 CA 的注册门户提交它。

    1. 客户端的私钥嵌套在 CRMF 请求中，只能通过 KRA 解封。
  2. 使用密钥 archival 选项检测它是一个 CRMF 请求，CA 会将请求转发到 KRA，以用于私钥存档。
  3. KRA 在确认私钥与公钥对应后，KRA 会解密 / 解封用户私钥，在将其存储在其内部 LDAP 数据库中之前，KRA 会再次对其进行加密/换行。
  4. 成功存储了私钥后，KRA 会响应 CA，确认密钥已成功存档。
  5. CA 向 Enrollment Profile Framework 发送该请求以获取证书信息内容和验证。当一切通过时，它会发出证书并将其发送回后端实体。

2.4.5.2. 恢复密钥
复制链接

KRA 支持代理发起的密钥恢复。agent-initiated 恢复是在指定恢复代理使用 KRA 代理服务门户上的密钥恢复表单时，处理和批准密钥恢复请求。通过批准指定数量的代理，组织可以在密钥的所有者不可用时或密钥丢失时恢复密钥。

通过 KRA 代理服务门户，密钥恢复代理可以集中授权并检索私有加密密钥及关联的证书，然后可以导入到客户端中。

在密钥恢复授权中，其中一个密钥恢复代理会通知所有必需的恢复代理有关不可变密钥恢复。所有恢复代理访问 KRA 密钥恢复门户。一个代理启动密钥恢复过程。KRA 会向代理返回通知，包括标识代理需要授权的特定密钥恢复请求的恢复授权号。每个代理都使用参考号，并单独授权密钥恢复。

KRA 支持同步 恢复，这意味着恢复过程的每个步骤都包括在 KRA 的内部 LDAP 数据库下，每个后续批准或拒绝了 KRA 的内部 LDAP 数据库都存储在 KRA 的内部 LDAP 数据库中。即使原始浏览器会话关闭或者 KRA 关闭，也可以检索恢复过程的状态数据。代理可以搜索密钥以恢复，而无需使用引用号。

图 2.3 “异步恢复” 中展示了这个异步恢复选项。

图 2.3. 异步恢复

恢复选项
View larger image
恢复选项

KRA 告知代理启动授权状态的关键恢复过程。

输入所有授权时，KRA 会检查信息。如果显示的信息正确，它会检索请求的密钥，并将其与通过 PKCS the 软件包的形式返回对应的证书返回给启动密钥恢复过程的代理。

警告

PKCSwp 软件包包含加密的私钥。为最大程度降低密钥威胁的风险，恢复代理必须使用安全方法向密钥接收者提供 PKCS the 软件包和密码。代理应该使用良好的密码来加密 PKCS the package 并设置适当的交付机制。

密钥恢复代理方案 将 KRA 配置为识别密钥恢复代理所属的组，并在恢复存档密钥前指定需要多少个恢复代理来授权密钥恢复请求。

重要

以上信息指的是使用 Web 浏览器，如 Firefox。但是，对 KRA 使用功能至关重要的功能不再是较新的浏览器版本。在这种情况下，需要使用 pki 工具来复制此行为。如需更多信息，请参阅 pki (1) 和 pki-key (1) man page 或运行 CRMFPopClient --help 和 man CMCRequest。

除了存储非对称密钥外，KRA 还可以存储类似于对称密钥的对称密钥或机密，如卷加密机密，甚至密码和密码短语。pki 工具支持启用存储和检索这些其他类型的 secret 的选项。

2.4.5.3. KRA 传输密钥轮转
复制链接

KRA 传输轮转允许使用当前和新传输密钥在 CA 和 KRA 子系统实例之间进行无缝过渡。这允许定期轮转 KRA 传输密钥，以便在转换期间允许旧和新的传输密钥运行；单个子系统实例需要配置，而其他克隆仍不会停机。

在 KRA 传输密钥轮转过程中，生成一个新的传输密钥对，提交证书请求，并检索新的传输证书。新的传输密钥对和证书必须包含在 KRA 配置中，以便为第二个传输密钥提供支持。KRA 支持两个传输密钥后，管理员可以开始将 CA 转换为新的传输密钥。当所有 CA 移至新传输密钥后，可以删除对旧传输密钥的 KRA 支持。

配置 KRA 传输密钥轮转：

  1. 生成一个新的 KRA 传输密钥和证书
  2. 将新传输密钥和证书传送到 KRA 克隆
  3. 使用新的 KRA 传输证书更新 CA 配置
  4. 更新 KRA 配置，使其只使用新的传输密钥和证书

之后，KRA 传输证书的轮转已完成，所有受影响的 CA 和 KRA 都只使用新的 KRA 证书。有关如何执行上述步骤的更多信息，请参阅以下步骤。

生成新的 KRA 传输密钥和证书

  1. 请求 KRA 传输证书。

    • 停止 KRA： 

      # pki-server stop pki-kra
      Copy to Clipboard Toggle word wrap

      或者，如果使用 Nuxwdog watchdog: 

      # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
      Copy to Clipboard Toggle word wrap

    • 进入 KRA NSS 数据库目录： 

      # cd /etc/pki/pki-kra/alias
      Copy to Clipboard Toggle word wrap

    • 创建一个子目录，并将所有 NSS 数据库文件保存到其中。例如： 

      # mkdir nss_db_backup
      Copy to Clipboard Toggle word wrap 
      # cp *.db nss_db_backup
      Copy to Clipboard Toggle word wrap

    • 使用 PKCS10Client 工具创建新请求。例如： 

      # PKCS10Client -p password -d '.' -o 'req.txt' -n 'CN=KRA Transport 2 Certificate,O=example.com Security Domain'
      Copy to Clipboard Toggle word wrap

      或者，使用 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
      Copy to Clipboard Toggle word wrap
    • 在 CA End-Entity 页面的 Manual Data Recovery Manager Transport Certificate Enrollment 页面中提交传输证书请求。
    • 通过检查 End-Entity 检索页面中的请求状态，等待已提交请求的代理批准，以检索证书。
  2. 通过 CA 代理服务接口批准 KRA 传输证书。

  3. 检索 KRA 传输证书。

    • 进入 KRA NSS 数据库目录： 

      # cd /etc/pki/pki-kra/alias
      Copy to Clipboard Toggle word wrap
    • 通过检查 End-Entity 检索页面中的请求状态，等待已提交请求的代理批准，以检索证书。
    • 新的 KRA 传输证书可用后，将其 Base64 编码的值粘贴到文本文件中，例如名为 cert-serial_number.txt 的文件。不要包含标头(-----BEGIN CERTIFICATE-----)或页脚(-----END CERTIFICATE-----)。

  4. 导入 KRA 传输证书。

    • 进入 KRA NSS 数据库目录： 

      # cd /etc/pki/pki-kra/alias
      Copy to Clipboard Toggle word wrap

    • 将传输证书导入到 KRA NSS 数据库中： 

      # certutil -d . -A -n 'transportCert-serial_number cert-pki-kra KRA' -t 'u,u,u' -a -i cert-serial_number.txt
      Copy to Clipboard Toggle word wrap

  5. 更新 KRA 传输证书配置。

    • 进入 KRA NSS 数据库目录： 

      # cd /etc/pki/pki-kra/alias
      Copy to Clipboard Toggle word wrap

    • 验证新 KRA 传输证书是否已导入： 

      # certutil -d . -L
      Copy to Clipboard Toggle word wrap 
      # certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
      Copy to Clipboard Toggle word wrap

    • 打开 /var/lib/pki/pki-kra/kra/conf/CS.cfg 文件并添加以下行： 

      kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
      Copy to Clipboard Toggle word wrap
将新传输密钥和证书传播到 KRA 克隆
  1. 启动 KRA： 
# pki-server start pki-kra
Copy to Clipboard Toggle word wrap

或者，如果使用 Nuxwdog watchdog: 

# systemctl start pki-tomcatd-nuxwdog@pki-kra.service
Copy to Clipboard Toggle word wrap

  1. 提取用于传播到克隆的新传输密钥和证书。

    • 进入 KRA NSS 数据库目录： 

      # cd /etc/pki/pki-kra/alias
      Copy to Clipboard Toggle word wrap

    • 停止 KRA： 

      # pki-server stop pki-kra
      Copy to Clipboard Toggle word wrap

      或者，如果使用 Nuxwdog watchdog: 

      # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
      Copy to Clipboard Toggle word wrap

    • 验证新的 KRA 传输证书是否存在： 

      # certutil -d . -L
      Copy to Clipboard Toggle word wrap 
      # certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
      Copy to Clipboard Toggle word wrap

    • 导出 KRA 新传输密钥和证书： 

      # pk12util -o transport.p12 -d . -n 'transportCert-serial_number cert-pki-kra KRA'
      Copy to Clipboard Toggle word wrap

    • 验证导出的 KRA 传输密钥和证书： 

      # pk12util -l transport.p12
      Copy to Clipboard Toggle word wrap

  2. 在每个 KRA 克隆上执行这些步骤：

    • 将 transport.p12 文件（包括传输密钥和证书）复制到 KRA 克隆位置。

    • 进入克隆 NSS 数据库目录： 

      # cd /etc/pki/pki-kra/alias
      Copy to Clipboard Toggle word wrap

    • 停止 KRA 克隆： 

      # pki-server stop pki-kra
      Copy to Clipboard Toggle word wrap

      或者，如果使用 Nuxwdog watchdog: 

      # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
      Copy to Clipboard Toggle word wrap

    • 检查克隆 NSS 数据库的内容： 

      # certutil -d . -L
      Copy to Clipboard Toggle word wrap

    • 导入克隆的新传输密钥和证书： 

      # pk12util -i transport.p12 -d .
      Copy to Clipboard Toggle word wrap

    • 在克隆的 /var/lib/pki/pki-kra/kra/conf/CS.cfg 文件中添加以下行： 

      kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
      Copy to Clipboard Toggle word wrap

    • 启动 KRA 克隆： 

      # pki-server start pki-kra
      Copy to Clipboard Toggle word wrap

      或者，如果使用 Nuxwdog watchdog: 

      # systemctl start pki-tomcatd-nuxwdog@pki-kra.service
      Copy to Clipboard Toggle word wrap
使用新的 KRA 传输证书更新 CA 配置

  1. 格式化 CA 中包含的新 KRA 传输证书。

    • 获取在前面的过程中检索 KRA 传输证书时创建的 cert-serial_number.txt KRA 传输证书文件。

    • 将 cert-serial_number.txt 中包含的 Base64 编码的证书转换为单行文件： 

      # tr -d '\n' < cert-serial_number.txt > cert-one-line-serial_number.txt
      Copy to Clipboard Toggle word wrap

  2. 对 CA 及其所有与上述 KRA 对应的克隆执行以下操作：

    • 停止 CA： 

      # pki-server stop pki-ca
      Copy to Clipboard Toggle word wrap

      或者，如果使用 Nuxwdog watchdog: 

      # systemctl stop pki-tomcatd-nuxwdog@pki-ca.service
      Copy to Clipboard Toggle word wrap

    • 在 /var/lib/pki/pki-ca/ca/conf/CS.cfg 文件中，找到以下行中包含的证书： 

      ca.connector.KRA.transportCert=certificate
      Copy to Clipboard Toggle word wrap

      将该证书替换为 cert-one-line-serial_number.txt 中包含的证书。

    • 启动 CA： 

      # pki-server start pki-ca
      Copy to Clipboard Toggle word wrap

      或者，如果使用 Nuxwdog watchdog: 

      # systemctl start pki-tomcatd-nuxwdog@pki-ca.service
      Copy to Clipboard Toggle word wrap
注意

虽然 CA 及其所有克隆都使用新的 KRA 传输证书进行更新，但已完成的 CA 实例将使用新的 KRA 传输证书，并且尚未更新的 CA 实例继续使用旧的 KRA 传输证书。由于对应的 KRA 及其克隆已更新为同时使用这两个传输证书，因此不会发生停机。

更新 KRA 配置，使其只使用新的传输密钥和证书

对于 KRA 及其每个克隆，请执行以下操作：

  1. 进入 KRA NSS 数据库目录： 

    # cd /etc/pki/pki-kra/alias
    Copy to Clipboard Toggle word wrap

  2. 停止 KRA： 

    # pki-server stop pki-kra
    Copy to Clipboard Toggle word wrap

    或者，如果使用 Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@pki-kra.service
    Copy to Clipboard Toggle word wrap

  3. 验证新 KRA 传输证书是否已导入： 

    # certutil -d . -L
    Copy to Clipboard Toggle word wrap 
    # certutil -d . -L -n 'transportCert-serial_number cert-pki-kra KRA'
    Copy to Clipboard Toggle word wrap

  4. 打开 /var/lib/pki/pki-kra/kra/conf/CS.cfg 文件，并查找以下行中包含的 nickName 值： 

    kra.transportUnit.nickName=transportCert cert-pki-kra KRA
    Copy to Clipboard Toggle word wrap

    将 nickName 值替换为以下行中包含的 newNickName 值： 

    kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
    Copy to Clipboard Toggle word wrap

    因此，CS.cfg 文件包含这一行： 

    kra.transportUnit.nickName=transportCert-serial_number cert-pki-kra KRA
    Copy to Clipboard Toggle word wrap

  5. 从 /var/lib/pki/pki-kra/kra/conf/CS.cfg 中删除以下行： 

    kra.transportUnit.newNickName=transportCert-serial_number cert-pki-kra KRA
    Copy to Clipboard Toggle word wrap

  6. 启动 KRA： 

    # pki-server start pki-kra
    Copy to Clipboard Toggle word wrap

    或者，如果使用 Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@pki-kra.service
    Copy to Clipboard Toggle word wrap
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat