Language:
Format:

管理指南

Red Hat Certificate System 9

更新了 Red Hat Certificate System 9.7

摘要

本手册涵盖安装、配置和管理 &CRTS、子系统的所有方面。它还涵盖添加用户等管理任务；请求、更新和撤销证书；发布 CRL，以及管理智能卡。本指南适用于 &CRTS；管理员。

第 1 章 Red Hat Certificate Systemnbsp 概述;Hat Certificate Red Hat Certificate Systemnbsp;System Subsystems

每个常见的 PKI 操作都 - 发布、更新和撤销证书；存档和恢复密钥；发布 CRL 并验证证书状态 - 由红帽证书系统设备中的交互子系统进行；红帽证书认证系统；验证证书；系统。本章介绍了各个子系统的功能和它们一起来构建强大且本地 PKI 的功能。

1.1. 使用证书

证书的目的是建立信任。它们的使用情况根据它们用于确保的信任类型而有所不同。某些种类的证书用于验证出发者的身份；另一些则用于验证对象或项目没有被篡改。

有关使用证书、证书类型或证书如何建立身份和关系的信息，请参阅 红帽认证系统 9 规划、安装和部署指南中的证书和验证章节。 https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/9/html/Planning_Installation_and_Deployment_Guide/Introduction_to_Public_Key_Cryptography-Certificates_and_Authentication.html#types-of-certificates

1.2. CertificateCertificate Systemnbsp 的评论;系统子系统

Red Hat Certificate Systemnbsp;Hat Certificate Red Hat Certificate Systemnbsp;System 提供五个不同的子系统，它们分别侧重于 PKI 部署的不同方面。这些子系统共同创建公钥基础架构(PKI)。根据安装的子系统，PKI 可以充当令牌管理系统(TMS)或非令牌管理系统。有关子系统和 TMS 和非TMS 环境的描述，请参阅红帽认证系统 规划、安装和部署指南中的证书系统子系统 章节。

Enterprise 安全客户端

企业安全客户端不是子系统，因为它不使用证书、密钥或令牌执行任何操作。Enterprise Security Client 是一个用户界面，它允许用户非常轻松地管理智能卡中的证书。Enterprise Security Client 会将所有令牌操作（如证书请求）发送到令牌处理系统(TPS)，然后将其发送到证书颁发机构(CA)。如需更多信息，请参阅 Red Hat Certificate System 9 使用 Enterprise Security Client 管理智能卡。

1.3. 查看管理证书(Non-TMS)

传统的 PKI 环境提供了基本的框架，用于管理存储在软件数据库中的证书。这是一个 非TMS 环境，因为它不管理智能卡上的证书。至少，非TMS 只需要一个 CA，但非 RHEL 环境也可以使用 OCSP 响应器和 KRA 实例。

有关此主题的详情，请参阅 红帽证书系统规划、安装和部署指南中的 以下章节：

1.4. 查看令牌管理系统(TMS)

CertificateCertificate Systemnbsp;System 创建、管理、更新并撤销证书，同时存档和恢复密钥。对于使用智能卡的组织，证书Certificate Systemnbsp;System 有令牌管理系统 - 具有已建立关系的子系统集合 - 生成密钥和请求以及接收用于智能卡的证书。

有关此主题的详情，请参阅 红帽证书系统规划、安装和部署指南中的 以下章节：

1.5. RedRed Hat Certificate Systemnbsp;Hat CertificateRed Hat Certificate Systemnbsp;System services

根据用户类型，管理证书和密钥有不同的接口：管理员、代理、审计员和最终用户。有关通过每个界面执行的不同功能的概述，请参阅 红帽认证系统 9 规划、安装和部署指南中的红帽认证系统 用户界面 部分。

部分 I. Red Hat Certificate System User Interfaces

第 2 章用户界面

根据用户的角色，管理证书和密钥有不同的接口：管理员、代理、审计员和最终用户。

2.1. 用户界面概述

管理员可以使用以下接口安全地与完成的证书系统安装交互：

PKI 命令行界面和其他命令行实用程序
PKI 控制台图形界面
证书系统 Web 界面.

这些接口需要先配置，然后才能通过 TLS 与证书系统服务器进行安全通信。不允许在没有正确配置的情况下使用这些客户端。其中一些工具使用 TLS 客户端身份验证。如果需要，它们所需的初始化过程包括配置这一点。使用的接口取决于管理员的首选项和功能。本章会在指南的剩余部分中描述使用这些接口的常见操作。

默认情况下，PKI 命令行界面使用用户的 ~/.dogtag/ 目录中的 NSS 数据库。第 2.5.1.1 节 “pki CLI initialization” 提供使用管理员证书和密钥初始化 NSS 数据库的详细步骤。第 2.5.1.2 节 “Using "pki" CLI” 中介绍了使用 PKI 命令行工具的一些示例。其他示例将显示在本指南的其余部分中。

与证书系统（作为其他用户角色中的管理员）交互，可以使用各种命令行实用程序提交 CMC 请求，管理生成的证书等。这些在第 2.5 节 “命令行界面” 中简单描述，如第 2.5.2 节 “AtoB”。这些工具在稍后部分（如第 5.2.1.2 节 “使用 PKCS10Client创建 CSR” ）中使用。

-- 证书系统 PKI 控制台界面是图形界面。第 2.3.1 节 “pkiconsole complete” 介绍如何初始化。第 2.3.2 节 “将 pkiconsole 用于 CA、OCSP、KRA 和 TKS Subsystems” 概述了使用控制台界面。后面部分，如第 3.2.2 节 “使用基于 Java 的管理控制台管理证书注册配置集” 会根据特定操作进行更详细的信息。

证书系统 Web 界面允许通过 Firefox Web 浏览器访问。第 2.4.1 节 “浏览器初始化” 描述配置客户端身份验证的步骤。第 2.4 节 “Web 界面” 中的其他部分描述了使用证书系统的 Web 界面。

注意

要终止 PKI 控制台会话，请单击 Exit 按钮。要终止 Web 浏览器会话，请关闭浏览器。当命令行实用程序执行该操作并返回到提示时，命令行实用程序就会立即终止。因此，管理员部分无法终止会话。

2.2. 客户端 NSS 数据库初始化

在 Red Hat Certificate System 中，某些接口可能需要使用 TLS 客户端证书身份验证（验证）访问服务器。在执行服务器端的管理任务前，您需要：

为客户端准备 NSS 数据库。这可以是新数据库或现有数据库。
导入 CA 证书链并信任它们。
具有证书和对应密钥。它们可以生成在 NSS 数据库中，或者从其他位置导入，比如从 PKCS #12 文件中导入。

根据实用程序，您需要相应地初始化 NSS 数据库。请参阅：

第 2.5.1.1 节 “pki CLI initialization”
第 2.3.1 节 “pkiconsole complete”
第 2.4.1 节 “浏览器初始化”

2.3. 图形界面

pkiconsole 是一个图形界面，专为具有管理员角色特权的用户而设计，用于管理子系统本身。这包括添加用户、配置日志、管理配置文件和内部数据库，以及许多其他功能。此实用程序使用 client-authentication 通过 TLS 与证书系统服务器通信，并可用于远程管理服务器。

2.3.1. `pkiconsole` complete

要首次使用 pkiconsole 接口，请指定新密码并使用以下命令：

$ pki -c password -d ~/.redhat-idm-console client-init

这个命令会在 ~/.redhat-idm-console/ 目录中创建一个新的客户端 NSS 数据库。

要将 CA 证书导入到 PKI 客户端 NSS 数据库，请参阅 Red Hat 证书系统规划、安装和部署指南中的 将 证书导入到 NSS 数据库 部分。

要请求新的客户端证书，请参阅第 5 章 请求、注册和管理证书。

执行以下命令从 .p12 文件中提取 admin 客户端证书：

$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt

验证和导入 管理客户端证书，如 红帽认证系统规划、安装和部署指南中的 管理证书/密钥加密令牌 一节中所述：

$ PKICertImport -d ~/.redhat-idm-console -n "nickname" -t ",," -a -i file.crt -u C

重要

在导入 CA 管理客户端证书前，请确保已导入所有中间证书和 root CA 证书。

将现有客户端证书及其密钥导入到客户端 NSS 数据库中：

$ pki -c password -d ~/.redhat-idm-console pkcs12-import --pkcs12-file file --pkcs12-password pkcs12-password

使用以下命令验证客户端证书：

$ certutil -V -u C -n "nickname" -d ~/.redhat-idm-console

2.3.2. 将 `pkiconsole` 用于 CA、OCSP、KRA 和 TKS Subsystems

Java 控制台由四个子系统使用：CA、OCSP、KRA 和 TKS。控制台可通过本地安装的 pkiconsole 工具访问。它可以访问任何子系统，因为该命令需要主机名、子系统的管理 TLS 端口和特定的子系统类型。

pkiconsole https://server.example.com:admin_port/subsystem_type

如果没有配置 DNS，您可以使用 IPv4 或 IPv6 地址连接到控制台。例如：

https://192.0.2.1:8443/ca
https://[2001:DB8::1111]:8443/ca

这会打开一个控制台，如图 2.1 “证书系统控制台” 所示。

图 2.1. 证书系统控制台

Configuration 选项卡控制子系统的所有设置，如名称所示。此选项卡中的选择根据实例的子系统类型而异；CA 具有最多选项，因为它具有适用于作业、通知和证书注册身份验证的其他配置。

所有子系统都有四个基本选项：

用户和组
访问控制列表
日志配置
子系统证书（根据子系统发布的证书，例如，在安全域或审计签名中）

Status 选项卡显示子系统维护的日志。

2.4. Web 界面

2.4.1. 浏览器初始化

本节解释了 Firefox 访问 PKI 服务的浏览器初始化。

导入 CA 证书

点击 Menu → 首选项 → 隐私以及安全 → 视图证书。
选择" 颁发机构 "选项卡，然后单击" 导入 "按钮。
选择 ca.crt 文件并点击 Import。

导入客户端证书

点击选项 → 首选项 → 隐私以及安全 → 视图证书。
选择您的证书选项卡。
单击 Import，再选择客户端 p12 文件，如 ca_admin_cert.p12。
在提示符下输入客户端证书的密码。
点击 OK。
验证您的证书下是否添加了条目。

访问 Web 控制台

您可以通过在浏览器中打开 https://host_name:端口 来访问 PKI 服务。

2.4.2. 管理接口

所有子系统都使用基于 HTML 的管理界面。它通过输入主机名并以 URL 保护端口、与管理员的证书进行身份验证，然后单击相应的管理员链接。

注意

所有子系统均只有一个 TLS 端口，它们用于管理员和代理服务。对这些服务的访问受基于证书的身份验证的限制。

HTML 管理界面比 Java 控制台更多；主要管理功能正在管理子系统用户。

TPS 仅允许操作来管理 TPS 子系统的用户。但是，TPS 管理员页面还可列出令牌，并显示在 TPS 上执行的所有活动（包括通常隐藏的管理操作）。

图 2.2. TPS 管理员页面

2.4.3. 代理接口

代理服务页面是几乎所有证书和密钥管理任务的执行位置。这些服务是基于 HTML 的，代理使用特殊的代理证书向站点进行身份验证。

图 2.3. 证书管理器的代理服务页面

具体操作会根据子系统的不同而有所不同：

证书管理器代理服务包括批准证书请求（发出证书）、撤销证书以及发布证书和 CRL。CA 发布的所有证书均可通过其代理服务页面进行管理。
TPS 代理服务（如 CA 代理服务）管理已格式化的所有令牌，并通过 TPS 向它们发布证书。令牌可以被代理注册、暂停和删除。另外两个角色（operator 和 admin）可以查看 web 服务页面中的令牌，但不能对令牌执行任何操作。
KRA 代理服务页面处理密钥恢复请求，这设定了在证书丢失时是否允许重新发布证书。
OCSP 代理服务页面允许代理配置将 CRL 发布到 OCSP 的 CA，以手动将 CRL 加载到 OCSP，并查看客户端 OCSP 请求的状态。

TKS 是唯一没有代理服务页面的子系统。

2.4.4. 最终用户页面

CA 和 TPS 均以某种方式处理直接用户请求。这意味着最终用户必须采用一种方法来连接这些子系统。CA 具有最终用户或 最终用户、 HTML 服务。TPS 使用企业安全客户端。

最终用户服务使用服务器的主机名和标准端口号通过标准 HTTP 访问；也可使用服务器的主机名和特定端点 TLS 端口通过 HTTPS 访问它们。

对于 CA，每种 TLS 证书类型通过特定的在线提交表单进行处理，称为 配置集。CA 有两个 dozen 证书配置文件，涵盖了所有种类的证书，包括用户 TLS 证书、服务器 TLS 证书、日志和文件签名证书、电子邮件证书以及每种子系统证书。还可能有自定义配置集。

图 2.4. 证书的 Manager 结束日期（Entities 页）

最终用户在签发证书时，通过 CA 页面检索其证书。它们也可以下载 CA 链和 CRL，并可以通过这些页面撤销或更新证书。

2.5. 命令行界面

本节讨论命令行实用程序。

2.5.1. "pki" CLI

pki 命令行界面(CLI)提供对使用 REST 界面的服务器各种服务的访问（请参阅 红帽认证系统规划、安装和部署指南中的 REST 接口 部分）。CLI 可以按照以下方式调用：

$ pki [CLI options] <command> [command parameters]

请注意，必须在命令前放置 CLI 选项，并在命令之后放置命令参数。

2.5.1.1. pki CLI initialization

要首次使用命令行界面，请指定新密码并使用以下命令：

$ pki -c <password> client-init

这会在 ~/.dogtag/nssdb 目录中创建一个新的客户端 NSS 数据库。必须在使用客户端 NSS 数据库的所有 CLI 操作中指定密码。或者，如果密码存储在文件中，您可以使用 -C 选项指定该文件。例如：

$ pki -C password_file client-init

要将 CA 证书导入到客户端 NSS 数据库，请参阅 红帽认证系统规划、安装和部署指南中的 将 证书导入到 NSS 数据库 部分。

有些命令可能需要客户端证书身份验证。要将现有客户端证书及其密钥导入到客户端 NSS 数据库中，请指定 PKCS #12 文件和密码，并执行以下命令：

执行以下命令从 .p12 文件中提取 admin 客户端证书：

$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt

验证和导入 管理客户端证书，如 红帽认证系统规划、安装和部署指南中的 管理证书/密钥加密令牌 一节中所述：

$ PKICertImport -d ~/.dogtag/nssdb -n "nickname" -t ",," -a -i file.crt -u C

重要

在导入 CA 管理客户端证书前，请确保已导入所有中间证书和 root CA 证书。

要将现有客户端证书及其密钥导入到客户端 NSS 数据库中，请指定 PKCS #12 文件和密码，并执行以下命令：

$ pki -c <password> pkcs12-import --pkcs12-file <file> --pkcs12-password <password>

使用以下命令验证客户端证书：

certutil -V -u C -n "nickname" -d ~/.dogtag/nssdb

2.5.1.2. Using "pki" CLI

命令行界面支持以分级结构组织的多个命令。要列出顶级命令，在不执行任何附加命令或参数的情况下执行 pki 命令：

$ pki

些命令使用子命令。要列出它们，请使用命令名称执行 pki，而不执行附加选项。例如：

$ pki ca

$ pki ca-cert

要查看命令用法信息，请使用 --help 选项：

$ pki --help

$ pki ca-cert-find --help

要查看 man page，请指定命令行帮助命令：

$ pki help

$ pki help ca-cert-find

要执行不需要身份验证的命令，请指定命令及其参数（如果需要），例如：

$ pki ca-cert-find

要执行需要客户端证书身份验证的命令，请指定证书 nickname、客户端 NSS 数据库密码以及可选的服务器 URL：

$ pki -U <server URL> -n <nickname> -c <password> <command> [command parameters]

例如：

$ pki -n jsmith -c password ca-user-find ...

默认情况下，CLI 与位于 http://local_host_name 的服务器通信：8080。要与位于不同位置的服务器通信，请使用 -U 选项指定 URL，例如：

$ pki -U https://server.example.com:8443 -n jsmith -c password ca-user-find

2.5.2. AtoB

AtoB 工具对 Base64 编码的证书进行解码，使其二进制文件等效。例如：

$ AtoB input.ascii output.bin

详情请查看 AtoB(1) man page。

2.5.3. AuditVerify

AuditVerify 程序通过验证日志条目中的签名来验证审计日志的完整性。

例如：

$ AuditVerify -d ~jsmith/auditVerifyDir -n Log Signing Certificate -a ~jsmith/auditVerifyDir/logListFile -P "" -v

这个示例使用 ~jsmith/auditVerifyDir NSS 数据库中的 Log Signing Certificate (-n)验证审计日志。要验证(-a)的日志列表位于 ~jsmith/auditVerifyDir/logListFile 文件中，以逗号分隔和排序。证书前的前缀(-P)，密钥数据库文件名为空。输出是 verbose(-v)。

详情请查看 AuditVerify(1) man page 或第 15.3.2 节 “使用签名审计日志”。

2.5.4. BtoA

BtoA 程序编码了 Base64 中的二进制数据。例如：

$ BtoA input.bin output.ascii

详情请查看 BtoA(1) man page。

2.5.5. CMCRequest

CMCRequest 程序创建一个证书保护或撤销请求。例如：

$ CMCRequest example.cfg

注意

CMCRequest 工具的所有选项都作为传递给实用程序的配置文件的一部分指定。有关配置文件选项和更多信息，请查看 CMCRequest(1) man page。另请参阅 4.3。使用 CMC 和第 7.2.1 节 “使用 CMCRequest撤销证书” 请求和接收证书。

2.5.6. CMCRevoke

传统.不要使用。

2.5.7. CMCSharedToken

CMCSharedToken 工具为共享保障的 CMC 请求加密用户密码短语。例如：

$ CMCSharedToken -d . -p myNSSPassword -s "shared_passphrase" -o cmcSharedTok2.b64 -n "subsystemCert cert-pki-tomcat"

共享密码短语(-s)被加密并存储在 cmcSharedtok2.b64 文件中(-o) 使用名为 subsystemCert-pki-tomcat (-n) 在当前目录中的 NSS 数据库中的证书。默认安全令牌内部使用（因为未指定 -h ），并且 myNSSPassword 的令牌密码用于访问令牌。

详情请查看 CMCSharedtoken(1) man page 和第 7.2.1 节 “使用 CMCRequest撤销证书”。

2.5.8. CRMFPopClient

CRMFPopClient 实用程序是使用 NSS 数据库的证书请求消息格式(CRMF)客户端，并提供 Possession 的概念验证。

例如：

$ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -t false -v -o /user_or_entity_database_directory/example.csr

此示例使用 cn=subject_name subject DN(-n)、在当前目录中的 NSS 数据库创建一个新的 CSR，用于传输 kra.transport (-b)、AES/CBC/PKCS5adding key wrap algorithm from the key wrap algorithm is specified（ -v）和生成的 CSR 写入 /user_or_entity_database_directory/example.csr 文件(-o)。

有关详情、更多选项和其他示例，请参阅 CRMFPopClient --help 命令的输出以及第 7.2.1 节 “使用 CMCRequest撤销证书”。

2.5.9. HttpClient

HttpClient 程序是一个 NSS 感知 HTTP 客户端，用于提交 CMC 请求。

例如：

$ HttpClient request.cfg

注意

HttpClient 实用程序的所有参数都存储在 request.cfg 文件中。如需更多信息，请参阅 HttpClient --help 命令的输出。

2.5.10. OCSPClient

一个在线证书状态协议(OCSP)客户端，用于检查证书撤销状态。

例如：

$ OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2

这个示例在端口 8080 上查询 server.example.com OCSP 服务器(-h)检查由 caSigningcet cert-pki-ca (-c)签名的证书是否有效。使用 /etc/pki/pki-tomcat/alias 目录中的 NSS 数据库。

如需了解更多详细信息、更多选项和其他示例，请参阅 OCSPClient --help 命令的输出。

2.5.11. PKCS10Client

PKCS10Client 工具为 RSA 和 EC 密钥（可选）在 HSM 中创建一个 PKCS10 格式的 CSR。

例如：

$ PKCS10Client -d /etc/dirsrv/slapd-instance_name/ -p password -a rsa -l 2048 -o ~/ds.csr -n "CN=$HOSTNAME"

这个示例在 /etc/dirsrv/slapd-instance_name/ 目录中（-d with database password (-p)）中创建带有 2048 字节(-l)密钥。输出 CSR 存储在 ~/ds.cfg 文件中(-o)，证书 DN 为 CN=$HOSTNAME (-n)。

详情请查看 PKCS10Client(1) man page。

2.5.12. PrettyPrintCert

PrettyPrintCert 工具以人类可读格式显示证书的内容。

例如：

$ PrettyPrintCert ascii_data.cert

此命令解析 ascii_data.cert 文件的输出，并以人类可读格式显示其内容。输出中包含签名算法、exponent、modulus 和证书扩展等信息。

详情请查看 PrettyPrintCert(1) man page。

2.5.13. PrettyPrintCrl

PrettyPrintCrl 实用程序以人类可读格式显示 CRL 文件的内容。

例如：

$ PrettyPrintCrl ascii_data.crl

此命令解析 ascii_data.crl 的输出，并以人类可读格式显示其内容。输出中包括信息，如撤销签名算法、撤销者以及已撤销证书及其原因列表。

详情请查看 PrettyPrintCrl(1) man page。

2.5.14. TokenInfo

TokenInfo 实用程序列出了 NSS 数据库中的所有令牌。

例如：

$ TokenInfo ./nssdb/

此命令列出在指定数据库目录中注册的所有令牌（HSM、软令牌等）。

如需了解更多详细信息、更多选项和其他示例，请参阅 TokenInfo 命令的输出

2.5.15. tkstool

tkstool 程序与令牌密钥服务(TKS)子系统交互。

例如：

$ tkstool -M -n new_master -d /var/lib/pki/pki-tomcat/alias -h token_name

该命令在 HSM token_name上的 /var/lib/pki/pki-tomcat/alias NSS 数据库中创建一个名为 new_master (-n)的新 master 密钥(-M)

详情请查看 tkstool -H 命令的输出。

2.6. Enterprise 安全客户端

Enterprise Security Client 是 Red Hat Certificate Systemnbsp 的工具；授权证书 Red Hat Certificate Systemnbsp;System 简化了智能卡管理。最终用户可以使用安全令牌（smart 卡）来存储用于应用程序的用户证书，如单点登录访问和客户端身份验证。最终用户会签发包含签名、加密和其他加密功能所需的证书和密钥的令牌。

Enterprise Security Client 是 CertificateCertificate Systemnbsp 的第三个部分；系统的完整令牌管理系统。两个子系统 - 令牌密钥服务(TKS)和令牌处理系统(TPS)用于处理与令牌相关的操作。Enterprise Security Client 是允许智能卡和用户访问令牌管理系统的接口。

注册令牌后，可将 Mozilla Firefox 和 Thunderbird 等应用程序配置为识别令牌并将其用于安全操作，如客户端身份验证和 S/MIME 邮件。Enterprise Security Client 提供以下功能：

支持 JavaCard 2.1 或更高版本卡和全球平台 2.01- 兼容智能卡，如 Safenet 的 330J 智能卡。
支持 Gemalto TOP IM FIPS CY2 令牌，包括智能卡和 GemPCKey USB 形式因素键。
支持 SafeNet 智能卡 650(SC650)。
注册安全令牌，以便被 TPS 识别。
维护安全令牌，如使用 TPS 重新注册令牌。
提供有关受管理的令牌或令牌的当前状态的信息。
支持服务器端密钥生成，以便在令牌丢失时可以在单独的令牌中存档并恢复密钥。

Enterprise Security Client 是最终用户在智能卡或令牌上注册和管理密钥和证书的客户端。这是 CertificateCertificate Systemnbsp;System 令牌管理系统(TPS)和令牌密钥服务(TKS)中的最后一个组件。

Enterprise Security Client 提供令牌管理系统的用户界面。最终用户可以签发安全令牌，其中包含签名、加密和其他加密功能所需的证书和密钥。要使用令牌，TPS 必须能够识别并与之通信。企业安全客户端是要注册令牌的方法。

企业安全客户端通过 SSL/TLS HTTP 频道与 TPS 的后端通信。它基于用户界面的可扩展 Mozilla XULRunner 框架，同时为基于简单的 HTML 的 UI 保留传统的 Web 浏览器容器。

在令牌被正确注册后，可将 Web 浏览器配置为识别令牌并将其用于安全操作。Enterprise Security Client 提供以下功能：

允许用户注册安全令牌，以便被 TPS 识别。
允许用户维护安全令牌。例如，企业安全客户端可以使用 TPS 重新注册令牌。
通过默认的和自定义令牌配置集，为多种不同类型的令牌提供支持。默认情况下，TPS 可以自动注册用户密钥、设备密钥和安全分析密钥。可以添加额外的配置集，以便使用不同的使用的令牌（由令牌 CUID 等属性标识）根据适当的配置集自动注册。
提供有关被管理的令牌的当前状态的信息。

部分 II. 设置证书服务

第 3 章制作发行证书规则（证书配置文件）

CertificateCertificate Systemnbsp;System 提供了一个自定义的框架，用于应用传入请求的策略，并控制输入请求类型和输出证书类型，这些框架称为 证书配置文件。证书配置集在证书管理器端点页面中设置证书注册表单所需的信息。本章论述了如何配置证书配置集。

3.1. 关于证书配置集

证书配置集定义了与发布特定类型的证书相关联的一切内容，包括身份验证方法、授权方法、默认证书内容、内容值的限制以及证书配置文件的输入和输出内容。注册和续订请求将提交到证书配置文件，然后受该证书配置集中设置的默认值和约束。这些限制通过与证书配置集关联的输入表单或通过其它方法提交请求。从证书配置文件请求发布的证书包含默认设置所需内容，以及默认参数所需的信息。约束提供了证书中允许的内容的规则。

有关使用和自定义证书配置集的详情，请参考第 3.2 节 “设置证书配置集”。

证书系统包含一组默认配置集。虽然创建了默认配置集来满足大多数部署，但每个部署都可以添加自己的新证书配置集或修改现有的配置集。

身份验证.在每个认证配置集中都可以指定身份验证方法。
授权.在每个认证配置集中都可以指定授权方法。
配置集输入。配置集输入是请求证书时提交给 CA 的参数和值。配置集输入包括证书请求的公钥和证书实体请求的证书主题名称。
配置集输出。配置集输出是参数和值，用于指定向端点提供证书的格式。当请求成功时，配置集输出为 CMC 响应，其中包含 PKCS#7 证书链。
证书内容。每个证书都定义内容信息，如为其分配的实体的名称（主题名称）、签名算法及其有效周期。在 X.509 标准中定义证书中包含的内容。使用 X509 标准的版本 3，证书也可以包含扩展。有关证书扩展的详情请参考第 B.3 节 “标准 X.509 v3 证书扩展参考”。
关于证书配置文件的所有信息都在配置集的配置文件中的 set 条目中定义。当应该同时请求多个证书时，可以在配置集策略中定义多个集合条目来满足每个证书的需求。每个策略集都包含多个策略规则，每个策略规则描述了证书内容中的一个字段。策略规则可以包括以下部分：
- 配置集默认值。以下是证书中包含的信息的预定义参数和允许值。配置集默认值包括证书的有效性周期，以及每个发布的证书扩展显示哪些证书扩展。
- 配置集限制。约束设置规则或策略以发布证书。另外，配置集限制包括需要证书主体名称至少包含一个 CN 组件的规则，从而将证书的有效性设置为 360 天，以定义续订允许的宽限期，或者要求 subjectaltname 扩展始终设置为 true。

3.1.1. 注册配置集

定义输入、输出和策略集合的每个配置集的参数在表 11.1 中被详细列出。红帽认证系统规划、安装和部署指南中的配置文件参数.

配置集通常包含输入、策略集和输出，如例 3.1 “caCMCUserCert Profile 示例” 中的 caUserCert 配置集所示。

例 3.1. caCMCUserCert Profile 示例

证书配置集的第一部分是描述。这会显示名称、长描述（无论是否启用）以及谁启用它。

desc=This certificate profile is for enrolling user certificates by using the CMC certificate request with CMC Signature authentication.
visible=true
enable=true
enableBy=admin
name=Signed CMC-Authenticated User Certificate Enrollment

注意

这个配置集中缺少 auth.instance_id= 条目意味着，不需要使用此配置集进行身份验证来提交注册请求。但是，经授权 CA 代理的手动批准需要经过授权后才能获得帮助。

接下来，配置集会列出配置集的所有所需输入：

input.list=i1
input.i1.class_id=cmcCertReqInputImp

对于 caCMCUserCert 配置集，这定义了证书请求类型，即 CMC。

接下来，配置集必须定义输出，即最终证书的格式。唯一可用的是 certOutputImpl，这会导致 CMC 响应在成功时返回到请求者。

output.list=o1
output.o1.class_id=certOutputImpl

最后最大的 - 配置块是配置集设置的策略。策略集列出了应用于最终证书的所有设置，如其有效期期、其续订设置以及证书可用于的操作。policyset.list 参数标识应用于某个证书的策略的块名称，policyset.userCertSet.list 列出了要应用的单个策略。

例如，根据策略中的配置，第六个策略会自动填充证书中的键使用范围。它通过设置限制来设置默认值，并要求证书使用这些默认值：

policyset.list=userCertSet
policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9
...
policyset.userCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
policyset.userCertSet.6.constraint.name=Key Usage Extension Constraint
policyset.userCertSet.6.constraint.params.keyUsageCritical=true
policyset.userCertSet.6.constraint.params.keyUsageDigitalSignature=true
policyset.userCertSet.6.constraint.params.keyUsageNonRepudiation=true
policyset.userCertSet.6.constraint.params.keyUsageDataEncipherment=false
policyset.userCertSet.6.constraint.params.keyUsageKeyEncipherment=true
policyset.userCertSet.6.constraint.params.keyUsageKeyAgreement=false
policyset.userCertSet.6.constraint.params.keyUsageKeyCertSign=false
policyset.userCertSet.6.constraint.params.keyUsageCrlSign=false
policyset.userCertSet.6.constraint.params.keyUsageEncipherOnly=false
policyset.userCertSet.6.constraint.params.keyUsageDecipherOnly=false
policyset.userCertSet.6.default.class_id=keyUsageExtDefaultImpl
policyset.userCertSet.6.default.name=Key Usage Default
policyset.userCertSet.6.default.params.keyUsageCritical=true
policyset.userCertSet.6.default.params.keyUsageDigitalSignature=true
policyset.userCertSet.6.default.params.keyUsageNonRepudiation=true
policyset.userCertSet.6.default.params.keyUsageDataEncipherment=false
policyset.userCertSet.6.default.params.keyUsageKeyEncipherment=true
policyset.userCertSet.6.default.params.keyUsageKeyAgreement=false
policyset.userCertSet.6.default.params.keyUsageKeyCertSign=false
policyset.userCertSet.6.default.params.keyUsageCrlSign=false
policyset.userCertSet.6.default.params.keyUsageEncipherOnly=false
policyset.userCertSet.6.default.params.keyUsageDecipherOnly=false
...

3.1.2. 证书扩展：默认和限制

扩展配置用于包含在证书或规则中有关如何使用证书的附加信息。这些扩展可以在证书请求中指定，或者从配置集默认定义中获取，然后由限制强制实施。

如果在配置集中添加或标识了证书扩展，方法是添加与扩展名对应的默认值，并在请求中未设置证书扩展。例如： Basic Constraints Extension 标识证书是否为 CA 签名证书、可在 CA 中配置的最大下级 CA 数以及扩展是否重要（必需）：

policyset.caCertSet.5.default.name=Basic Constraints Extension Default
policyset.caCertSet.5.default.params.basicConstraintsCritical=true
policyset.caCertSet.5.default.params.basicConstraintsIsCA=true
policyset.caCertSet.5.default.params.basicConstraintsPathLen=-1

扩展也可以为名为 constraints 的证书请求设置所需的值。如果请求的内容与集合约束不匹配，则请求将被拒绝。约束通常对应于扩展名默认值，但并不总是对应。例如：

policyset.caCertSet.5.constraint.class_id=basicConstraintsExtConstraintImpl
policyset.caCertSet.5.constraint.name=Basic Constraint Extension Constraint
policyset.caCertSet.5.constraint.params.basicConstraintsCritical=true
policyset.caCertSet.5.constraint.params.basicConstraintsIsCA=true
policyset.caCertSet.5.constraint.params.basicConstraintsMinPathLen=-1
policyset.caCertSet.5.constraint.params.basicConstraintsMaxPathLen=-1

注意

要允许用户在证书请求中嵌入用户提供的扩展并忽略配置集中定义的默认值，配置集需要包含 User Supplied Extension Default，如第 B.1.32 节 “用户补充默认设置”。

3.1.3. 输入和输出

输入设置信息，必须提交以接收证书。这可以是请求者信息、证书请求特定格式或机构信息。

配置集中配置的输出定义签发的证书格式。

在 CertificateCertificate Systemnbsp;System 中，通过 注册表单 （通过结束日期页面访问）访问配置文件。（即使客户端，如 TPS，通过这些表单提交注册请求。）然后，输入对应于注册表单中的字段。输出与证书检索页面中包含的信息对应。

3.2. 设置证书配置集

在证书系统中，您可以添加、删除和修改注册的配置集：

使用 PKI 命令行界面
使用基于 Java 的管理控制台

本节提供有关每种方法的信息。

3.2.1. 使用 PKI 命令行界面管理证书注册配置集

这部分论述了如何使用 pki 工具管理证书配置集。详情请查看 pki-ca-profile(1) man page。

注意

建议使用 raw 格式。有关配置集的每个属性和字段的详情，请参阅红帽认证系统规划、安装和部署指南中的有关文件系统创建和编辑证书配置集部分。

3.2.1.1. 启用和禁用证书配置集

在编辑证书配置集前，您必须禁用它。修改完成后，您可以重新启用该配置集。

注意

只有 CA 代理可以启用和禁用证书配置集。

例如，禁用 caCMCECserverCert 证书配置集：

# pki -c password -n caagent ca-profile-disable caCMCECserverCert

例如，启用 caCMCECserverCert 证书配置集：

# pki -c password -n caagent ca-profile-enable caCMCECserverCert

3.2.1.2. 以 Raw 格式创建证书配置集

要以 raw 格式创建新配置集：

# pki -c password -n caadmin ca-profile-add profile_name.cfg --raw

注意

在 raw 格式中，指定新的配置集 ID，如下所示：

profileId=profile_name

3.2.1.3. 使用 Raw 格式编辑证书配置文件

CA 管理员可以使用 raw 格式编辑证书配置文件，而无需手动下载配置文件。

例如，要编辑 caCMCECserverCert 配置集：

# pki -c password -n caadmin ca-profile-edit caCMCECserverCert

此命令自动下载原始格式的配置集配置，并在 VI 编辑器中打开它。关闭编辑器时，服务器上的配置集配置会更新。

编辑配置集后您不需要重启 CA。

重要

在编辑配置集前，禁用配置集。详情请查看第 3.2.1.1 节 “启用和禁用证书配置集”。

例 3.2. 以 RAW 格式编辑证书配置集

例如，要编辑 caCMCserverCert 配置集以接受多个用户提供的扩展：

禁用配置集作为 CA 代理：

# pki -c password -n caagemt ca-profile-disable caCMCserverCert

以 CA 管理员身份编辑配置集：
1. 在 VI 编辑器中下载并打开配置集：
```
# pki -c password -n caadmin ca-profile-edit caCMCserverCert
```
2. 更新配置以接受扩展。详情请查看例 B.3 “CSR 中的多个用户提供的扩展”。

将配置集启用为 CA 代理：

# pki -c password -n caagent ca-profile-enable caCMCserverCert

3.2.1.4. 删除证书配置集

删除证书配置集：

# pki -c password -n caadmin ca-profile-del profile_name

重要

在删除配置集前，禁用配置集。详情请查看第 3.2.1.1 节 “启用和禁用证书配置集”。

3.2.2. 使用基于 Java 的管理控制台管理证书注册配置集

3.2.2.1. 通过 CA 控制台创建证书配置集

为了安全起见，证书系统可强制隔离现有的证书配置集，只有管理员在代理允许后才可以编辑它。要添加新证书配置集或修改现有证书配置集，请以管理员身份执行以下步骤：

登录到证书Certificate Systemnbsp;System CA 子系统控制台。
```
pkiconsole https://server.example.com:8443/ca
```
在 Configuration 选项卡中，选择 Certificate Manager，然后选择 Certificate Profiles。
Certificate Profile Instances Management 选项卡（列出配置的证书配置集）会打开。
要创建新证书配置文件，请单击 Add。
在 Select Certificate Profile Plugin Implementation 窗口中，选择创建配置集的证书类型。
在 Certificate Profile Instance Editor 中查看配置集信息。
- 证书配置文件实例 ID.这是系统用来识别配置集的 ID。
- 证书配置文件名称.这是配置集的用户友好名称。
- 证书配置文件描述.
- 最终用户证书配置文件.这将设置请求是否必须通过配置集的输入表单进行发布。这通常设置为 true。将其设置为 false 可让通过证书管理器的证书配置集框架处理签名请求，而不是通过证书配置集的输入页面。
- 证书配置文件身份验证.这将设置身份验证方法。通过为身份验证提供实例 ID 来设置自动化身份验证。如果此字段为空，则验证方法是代理批准的注册；请求将提交到代理服务接口的请求队列。
  除非用于 TMS 子系统，否则管理员必须选择以下身份验证插件之一：
  - CMCAuth ：当 CA 代理必须批准并提交注册请求时，使用此插件。
  - CMCUserSignedAuth ：使用此插件使非代理用户注册自己的证书。
点击 OK。插件编辑器关闭，新配置集在 profile 选项卡中列出。
为新配置集配置策略、输入和输出。从列表中选择新配置集，再单击 Edit/View。
在证书配置文件规则编辑器窗口的 Policies 选项卡中设置策略。Policies 标签页列出了为配置集类型默认设置的策略。
1. 要添加策略，请点击 Add。
2. 从 Default 字段中选择默认值，在 Constraints 字段中选择与该策略关联的限制，然后单击确定。
3. 填写策略设置 ID。在发出双键对时，单独的策略会定义与每个证书关联的策略。然后填写证书配置集策略 ID，这是证书配置集策略的名称或标识符。
4. 在 Defaults 和 Constraints 选项卡中配置任何参数。
  默认值定义填充证书请求的属性，后者决定了证书的内容。这些可以是扩展、有效期期或证书中包含的其他字段。约束定义了默认值。
  如需每个默认或约束的完整详情，请参阅第 B.1 节 “默认参考” 和第 B.2 节 “约束参考”。
要修改现有策略，请选择一个策略，然后点 Edit。然后，编辑该策略的默认值和限制。
要删除策略，请选择策略，然后点 Delete。
在证书配置文件规则编辑器窗口的输入选项卡中设置输入。配置集可以有多个输入类型。
注意
除非为 TMS 子系统配置配置集，否则仅选择 cmcCertReqInput 并删除其他配置集，并点 Delete 按钮。
1. 要添加输入，请单击 Add。
2. 从列表中选择输入，然后单击确定。如需默认输入的完整详情，请参阅第 A.1 节 “输入参考”。
3. 此时会打开 New Certificate Profile Editor 窗口。设置输入 ID，然后单击确定。
可以添加和删除输入。可以选择编辑输入，但因为输入没有参数或其他设置，因此没有配置任何内容。
要删除输入，请选择输入，然后单击 Delete。
在证书配置集规则编辑器窗口的 Outputs 选项卡中设置输出。
必须为使用自动身份验证方法的任何证书配置集设置输出；不需要为使用代理批准的验证的任何证书配置集设置输出。默认情况下，所有配置集都会设置证书输出类型，并自动添加到自定义配置集。
除非为 TMS 子系统配置配置集，否则仅选择 certOutput。
可以添加和删除输出。可以选择编辑输出，但由于输出没有参数或其他设置，所以没有配置任何设置。
1. 要添加输出，请单击 Add。
2. 选择列表中的输出，然后单击确定。
3. 为输出指定名称或标识符，然后单击 OK。
  此输出将在输出标签页中列出。您可以编辑它，向此输出中的参数提供值。
要删除输出，请选择列表中的输出，然后单击 Delete。

重启 CA 以应用新配置集。

systemctl restart pki-tomcatd-nuxwdog@instance_name.service

以管理员创建配置集后，CA 代理必须在代理服务页面中批准配置集以启用该配置集。
1. 打开 CA 的服务页面。
```
https://server.example.com:8443/ca/services
```
2. 单击 Manage Certificate Profiles 链接。本页列出了管理员设置的所有证书配置文件，包括活跃和不活跃状态。
3. 点要批准的证书配置集的名称。
4. 在页面底部，单击启用按钮。

注意

如果这个配置集将与 TPS 搭配使用，则必须将 TPS 配置为识别配置集类型。这在 11.1.4 中。在红帽认证系统规划、安装和部署指南中管理智能卡 CA 配置文件.

配置集的授权方法只能使用命令行添加到配置集，如红帽证书系统规划、安装和部署指南中的文件系统中直接创建和编辑证书配置集部分。

3.2.2.2. 在控制台中编辑证书配置集

修改现有的证书配置集：

登录到代理服务页面并禁用配置集。
当一个证书配置集由代理启用后，证书配置集会在 Certificate Profile Instance Management 选项卡中被标记为证书配置集，且无法通过控制台以任何方式编辑证书配置集。
登录到证书Certificate Systemnbsp;System CA 子系统控制台。
```
pkiconsole https://server.example.com:8443/ca
```
在 Configuration 选项卡中，选择 Certificate Manager，然后选择 Certificate Profiles。
选择证书配置文件，再单击 Edit/View。
此时会出现证书 Profile Rule Editor 窗口。对默认值、约束、输入或输出的任何更改。
注意
配置集实例 ID 无法修改。
如有必要，通过拉出窗口的某一角放扩大窗口。
重启 CA 以应用更改。
在 agent services 页面中，重新启用该配置集。

注意

删除代理不会批准的任何证书配置集。出现在 Certificate Profile Instance Management 选项卡中的任何证书配置集也会出现在代理服务界面中。如果已经启用了配置集，则代理必须禁用它，然后才能从配置集列表中删除。

3.2.3. 列出证书注册配置集

在安装 CertificateCertificate Systemnbsp;System CA 时，以下预定义的证书配置集可使用并在此环境中设置。这些证书配置集是为最常见的类型证书而设计的，它们提供常见的默认值、约束、身份验证方法、输入和输出。

要在命令行中列出可用配置集，请使用 pki 工具程序。例如：

# pki -c password -n caadmin ca-profile-find
------------------
59 entries matched
------------------
  Profile ID: caCMCserverCert
  Name: Server Certificate Enrollment using CMC
  Description: This certificate profile is for enrolling server certificates using CMC.

  Profile ID: caCMCECserverCert
  Name: Server Certificate wth ECC keys Enrollment using CMC
  Description: This certificate profile is for enrolling server certificates with ECC keys using CMC.

  Profile ID: caCMCECsubsystemCert
  Name: Subsystem Certificate Enrollment with ECC keys using CMC
  Description: This certificate profile is for enrolling subsystem certificates with ECC keys using CMC.

  Profile ID: caCMCsubsystemCert
  Name: Subsystem Certificate Enrollment using CMC
  Description: This certificate profile is for enrolling subsystem certificates using CMC.

  ...
-----------------------------
Number of entries returned 20

详情请查看 pki-ca-profile(1) man page。如需更多信息，请参阅 红帽认证系统规划、安装和部署指南。

3.2.4. 显示证书注册配置集详情

例如，要显示特定的证书配置集，如 caECFullCMCUserSignedCert ：

$ pki -c password -n caadmin ca-profile-show caECFullCMCUserSignedCert
-----------------------------------
Profile "caECFullCMCUserSignedCert"
-----------------------------------
  Profile ID: caECFullCMCUserSignedCert
  Name: User-Signed CMC-Authenticated User Certificate Enrollment
  Description: This certificate profile is for enrolling user certificates with EC keys by using the CMC certificate request with non-agent user CMC authentication.

  Name: Certificate Request Input
  Class: cmcCertReqInputImpl

    Attribute Name: cert_request
    Attribute Description: Certificate Request
    Attribute Syntax: cert_request

  Name: Certificate Output
  Class: certOutputImpl

    Attribute Name: pretty_cert
    Attribute Description: Certificate Pretty Print
    Attribute Syntax: pretty_print

    Attribute Name: b64_cert
    Attribute Description: Certificate Base-64 Encoded
    Attribute Syntax: pretty_print

例如，要显示特定的证书配置集，如 caECFullCMCUserSignedCert，采用 raw 格式：

$ pki -c password -n caadmin ca-profile-show caECFullCMCUserSignedCert --raw
#Wed Jul 25 14:41:35 PDT 2018
auth.instance_id=CMCUserSignedAuth
policyset.cmcUserCertSet.1.default.params.name=
policyset.cmcUserCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl
policyset.cmcUserCertSet.6.default.params.keyUsageKeyCertSign=false
policyset.cmcUserCertSet.10.default.class_id=noDefaultImpl
policyset.cmcUserCertSet.10.constraint.name=Renewal Grace Period Constraint
output.o1.class_id=certOutputImpl

...

详情请查看 pki-ca-profile(1) man page。

3.3. 在配置集中定义密钥默认值

在创建证书配置集时，必须在 Subject Key Identifier Default 前添加 Key Default。CertificateCertificate Systemnbsp;System 在创建或应用 Subject Key Identifier Default 之前，在 Key Default 中处理密钥限制，因此如果密钥还没有被处理，在主题名称中设置密钥会失败。

例如，对象签名配置集可以定义这两个默认值：

policyset.set1.p3.constraint.class_id=noConstraintImpl
policyset.set1.p3.constraint.name=No Constraint
policyset.set1.p3.default.class_id=subjectKeyIdentifierExtDefaultImpl
policyset.set1.p3.default.name=Subject Key Identifier Default
...
policyset.set1.p11.constraint.class_id=keyConstraintImpl
policyset.set1.p11.constraint.name=Key Constraint
policyset.set1.p11.constraint.params.keyType=RSA
policyset.set1.p11.constraint.params.keyParameters=1024,2048,3072,4096
policyset.set1.p11.default.class_id=userKeyDefaultImpl
policyset.set1.p11.default.name=Key Default

在 policyset 列表中，必须在 Subject Key Identifier Default(p3)前列出 Key Default(p11)。

policyset.set1.list=p1,p2,p11,p3,p4,p5,p6,p7,p8,p9,p10

3.4. 配置配置集以启用续订

本节讨论如何为证书续订设置配置集。有关如何更新证书的详情请参考第 5.5 节 “续订证书”。

允许续订的配置集通常由 renewGracePeriodConstraint 条目使用。例如：

policyset.cmcUserCertSet.10.constraint.class_id=renewGracePeriodConstraintImpl
policyset.cmcUserCertSet.10.constraint.name=Renewal Grace Period Constraint
policyset.cmcUserCertSet.10.constraint.params.renewal.graceBefore=30
policyset.cmcUserCertSet.10.constraint.params.renewal.graceAfter=30
policyset.cmcUserCertSet.10.default.class_id=noDefaultImpl
policyset.cmcUserCertSet.10.default.name=No Default

3.4.1. 使用 Same Key 续订

允许为续订提交同一密钥的配置集，在 uniqueKeyConstraint 条目中将 allowSameKeyRenewal 参数设置为 true。例如：

policyset.cmcUserCertSet.9.constraint.class_id=uniqueKeyConstraintImpl
policyset.cmcUserCertSet.9.constraint.name=Unique Key Constraint
policyset.cmcUserCertSet.9.constraint.params.allowSameKeyRenewal=true
policyset.cmcUserCertSet.9.default.class_id=noDefaultImpl
policyset.cmcUserCertSet.9.default.name=No Default

3.4.2. 使用新密钥续订

要使用新密钥续订证书，请使用与新密钥相同的配置集。证书系统使用用户签名证书的 subjectDN 签署新证书的请求。

3.5. 为证书设置签名算法

CA 的签名证书可以用 CA 支持的任何公钥算法为它的问题签名。例如，只要 CA 支持 ECC 和 RSA 算法，ECC 签名证书就可以为 ECC 和 RSA 证书请求签名。RSA 签名证书可以使用 EC 密钥为 PKCS #10 请求签名，但如果 ECC 模块不适用于 CA，则 CA 无法使用 EC 密钥为 PKCS #10 请求签名的 CRMF 证书请求，以验证 CRMF 概念验证(POP)。

ECC 和 RSA 是公钥加密和签名算法。两种公钥算法都支持不同的密码套件，用于加密和解密数据。CA 签名证书的功能部分是使用其支持的加密套件之一发布和签名的证书。

每个配置集可以定义 CA 应该用来为通过该配置集处理的证书签名的密码套件。如果没有设置签名算法，配置集将使用任何默认签名算法。

3.5.1. 设置 CA 的默认签名算法

打开 CA 控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，展开证书管理器树。
在 General Settings 选项卡中，设置 Algorithm 下拉菜单中选择要使用的算法。

3.5.2. 在配置集中设置 Signing Algorithm Default

每个配置集都定义了一个 Signing Algorithm Default 扩展。默认有两个设置：如果证书请求指定了不同的算法，则默认算法和允许的算法列表。如果没有指定签名算法，则配置集会使用任何设置为 CA 的默认设置。

在配置集的 .cfg 文件中，算法设置了两个参数：

policyset.cmcUserCertSet.8.constraint.class_id=signingAlgConstraintImpl
policyset.cmcUserCertSet.8.constraint.name=No Constraint
policyset.cmcUserCertSet.8.constraint.params.signingAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withRSA,SHA384withEC,SHA512withEC
policyset.cmcUserCertSet.8.default.class_id=signingAlgDefaultImpl
policyset.cmcUserCertSet.8.default.name=Signing Alg
policyset.cmcUserCertSet.8.default.params.signingAlg=-

通过控制台配置 Signing Algorithm Default：

注意

在编辑配置集前，必须先由代理禁用它。

打开 CA 控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，展开证书管理器树。
单击 Certificate Profiles 项。
点 Policies 标签页。
选择 Signing Alg 策略，然后单击 Edit 按钮。
要设置默认的签名算法，请在 Defaults 选项卡中设置值。如果设为 -，则配置集将使用 CA 的默认。
要设置一个可以在证书请求中接受的允许签名算法列表，打开 Constraints 标签页，然后在 Sign AlgsAllowed 的 Value 字段中设置算法列表。
约束的可能值列在第 B.2.10 节 “签名算法” 中。

3.7. 管理主题名称和主题备用名称

证书的 主题名称 是一个可分辨的名称(DN)，其中包含标识签发证书的实体的信息。此主题名称可从标准 LDAP 目录组件（如通用名称和组织单元）构建。这些组件在 X.500 中定义。除了 - 甚至是是放置 - 主题名称，证书还可具有 主题备用名称，这是为证书设置的一种扩展集，其中包含未在 X.500 中定义的额外信息。

可以自定义主题名称和主题备用名称的命名组件。

重要

如果主题名称为空，则主题备用名称必须存在并标记为"关键"。

3.7.1. 在 Subject Name 中使用 Requester CN 或 UID

证书请求中的 cn 或 uid 值可以用来构建签发的证书的主题名称。本节演示了一个配置集，它需要在 Subject Name Constraint 中指定 naming 属性（CN 或 UID）。如果缺少 naming 属性，请求将被拒绝。

这个配置有两个部分：

CN 或 UID 格式在 Subject Name Constraint 中的模式配置中设定。
主题 DN 的格式（包括 CN 或 UID 令牌）和证书的特定后缀在 Subject Name Default 中设定。

例如，在主题 DN 中使用 CN：

policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,DC=example, DC=com

在本例中，如果一个请求进入了 CN of cn=John Smith，则证书将使用 cn=John Smith,DC=example, DC=com 的主题 DN 颁发。如果请求来自 uid=jsmith 且无 CN，则请求将被拒绝。

相同的配置用于将请求者 UID 拉取到主题 DN 中：

policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=UID=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.uid$,DC=example, DC=com

pattern 参数的格式包括在第 B.2.11 节 “主题名称约束” 和第 B.1.27 节 “主题名称默认” 中。

3.7.2. 在 Subject Alt Name 中插入 LDAP 目录属性值和其他信息

LDAP 目录或请求者提交的信息可通过使用 Subject Alt Name Extension Default 配置中匹配的变量插入到证书的主题备用名称中。此默认值设定信息的类型（格式），然后设置用于检索信息的匹配模式（变量）。例如：

policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.userCertSet.8.default.name=Subject Alt Name Constraint
policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true

这会在 subject alt name 中插入请求者的电子邮件作为第一个 CN 组件。要使用额外的组件，请在数字上递增 Type_、Pattern_ 和 Enable_ 值，如 Type_1。

配置 subject alt 名称也包括在第 B.1.23 节 “主题名称扩展默认值” 中。

将 LDAP 组件插入到证书的 subject alt 名称中：

插入 LDAP 属性值需要启用用户目录身份验证插件 SharedSecret。
1. 打开 CA 控制台。
```
pkiconsole https://server.example.com:8443/ca
```
2. 在左侧导航树中选择 Authentication。
3. 在 Authentication Instance 选项卡中，点 Add，再添加 SharedSecret 身份验证插件的实例。
4. 输入以下信息：
```
Authentication InstanceID=SharedToken
shrTokAttr=shrTok
ldap.ldapconn.host=server.example.com
ldap.ldapconn.port=636
ldap.ldapconn.secureConn=true
ldap.ldapauth.bindDN=cn=Directory Manager
password=password
ldap.ldapauth.authtype=BasicAuth
ldap.basedn=ou=People,dc=example,dc=org
```
5. 保存新的插件实例。
有关设置 CMC 共享令牌的详情，请参考第 9.4.2 节 “设置 CMC 共享 Secret”。
ldapStringAttributes 参数指示身份验证插件从用户的 LDAP 条目中读取 mail 属性的值，并将该值放在证书请求中。当值位于请求时，可以将证书配置集策略设置为插入扩展值的值。
dnpattern 参数的格式包括在第 B.2.11 节 “主题名称约束” 和第 B.1.27 节 “主题名称默认” 中。
要启用 CA 在证书扩展中插入 LDAP 属性值，请编辑配置集的配置文件，并为扩展插入策略 set 参数。例如，要在 caFullCMCSharedTokenCert 配置集中的 Subject Alternative Name 扩展中插入 mail 属性值，请更改以下代码：
```
policyset.setID.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$
```
有关编辑配置集的详情，请参考第 3.2.1.3 节 “使用 Raw 格式编辑证书配置文件”。

重启 CA。

systemctl restart pki-tomcatd-nuxwdog@instance_name.service

在本例中，通过 caFullCMCSharedTokenCert 配置集注册表单提交的证书会添加 Subject Alternative Name 扩展，并带有 requester 的邮件 LDAP 属性的值。例如：

Identifier: Subject Alternative Name - 2.5.29.17
    Critical: no
    Value:
    RFC822Name: jsmith@example.com

有许多属性可自动插入到证书中，在策略集中的任何 Pattern_ 参数中设置为令牌($X$)。常见令牌在表 3.1 “用于填充证书的变量” 中列出，默认配置集包含如何使用这些令牌的示例。

表 3.1. 用于填充证书的变量

策略设置令牌	描述
$request.auth_token.cn[0]$	请求证书的用户的 LDAP 通用名称(`cn`)属性。
$request.auth_token.mail[0]$	请求证书的用户的 LDAP 电子邮件（`邮件`）属性值。
$request.auth_token.tokencertsubject$	证书主题名称。
$request.auth_token.uid$	请求证书的用户的 LDAP 用户 ID(`uid`)属性。
$request.auth_token.userdn$	请求证书的用户 DN。
$request.auth_token.userid$	请求证书的用户的用户 ID 属性的值。
$request.uid$	请求证书的用户的用户 ID 属性的值。
$request.requestor_email$	提交请求的人的电子邮件地址。
$request.request_name$	提交请求的人员。
$request.upn$	Microsoft UPN。它的格式为 (UTF8String)1.3.6.1.4.1.311.20.2.3，$request.upn$。
$server.source$	指示服务器在主题名称中生成版本 4 个 UUID（随机号）组件。这始终具有格式 (IA5String)1.2.3.4,$server.source$.
$request.auth_token.user$	当请求由 TPS 提交时使用。请求证书的 TPS 子系统可信管理器。
$request.subject$	当请求由 TPS 提交时使用。TPS 已解析和请求的实体的主题名称 DN。例如： `cn=John.Smith.123456789,o=TMS Org`

3.7.3. 使用 SAN 扩展中的 CN 属性

有几个客户端应用程序和库不再支持使用 Subject DN 的 Common Name(CN)属性进行域名验证，在 RFC 2818 中已被弃用。相反，这些应用程序和库在证书请求中使用 dNSName Subject Alternative Name(SAN)值。

只有在根据 RFC 1034 第 3.5 节 3.5 节和具有多个组件匹配首选名称语法时，证书系统才会复制 CN。另外，现有 SAN 值会被保留。例如，基于 CN 的 dNSName 值被附加到现有 SAN。

要将证书系统配置为自动使用 SAN 扩展中的 CN 属性，请编辑用于发布证书的证书配置集。例如：

禁用配置集：

# pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-disable profile_name

编辑配置集：

# pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-edit profile_name

添加带有配置集唯一设置号的以下配置。例如：

policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
policyset.serverCertSet.12.default.name=Copy Common Name to Subject

前面的示例使用 12 作为集合号。

将新策略设置号附加到 policyset.userCertSet.list 参数。例如：
```
policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9,12
```
保存配置集。

启用配置集：

# pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-enable profile_name

注意

所有默认服务器配置集都包含 commonNameToSANDefaultImpl 默认。

3.7.4. 接受 CSR 的 SAN 扩展

在某些情况下，管理员希望在证书签名请求(CSR)中指定 Subject Alternative Name(SAN)扩展。

3.7.4.1. 将配置文件配置为来自 CSR 的检索 SAN

要允许从 CSR 检索 SAN，请使用用户扩展默认值。详情请查看第 B.1.32 节 “用户补充默认设置”。

注意

SAN 扩展可以包含一个或多个 SAN。

要接受来自 CSR 的 SAN，请在配置集中添加以下默认设置和约束，如 caCMCECserverCert ：

prefix.constraint.class_id=noConstraintImpl
prefix.constraint.name=No Constraint

prefix.default.class_id=userExtensionDefaultImpl
prefix.default.name=User supplied extension in CSR
prefix.default.params.userExtOID=2.5.29.17

3.7.4.2. 使用 SAN 生成 CSR

例如，使用 certutil 实用程序通过两个 SAN 生成 CSR：

# certutil -R -k ec -q nistp256 -d . -s "cn=Example Multiple SANs" --extSAN dns:www.example.com,dns:www.example.org -a -o /root/request.csr.p10

生成 CSR 后，请按照第 5.6.2 节 “CMC 注册过程” 中描述的步骤完成 CMC 注册。

第 4 章设置密钥存档和恢复

有关密钥存档和恢复的更多信息，请参阅 Red Hat 证书系统规划 、安装和部署指南中的存档激活、恢复和轮转密钥 部分。

本章论述了如何设置密钥恢复授权(KRA)，之前被称为 Data Recovery Manager(DRM)归档私钥并恢复用于恢复加密数据的归档密钥。

注意

本章仅讨论通过客户端密钥生成归档密钥。此处不讨论服务器端密钥生成和归档（无论是通过 TPS 启动还是通过 CA 的终止实体门户启动）。

有关智能卡密钥恢复的详情，请参考第 6.11 节 “设置服务器端密钥生成”。

有关在 CA 的 EE 门户中提供的服务器端密钥生成的详情，请参考第 5.2.2 节 “使用服务器侧密钥生成 CSR”。

注意

Gemalto SafeNet LunaSA 只支持 CKE - 密钥导出模型中的 PKI 私钥提取，且仅在非FIPS 模式中支持。LunaSA Cloning 模型和 FIPS 模式中的 CKE 模型不支持 PKI 私钥提取。

安装 KRA 后，它会加入安全域，并与 CA 对。因此，它被配置为归档和恢复私钥。但是，如果 KRA 证书由外部 CA 而不是安全域中的其中一个 CA 发布，则必须手动设置密钥存档和恢复过程。

如需更多信息，请参阅 红帽认证系统规划、安装和部署指南中的 手动设置密钥存档 部分。

注意

在克隆的环境中，需要手动设置密钥归档和恢复。如需更多信息，请参阅 Red Hat 证书系统规划、安装和部署指南中的 更新 CA-KRA Connector Information 部分。

4.1. 在控制台中配置代理验证密钥恢复

注意

虽然可以在控制台中配置密钥恢复代理数量，而 要使用的组 只能直接在 CS.cfg 文件中设置。默认情况下，控制台使用密钥恢复授权代理组。

打开 KRA 的控制台。例如：

pkiconsole https://server.example.com:8443/kra

点左侧导航树中的 Key Recovery Authority 链接。
在所需的代理数量字段中，输入用来批准密钥恢复的代理数量。

注意

有关如何在 CS.cfg 文件中配置代理批准的密钥恢复的更多信息，请参阅 红帽证书系统规划、安装和部署指南中的 "配置代理 -Approved Key Recovery "部分。

4.2. 测试密钥存档和恢复设置

注意

较新的浏览器不支持浏览器的关键存档；对于第 1 步，应该替换这些 浏览器的 CRMF 生成客户端。

测试密钥是否可以成功归档：

使用 CA 的手动用户签名和加密证书注册表单注册 2 证书。
提交请求。登录代理服务页面，并批准请求。
登录终端页面，并查看证书是否已颁发。在证书列表中，应该有两个带有连续序列号的新证书。
将证书导入 Web 浏览器。
确认密钥已被存档。在 KRA 的 agent services 页面中，选择 Show completed requests。如果密钥被成功存档，则会有有关该密钥的信息。如果没有显示密钥，请检查日志并更正问题。如果密钥已成功归档，请关闭浏览器窗口。
验证密钥。发送已签名并加密的电子邮件。收到电子邮件后，请打开它并检查消息，以查看其是否已签名并加密。消息窗口右上角应当有一个安全图标，这表示消息已签名并加密。
删除证书。再次检查加密的电子邮件；邮件客户端应该无法解密邮件。
测试归档的密钥是否可以成功恢复：
1. 打开 KRA 的代理服务页面，点 Recover Keys 链接。按照密钥所有者、序列号或公钥搜索密钥。如果密钥已成功存档，则会显示密钥信息。
2. 点 Recover。
3. 在出现的表单中，输入与私钥对应的 base-64 编码证书来恢复；使用 CA 获取此信息。如果通过提供 base-64 编码证书搜索归档的密钥，则不得在此处提供证书。
4. 确保已选中 Async Recovery 复选框，以便允许在恢复期间关闭浏览器会话。
  提示
  async 恢复是执行密钥恢复的默认和推荐方法。如果要执行同步密钥恢复，浏览器窗口将无法关闭，且在恢复过程中无法停止 KRA。
5. 根据代理方案，指定数量的代理必须授权这个密钥恢复。让代理搜索密钥恢复，然后批准启动的恢复。
6. 当所有代理都授权恢复后，下一屏幕将请求一个密码来加密带有证书的 PKCS #12 文件。
7. 下一屏幕返回一个下载 PKCS #12 blob 的链接，其中包含恢复的密钥对。按照链接，将 blob 保存到文件。
  重要
  在某些情况下，直接从 gcr-viewer 工具中的浏览器打开 PKCS #12 文件。要临时解决这个问题，请下载文件并在 gcr-viewer 中手动打开。
将密钥恢复到浏览器的数据库。将 .p12 文件导入浏览器和邮件客户端。
打开测试电子邮件。应再次显示该消息。

第 5 章请求、注册和管理证书

证书由最终用户请求和使用。虽然证书注册和续订是不仅限于管理员的、了解注册和续订流程的操作，但管理员更容易管理和创建适当的证书配置文件，如第 3.2 节 “设置证书配置集” 所述，并为每个证书类型使用适合验证方法（在第 9 章 注册证书的身份验证中进行。

本章讨论请求、接收和更新证书以用于外部证书证书；系统。有关请求和更新证书证书nbsp;System 子系统证书的详情，请参考第 16 章 管理子系统证书。

5.1. 关于注册和续订证书

注册是请求和获得证书的过程。注册过程的具体方法根据证书的类型、生成其密钥对的方法以及生成和批准证书本身的方法稍有不同。无论具体方法、证书注册（在高级别）都有相同的基本步骤：

生成证书请求(CSR)。
证书请求提交至 CA。
请求通过验证请求它的实体进行验证，确认请求是否满足用于提交它的证书配置文件规则。
申请已批准。
请求方检索新证书。

当证书达到其有效期期结束时，可以续订。

5.2. 创建证书签名请求

通常，以下方法用于生成证书请求(CSR)：

使用命令行工具生成 CSR
在支持的浏览器中生成 CSR
在应用程序内生成 CSR，如服务器的安装程序

其中一些方法支持直接提交 CSR，而有些方法则不支持。

从 RHCS 9.7 开始，支持 Server-Side 键生成来克服在较新版本的浏览器（如 Firefox v69 和 up）中消除密钥生成带来的不便性。因此，在本节中，我们将不讨论密钥生成浏览器支持。虽然没有原因认为这些浏览器的旧版本不应与旧的 RHCS 文档中所述继续工作。

从应用程序生成的 CSR 通常采用 PKCS#10 的形式。如果它们正确生成，则 RHCS 应该支持它们。

在以下小节中，我们将深入介绍 RHCS 支持的以下方法：

命令行工具
服务器侧密钥生成

5.2.1. 使用命令行工具生成 CSR

Red Hat Certificate System 支持使用以下工具创建 CSR：

certutil ：支持创建 PKCS #10 请求。
PKCS10Client ：支持创建 PKCS #10 请求。
CRMFPopClient ：支持创建 CRMF 请求。
pki client-cert-request: 支持 PKCS#10 和 CRMF 请求。

以下小节介绍了如何将这些实用程序与功能丰富的注册配置集框架搭配使用的一些示例。

5.2.1.1. 使用 `certutil`创建 CSR

这部分论述了如何使用 certutil 工具创建 CSR 的示例。

有关使用 certutil 的详情，请参考：

certutil(1) man page
certutil --help 命令的输出

5.2.1.1.1. 使用 `certutil` 创建带有 EC 密钥的 CSR

以下流程演示了如何使用 certutil 实用程序创建 Elliptic Curve(EC)密钥对和 CSR：

进入请求证书的用户或实体的证书数据库目录，例如：
```
$ cd /user_or_entity_database_directory/
```
创建二进制 CSR，并将其存储在 /user_or_entity_database_directory/request.csr 文件中：
```
$ certutil -d . -R -k ec -q nistp256 -s "CN=subject_name" -o /user_or_entity_database_directory/request-bin.csr
```
提示时输入所需的 NSS 数据库密码。
有关参数的详情，请查看 certutil(1) man page。

将创建的二进制格式 CSR 转换为 PEM 格式：

$ BtoA /user_or_entity_database_directory/request-bin.csr /user_or_entity_database_directory/request.csr

（可选）验证 CSR 文件是否正确：

$ cat /user_or_entity_database_directory/request.csr

		MIICbTCCAVUCAQAwKDEQMA4GA1UEChMHRXhhbXBsZTEUMBIGA1UEAxMLZXhhbXBs
		...

这是一个 PKCS#10 PEM 证书请求。

5.2.1.1.2. 使用 `certutil` 使用用户定义的扩展来创建 CSR

以下流程演示了如何使用 certutil 实用程序使用用户定义的扩展创建 CSR。

请注意，注册请求受 CA 定义的注册配置集的限制。请参阅例 B.3 “CSR 中的多个用户提供的扩展”。

进入请求证书的用户或实体的证书数据库目录，例如：
```
$ cd /user_or_entity_database_directory/
```
使用用户定义的 Key Usage 扩展创建 CSR，以及用户定义的扩展密钥使用扩展，并将其存储在 /user_or_entity_database_directory/request.csr 文件中：
```
$ certutil -d . -R -k rsa -g 1024 -s "CN=subject_name" --keyUsage keyEncipherment,dataEncipherment,critical --extKeyUsage timeStamp,msTrustListSign,critical -a -o /user_or_entity_database_directory/request.csr
```
提示时输入所需的 NSS 数据库密码。
有关参数的详情，请查看 certutil(1) man page。

（可选）验证 CSR 文件是否正确：

$ cat /user_or_entity_database_directory/request.csr
		Certificate request generated by NSS certutil
		Phone: (not specified)

		Common Name: user 4-2-1-2
		Email: (not specified)
		Organization: (not specified)
		State: (not specified)
		Country: (not specified)

这是一个 PKCS#10 PEM 证书请求。

5.2.1.2. 使用 `PKCS10Client`创建 CSR

这部分论述了如何使用 PKCS10Client 实用程序创建 CSR 的示例。

有关使用 PKCS10Client 的详情，请参考：

PKCS10Client(1) man page
PKCS10Client --help 命令的输出

5.2.1.2.1. 使用 `PKCS10Client` 创建 CSR

以下流程解释了如何使用 PKCS10Client 实用程序创建 Elliptic Curve(EC)密钥对和 CSR：

进入请求证书的用户或实体的证书数据库目录，例如：
```
$ cd /user_or_entity_database_directory/
```
创建 CSR，并将其存储在 /user_or_entity_database_directory/example.csr 文件中：
```
$ PKCS10Client -d . -p NSS_password -a ec -c nistp256 -o /user_or_entity_database_directory/example.csr -n "CN=subject_name"
```
有关参数的详情，请查看 PKCS10Client(1) man page。

（可选）验证 CSR 是否正确：

$ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.2.2. 使用 `PKCS10Client` 为基于 SharedSecret 的 CMC 创建 CSR

以下流程解释了如何使用 PKCS10Client 程序为基于 SharedSecret 的 CMC 创建 RSA 密钥对和 CSR。它仅与 CMC Shared Secret 身份验证方法一起使用，默认由 caFullCMCSharedTokenCert 和 caECFullCMCSharedTokenCert 配置集处理。

进入请求证书的用户或实体的证书数据库目录，例如：
```
$ cd /user_or_entity_database_directory/
```
创建 CSR，并将其存储在 /user_or_entity_database_directory/example.csr 文件中：
```
$ PKCS10Client -d . -p NSS_password -o /user_or_entity_database_directory/example.csr -y true -n "CN=subject_name"
```
有关参数的详情，请查看 PKCS10Client(1) man page。

（可选）验证 CSR 是否正确：

$ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.3. 使用 `CRMFPopClient`创建 CSR

证书请求消息格式(CRMF)是 CMC 中接受的 CSR 格式，允许密钥存档信息安全地嵌入到请求中。

本节介绍如何使用 CRMFPopClient 实用程序创建 CSR 的示例。

有关使用 CRMFPopClient 的详情，请查看 CRMFPopClient(1) man page。

5.2.1.3.1. 使用 `CRMFPopClient` 创建带有密钥 Archival 的 CSR

以下流程解释了如何使用 CRMFPopClient 实用程序创建 RSA 密钥对，并使用密钥归档选项创建 CSR：

进入请求证书的用户或实体的证书数据库目录，例如：
```
$ cd /user_or_entity_database_directory/
```

检索 KRA 传输证书：

$ pki ca-cert-find --name "DRM Transport Certificate"
		---------------
		1 entries found
		---------------
			Serial Number: 0x7
			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
			Status: VALID
			Type: X.509 version 3
			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
			Issued On: Thu Oct 22 18:26:11 CEST 2015
			Issued By: caadmin
		----------------------------
		Number of entries returned 1

导出 KRA 传输证书：

$ pki ca-cert-show 0x7 --output kra.transport

创建 CSR，并将其存储在 /user_or_entity_database_directory/example.csr 文件中：
```
$ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -v -o /user_or_entity_database_directory/example.csr
```
要创建 Elliptic Curve(EC)密钥对和 CSR，将 -a ec -t false 选项传递给该命令。
有关参数的详情，请查看 CRMFPopClient(1) man page。

（可选）验证 CSR 是否正确：

$ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.3.2. 使用 `CRMFPopClient` 为基于 SharedSecret 的 CMC 创建 CSR

以下流程解释了如何使用 CRMFPopClient 程序为基于 SharedSecret 的 CMC 创建 RSA 密钥对和 CSR。它仅与 CMC Shared Secret 身份验证方法一起使用，默认由 caFullCMCSharedTokenCert 和 caECFullCMCSharedTokenCert 配置集处理。

进入请求证书的用户或实体的证书数据库目录，例如：
```
$ cd /user_or_entity_database_directory/
```

检索 KRA 传输证书：

$ pki ca-cert-find --name "DRM Transport Certificate"
		---------------
		1 entries found
		---------------
			Serial Number: 0x7
			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
			Status: VALID
			Type: X.509 version 3
			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
			Issued On: Thu Oct 22 18:26:11 CEST 2015
			Issued By: caadmin
		----------------------------
		Number of entries returned 1

导出 KRA 传输证书：

$ pki ca-cert-show 0x7 --output kra.transport

创建 CSR，并将其存储在 /user_or_entity_database_directory/example.csr 文件中：
```
$ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -y -v -o /user_or_entity_database_directory/example.csr
```
要创建 EC 密钥对和 CSR，将 -a ec -t false 选项传递给该命令。
有关参数的详情，请查看 CRMFPopClient --help 命令的输出。

（可选）验证 CSR 是否正确：

$ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.4. 在 `PKI` CLI 中使用 `client-cert-request` 创建 CSR

pki命令行工具也可以与 client-cert-request 命令一起使用，以生成 CSR。但是，与之前讨论的工具不同，使用 pki 生成的 CSR 将直接提交到 CA。可以生成 PKCS#10 或 CRMF 请求。

生成 PKCS#10 请求的示例：

pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type pkcs10

生成 CRMF 请求的示例：

pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type crmf

成功时将返回请求 id。

提交请求后，代理可以通过使用 pki ca-cert-request-approve 命令批准它。

例如：

pki -d agent token db directory -P https -p 8443 -h host.test.com -c agent token db passwd -n <CA agent cert nickname> ca-cert-request-approve request id

如需更多信息，请参阅 pki client-cert-request --help 命令的 man page。

5.2.2. 使用服务器侧密钥生成 CSR

许多新版本的浏览器（包括 Firefox v69 和 up 以及 Chrome）都已删除了生成 PKI 密钥的功能，以及对 CRMF 进行密钥归档的支持。在 RHEL 上，可以使用 CLI（如 CRMFPopClient --help）或 pki （请参阅 pki client-cert-request --help）作为临时解决方案。

自引入令牌密钥管理系统(TMS)起，服务器端密钥注册时间已足够长，可在 KRA 中生成密钥，而不是在智能卡上本地生成密钥。Red Hat Certificate System 9 现在采用类似的机制来解决浏览器 keygen deficiy 问题。密钥在服务器上生成（特别是在 KRA 上），然后安全地传送回 PKCS#12 中的客户端。

注意

强烈建议您只对加密证书使用 Server-Side Keygen 机制。

5.2.2.1. 功能亮点

证书请求密钥在 KRA 上生成（注意：必须安装 KRA 才能使用 CA）
配置集默认插件 serverKeygenUserKeyDefaultImpl 提供选择来启用或禁用密钥存档（例如，enableArchival 参数）
支持 RSA 和 EC 密钥
支持手动（代理）批准和自动批准（例如，基于目录密码）

5.2.2.2. 使用服务器侧密钥注册证书

默认的 Sever-Side Keygen 注册配置集可在 EE 页面的 List Certificate Profiles 选项卡找到：

手动用户使用服务器端密钥注册注册

图 5.1. 需要代理手动批准的服务器端密钥生成

使用服务器端密钥生成目录验证的用户注册

图 5.2. server-Side Keygen Enrollment，在成功 LDAP uid/pwd 身份验证后将自动批准

无论如何批准请求，服务器侧密钥注册机制都需要最终用户输入 PKCS#12 软件包的密码，其中包含签发的证书以及服务器发布后生成的加密私钥。

重要

用户不应与任何人共享其密码。甚至是 CA 或 KRA 代理。

当注册请求被批准后，将生成一个 PKCS#12 软件包，并生成、

如果是手动批准，PS PKCS#12 文件将返回到批准请求的 CA 代理；然后代理应该将 PKCS#12 文件转发给用户。
如果是自动批准，PMPS PKCS#12 文件将返回到提交该请求的用户

图 5.3. 代理手动批准注册

收到 PKCS#12 文件后，用户可以使用 pkcs12util（如 pkcs12util ）将此文件导入到每个应用程序自己的用户内部证书/密钥数据库中。例如，如 Firefox nss 数据库。

5.2.2.3. 密钥恢复

如果在证书注册配置集中将 enableArchival 参数设置为 true，则在 Server-Side Keygen 注册时将存档私钥。然后，授权 KRA 代理可以恢复归档的私钥。

5.2.2.4. 其它信息

5.2.2.4.1. KRA Request Records

注意

由于这个机制的性质，在配置集中将 enableArchival 参数设为 true 时，每个 Server-Side keygen 请求有两个 KRA 请求：

一个用于请求类型 asymkeyGenRequest
不能使用 KRA 代理页面上的 List Requests 过滤此请求类型；您可以选择 Show All Requests 以查看列出的请求。
一个用于请求类型恢复

5.2.2.4.2. 审计记录

如果启用，可以观察一些审计记录：

SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST
SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST

KRA

SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST_PROCESSED
SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST_PROCESSED（尚未实施）

5.3. 配置 Internet Explorer 以注册证书

警告

以下流程不再被支持，仅保留供参考。这个功能已从 Internet Explorer 11 中弃用，Microsoft 已结束对 IE 10 的支持。

由于 Microsoft Windows 中的安全设置，因此请求并通过使用 Internet Explorer 的最终实体页面来请求和注册证书，需要额外的浏览器配置。必须将浏览器配置为信任 CA，然后才能访问 CA 的最终用户页面。

5.3.1. 关于关键限制和 Internet Explorer

Microsoft 使用某些加密供应商，它只支持 RSA 和 ECC 密钥的潜在密钥子集。这些内容列在表 5.1 “供应商和密钥大小” 中。

密钥大小支持可能会影响与 Internet Explorer 搭配使用的配置集配置。配置配置集包括在第 3 章 制作发行证书规则（证书配置文件） 中。

表 5.1. 供应商和密钥大小

算法	供应商	支持的密钥大小
ECC	Microsoft Software Key Storage Provider	nistp256 nistp384 nistp521
ECC	Microsoft 智能卡存储供应商	nistp256 nistp384 nistp521
RSA	Microsoft Base Cryptographic Provider	1024
RSA	Microsoft Strong Cryptographic Provider	1024 2048 3072 4096 8192
RSA	增强的 Cryptographic Provider	1024 2048 3072 4096 8192
RSA	Microsoft Software Key Storage Provider	1024 2048 3072 4096 8192

5.3.2. 配置 Internet Explorer

打开 Internet Explorer。
Open Tools → Internet Options → Advanced → Security，取消选择 TLS 1.2。
导入 CA 证书链。
1. 为 CA 打开 unsecured end 服务页面，例如：
```
http://server.example.com:8080/ca/ee/ca
```
2. 点 Retrieval 选项卡。
3. 点左侧菜单中的 Import CA Certificate Chain，然后选择 Download the CA certificate chain in binary form。
4. 提示时，保存 CA 证书链文件。
5. 在 Internet Explorer 菜单中，点 Tools，然后选择 Internet Options。
6. 打开内容选项卡，然后单击证书按钮。
7. 单击导入按钮。在导入窗口中，浏览并选择导入的证书链。
  导入过程会提示将哪些证书存储用于 CA 证书链。根据证书类型选择 Automatically，选择证书存储。
8. 导入证书链后，打开受信任的根证书颁发机构选项卡，以验证证书链是否已成功导入。
将 Internet Explorer 配置为提示允许使用不安全的 ActiveX 控制进行脚本编写。如果不允许这样做，且最终用户会尝试在标准（非 SSL）最终用户中注册证书，Internet Explorer 将阻断这些页面。
1. 在 Internet Explorer 菜单中，点 Tools 并选择 Internet Options。
2. 打开" 安全 "选项卡，然后单击" 自定义级别 "。
3. 在 ActiveX Controls 和 Plugins 区域中，将 Initialize 和 script ActiveX 控制的值更改为 Prompt。
导入证书链后，Internet Explorer 可以访问安全的最终用户页面。打开安全网站，例如：
```
https://server.example.com:8443/ca/ee/ca
```
打开结束服务页面时，可能有一个安全例外。将 CA 服务网站添加到 Internet Explorer 的受信任的站点列表。
1. 在 Internet Explorer 菜单中，点 Tools，然后选择 Internet Options。
2. 打开 Security 选项卡，再单击 Sites，将 CA 站点添加到可信列表中。
3. 将 CA 服务页面的安全级别设置为 Medium-High; 如果以后此安全设置的限制太强，则尝试将其重置为 Medium。
打开工具 → 兼容性视图和兼容性视图设置，然后通过添加特定站点到列表来启用兼容性视图设置。
关闭浏览器。

要验证 Internet Explorer 是否可以用来注册，请尝试注册用户证书，如第 5.4.1 节 “通过"最终用户"页面请求并接收证书” 所述。

5.4. 请求和接收证书

如第 5.1 节 “关于注册和续订证书” 中所述，生成 CSR 后，需要将其提交到 CA 以提高状态。第 5.2 节 “创建证书签名请求” 中讨论的一些方法直接向 CA 提交 CSR，而有些方法需要在单独的步骤中提交 CSR，这可能由用户执行，或者由代理预签名。

在本节中，我们将讨论 RHCS CA 支持的单独提交步骤。

第 5.4.1 节 “通过"最终用户"页面请求并接收证书”
第 5.6 节 “使用 CMC 提交证书请求”

5.4.1. 通过"最终用户"页面请求并接收证书

在 CA End Entity 门户中（例如 https://host.domain:port#/ca/ee/ca），最终用户可以使用在 Enrollment/Renewal 选项卡下的 Enrollment/Renewal 选项卡下提交其证书请求（CSR，请参阅第 5.2 节 “创建证书签名请求” 来生成 CSR）。

本节假设您具有 Base64 编码格式的 CSR，包括标记行 -----BEGIN NEW CERTIFICATE REQUEST----- 和 -----END NEW CERTIFICATE REQUEST-----。

许多默认注册配置文件都提供一个证书请求文本框，该框可以在 Base64 编码 CSR 中粘贴，以及证书请求类型选择下拉列表。

在证书注册表单中，输入所需信息。

标准要求如下：

证书请求类型.这是 PKCS#10 或 CRMF。通过子系统管理控制台创建的证书请求是 PKCS #10；通过 certutil 工具和其他实用程序创建的证书请求通常是 PKCS #10。
证书请求.粘贴 base-64 编码的 blob，包括 -----BEGIN NEW CERTIFICATE REQUEST----- 和 -----END NEW CERTIFICATE REQUEST----- 标记行。
申请人名.这是请求证书的人的通用名称。
申请人电子邮件.这是请求者的电子邮件地址。在签发证书时，代理或 CA 系统将使用此地址联系请求者。例如 ：jdoe@someCompany.com
请求者电话.这是请求者的联系电话号码。

提交的请求排队代理批准。代理需要处理并批准证书请求。

注意

某些注册配置文件可能允许使用由 Red Hat Certificate Systemnbsp 提供的 LDAP uid/pwd 验证方法自动执行（例如，Red Hat Certificate Red Hat Certificate Systemnbsp;System.在下一节中，通过这些配置集进行注册不需要手动批准。有关支持的批准方法，请参阅第 9 章 注册证书的身份验证。

如果是手动批准，一旦证书被批准并生成，您可以检索该证书。

打开证书管理器端点页面，例如：
```
https://server.example.com:8443/ca/ee/ca
```
点 Retrieval 选项卡。
填写提交证书请求时创建的请求 ID 号，然后单击 Submit。
下一页显示证书请求的状态。如果状态 已经完成，则证书有一个链接。点签发的证书链接。
新证书信息以用户用户打印格式显示，采用 base-64 编码格式，采用 PKCS #7 格式。
可以通过此页面执行以下操作：
- 要在服务器或其他应用程序上安装此证书，请滚动到"服务器"部分中安装此证书，其中包含 base-64 编码证书。
将 base-64 编码的证书（包括 -----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 标记行）复制到文本文件。保存文本文件，并使用它来将证书的副本存储在私钥所驻留的实体的安全模块中。请参阅第 14.3.2.1 节 “创建用户”。

5.5. 续订证书

本节讨论如何更新证书。有关如何设置证书续订的详情请参考第 3.4 节 “配置配置集以启用续订”。

续订证书包括重新生成证书，其属性与原始证书相同。通常，有两个类型的续订：

相同的密钥续订 是原始密钥、配置文件和请求证书，并使用相同密钥重新创建具有新有效期期限和到期日期的新证书。这可以通过以下任一方法完成：
- 通过原始配置集(CSR)重新提交原始证书请求(CSR)，或者
- 使用支持工具（如 certutil）使用原始密钥重新生成 CSR
重新标记证书需要使用相同的信息重新生成证书请求，以便生成新的密钥对。然后，CSR 通过原始配置集提交。

5.5.1. 相同的密钥续订

5.5.1.1. 重新使用 CSR

在终端实体门户上，有三种批准方法可以进行相同的密钥续订。

agent-approved 方法需要提交要续订的证书的序列号；此方法需要 CA 代理的批准。
基于目录的续订需要提交要续订的证书的序列号，并且 CA 从其当前证书目录条目中提取信息。如果 ldap uid/pwd 已被成功进行身份验证，则证书会被自动批准。
基于证书的续订使用浏览器数据库中的证书进行身份验证，并具有重新发布相同的证书。

5.5.1.1.1. 代理(Approved)或基于目录的续订

有时，必须手动批准证书续订请求，可以是 CA 代理，或者提供用户目录的登录信息。

打开发布证书的 CA 的端点服务页面（或其克隆）。
```
https://server.example.com:8443/ca/ee/ca
```
单击要使用的续订表单的名称。
输入要续订的证书的序列号。这可以采用十进制或十六进制格式。
点续订按钮。
请求已提交。对于基于目录的续订，更新的证书将自动返回。否则，代理将批准续订请求。

5.5.1.1.2. 基于证书的续订

有些用户证书直接存储在浏览器中，因此一些续订表单只需检查浏览器证书数据库来进行续订。如果可以续订证书，则 CA 会自动批准并重新发布证书。

重要

如果被续订的证书已经到期，则可能就无法用于基于证书的续订。浏览器客户端可能会禁止任何带有过期证书的 SSL 客户端身份验证。

在这种情况下，必须使用其它续订方法之一续订证书。

打开发布证书的 CA 的端点服务页面（或其克隆）。
```
https://server.example.com:8443/ca/ee/ca
```
单击要使用的续订表单的名称。
没有输入字段，因此点击续订按钮。
提示时，选择要续订的证书。
请求将被提交，并且会自动返回更新的证书。

5.5.1.2. 通过使用相同密钥生成 CSR 续订

有时，原始 CSR 可能不可用。certutil 工具允许一个使用相同键重新生成 CSR，只要该密钥对位于 NSS 数据库中。这可以通过执行以下操作来实现：

在 NSS db 中找到对应的密钥 id：
```
Certutil -d <nssdb dir> -K
```

使用特定密钥生成 CSR：

Certutil -d <nssdb dir> -R -k <key id> -s <subject DN> -o <CSR output file>

或者，如果一个密钥 与 NSS db 中的证书相关联，则可使用 nickname ：

使用现有 nickname 生成 CSR：

Certutil -d <nssdb dir> -R -k <nickname> -s <subject DN> -o <CSR output file>

5.5.2. 通过重新加密证书进行续订

由于 重新密钥进行续订基本上是使用 与旧证书相同的信息生成新 CSR，只需遵循第 5.2 节 “创建证书签名请求” 中描述的任何方法之一。请注意，请输入与旧证书相同的信息。

5.6. 使用 CMC 提交证书请求

这部分论述了使用证书管理 CMS(CMC)注册证书的步骤。

有关使用 CMC 配置和注册证书的一般信息，请参阅：

红帽认证系统规划、安装和部署指南中的 CMC 配置部分。
红帽认证系统规划、安装和部署指南中的 CMC 注册 部分。
CMCRequest(1) man page
CMCResponse(1) man page

CMC 注册方式可以满足您的不同场景的要求。第 5.6.2 节 “CMC 注册过程” 请使用 红帽认证系统规划、安装和部署指南中的 CMC 补充注册 部分，详情。另外，第 5.6.3 节 “实际 CMC 注册方案” 部分可让管理员决定使用哪些机制。

5.6.1. 使用 CMC 注册

CMC 注册允许注册客户端使用 CMCAuth 插件进行身份验证，通过代理证书预签名证书。当收到使用代理证书的有效请求签名时，证书管理器会自动发布证书。

注意

CMC 注册功能被默认启用。除非配置已更改，否则应该不需要启用 CMC 注册身份验证插件或配置集。

CMCAuth 身份验证插件还为客户端提供 CMC 撤销程序。CMC 撤销程序允许客户端具有代理证书签名的证书请求，然后将此类请求发送到证书管理器。当收到使用代理证书签名的有效请求时，证书管理器会自动撤销证书。CMC 撤销程序可使用 CMCRevoke 命令行工具创建。有关 CMCRevoke 的更多信息，请参阅第 7.2 节 “执行 CMC Revocation”。

CMC 请求可以通过浏览器终端形式提交，也可以使用 HttpClient 等工具将请求发布到适当的配置集。CMCRequest 工具生成签名证书请求，然后使用 HttpClient 工具或浏览器最终用户表单提交，以自动注册并立即接收证书。

CMCRequest 工具具有简单的命令语法，它通过 .cfg 输入文件中提供的所有配置：

CMCRequest /path/to/file.cfg

也可以使用 CMCEnroll 工具创建单个 CMC 注册程序，其语法如下：

CMCEnroll -d /agent's/certificate/directory -h password -n cert_nickname -r certrequest.file -p certDB_passwd [-c "comment"]

CMCEnroll(1) man page 中详细介绍了这些工具。

注意

在引号中包含空格的值会包括在引号中。

5.6.1.1. 测试 CMCEnroll

使用 certutil 工具创建证书请求。
将 PKCS #10 ASCII 输出复制到文本文件。
运行 CMCEnroll 工具。
例如，如果名为 request34.txt 的输入文件，代理证书存储在浏览器数据库中，则代理证书的证书通用名称是 CertificateManagerAgentsCert，并且证书数据库的密码是 secret，该命令如下：
```
CMCEnroll -d ~jsmith/.mozilla/firefox/1234.jsmith -n "CertificateManagerAgentsCert" -r /export/requests/request34.txt -p secret
```
此命令的输出存储在文件中，该文件与 .out 一起附加到文件名中。
通过端点页面提交签名证书。
1. 打开"终端"页面。
```
https://server.example.com:8443/ca/ee/ca
```
2. 从证书配置集列表中选择 CMC 注册表单。
3. 将输出文件的内容粘贴到此表单的证书请求文本区域。
4. 从粘贴的内容中删除 -----BEGIN NEW CERTIFICATE REQUEST----- 和 ----END NEW CERTIFICATE REQUEST-----。
5. 填写联系信息并提交表单。
证书会立即被处理并返回。
使用 agent 页面搜索新证书。

5.6.2. CMC 注册过程

使用以下一般流程使用 CMC 请求并发布证书：

使用以下格式创建证书签名请求(CSR)：
- PKCS #10 格式
- 证书请求消息格式(CRMF)格式
有关使用以下格式创建 CSR 的详情，请参考第 5.2 节 “创建证书签名请求”。
将 admin 证书导入到客户端 NSS 数据库。例如：
- 执行以下命令，从 .p12 文件中提取 admin 客户端证书：
```
$ openssl pkcs12 -in /root/.dogtag/instance/ca_admin_cert.p12 -clcerts -nodes -nokeys -out /root/.dogtag/instance/ca_admin_cert.crt
```
- 根据 红帽认证系统规划、安装和部署指南中的管理证书/密钥加密令牌一节中的指导，验证和导入管理客户端证书：
```
$ PKICertImport -d . -n "CA Admin - Client Certificate" -t ",," -a -i /root/.dogtag/instance/ca_admin_cert.crt -u C
```
  重要
  在导入 CA Admin 客户端证书前，请确保已导入所有中间证书和 root CA 证书。
- 导入与证书关联的私钥。
```
$ pki -c password pkcs12-import --pkcs12-file /root/.dogtag/instance/ca_admin_cert.p12 --pkcs12-password-file /root/.dogtag/instance/ca/pkcs12_password.conf
```

为 CMC 请求创建配置文件，如 /home/user_name/cmc-request.cfg，其中包含以下内容：

# NSS database directory where CA agent certificate is stored
dbdir=/home/user_name/.dogtag/nssdb/

# NSS database password
password=password

# Token name (default is internal)
tokenname=internal

# Nickname for signing certificate
nickname=subsystem_admin

# Request format: pkcs10 or crmf
format=pkcs10

# Total number of PKCS10/CRMF requests
numRequests=1

# Path to the PKCS10/CRMF request
# The content must be in Base-64 encoded format.
# Multiple files are supported. They must be separated by space.
input=/home/user_name/file.csr

# Path for the CMC request
output=/home/user_name/cmc-request.bin

详情请查看 CMCRequest(1) man page。

创建 CMC 请求：
```
$ CMCRequest /home/user_name/cmc-request.cfg
```
如果命令成功，则 CMCRequest 程序会在请求配置文件的 output 参数中指定的文件中存储 CMC 请求。

为 HttpClient 创建配置文件，如 /home/user_name/cmc-submit.cfg，您要在以后的步骤中使用该文件来向 CA 提交 CMC 请求。在创建的文件中添加以下内容：

# PKI server host name
host=server.example.com

# PKI server port number
port=8443

# Use secure connection
secure=true

# Use client authentication
clientmode=true

# NSS database directory where the CA agent certificate is stored.
dbdir=/home/user_name/.dogtag/nssdb/

# NSS database password
password=password

# Token name (default: internal)
tokenname=internal

# Nickname of signing certificate
nickname=subsystem_admin

# Path for the CMC request
input=/home/user_name/cmc-request.bin

# Path for the CMC response
output=/home/user_name/cmc-response.bin

重要

在 nickname 参数中指定的 证书的别名 必须与之前用于 CMC 请求的证书匹配。

根据您请求的证书类型，将以下参数添加到上一步中创建的配置文件中：
```
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
```
例如，对于 CA 签名证书：
```
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
```
重要
当代理在下一步中提交 CMC 请求时，这个参数中指定的配置集必须使用 CMCAuth 身份验证插件。在用户初始化的注册中，配置集必须使用 CMCUserSignedAuth 插件。详情请查看第 9.3 节 “CMC 身份验证插件”。

将 CMC 请求提交到 CA：

$ HttpClient /home/user_name/cmc-submit.cfg

要将 CMC 响应转换为 PKCS #7 证书链，将 CMC 响应文件传递给 CMCResponse 工具的 -i 参数。例如：
```
$ CMCResponse -i /home/user_name/cmc-response.bin -o /home/user_name/cert_chain.crt
```

5.6.3. 实际 CMC 注册方案

这部分论述了频繁实际的使用场景及其工作流，以便 CA 管理员决定使用哪个 CMC 方法。

有关使用 CMC 注册证书的常规过程，请参阅第 5.6.2 节 “CMC 注册过程”。

5.6.3.1. 获取系统和服务器证书

如果 LDAP 或 web 服务器等服务需要 TLS 服务器证书，则此服务器的管理员会根据服务的文档创建一个 CSR，并将其发送到 CA 的代理进行批准。将第 5.6.2 节 “CMC 注册过程” 中描述的步骤用于此过程。另外，请考虑以下要求：

注册配置集

代理必须使用第 9.3 节 “CMC 身份验证插件” 中列出的现有 CMC 配置集之一，或者创建一个使用 CMCAuth 身份验证机制的自定义配置集。

CMC 签署证书

对于系统证书，CA 代理必须生成并签署 CMC 请求。为此，请将 CMCRequest 配置文件中的 nickname 参数设置为 CA 代理的 nickname。

注意

CA 代理必须有权访问自己的私钥。

HttpClient TLS Client Nickname

在 CMCRequest 实用程序配置文件中，使用与 HttpClient 配置文件中的 TLS 客户端身份验证相同的证书。

HttpClient servlet Parameter

传递给 HttpClient 工具的配置文件中的 servlet 是指处理请求的 CMC servlet 和注册配置文件。

根据您请求的证书类型，在上一步中创建的配置文件中添加以下条目之一：

对于 CA 签名证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert

对于 KRA 传输证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCkraTransportCert

对于 OCSP 签名证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCocspCert

对于审计签名证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCauditSigningCert

对于子系统证书：

对于 RSA 证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCsubsystemCert

对于 ECC 证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCsubsystemCert

对于 TLS 服务器证书：

对于 RSA 证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert

对于 ECC 证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCserverCert

对于管理员证书：

servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert

详情：

当代理预签署 CSR 时，由于代理检查 CSR 来进行识别，因此该验证身份被视为已建立的识别。不需要额外的 CMC 特定的身份证。
PKCS #10 文件已提供 Possession 信息，且不需要额外的 Possession(POP)。
在代理预批准的请求中，必须禁用 PopLinkWittnessV2 功能，因为代理会检查身份识别。

5.6.3.2. 获取用户的第一个签名证书

可以通过两种方式批准用户的第一个签名证书：

代理为 CMC 请求签名。请参阅第 5.6.3.2.1 节 “使用代理证书签名 CMC 请求”。
证书注册通过共享 Secret 进行身份验证。请参阅第 5.6.3.2.2 节 “使用共享 Secret 对证书注册进行身份验证”。

5.6.3.2.1. 使用代理证书签名 CMC 请求

使用代理证书签名 CMC 请求的过程与第 5.6.3.1 节 “获取系统和服务器证书” 中描述的系统和服务器证书相同。唯一的不同之处在于用户创建 CSR，并将其发送到 CA 代理进行批准。

5.6.3.2.2. 使用共享 Secret 对证书注册进行身份验证

当用户希望获取第一个签名证书时，代理无法批准请求，如第 5.6.3.2.1 节 “使用代理证书签名 CMC 请求” 所述，您可以使用 Shared Token。使用这个令牌，用户可以获取第一个签名证书。然后，此证书可用于签署用户的其他证书。

在这种情况下，使用 Shared Secret 机制获取用户的第一个签名证书。将以下信息与第 5.6.2 节 “CMC 注册过程” 一起使用：

以用户或 CA 管理员创建共享令牌。详情请参阅 红帽证书系统规划、安装和部署指南中的 创建共享 Secret 令牌 部分。
请注意：
- 如果创建令牌，用户必须将令牌发送到 CA 管理员。
- 如果 CA 管理员创建了令牌，管理员必须向用户共享用于生成令牌的密码。使用安全的方式传输密码。
作为 CA 管理员，将 Shared Token 添加到 LDAP 中的用户条目中。详情请参阅 Red Hat 证书系统规划、安装和部署指南中的 第 9.4.2.1 节 “将 CMC 共享 Secret 添加到用于证书注册的用户条目” 和 启用 CMC Shared Secret 功能 部分。
使用传递给 CMCRequest 工具的配置文件中的以下参数：
- identification.enable
- witness.sharedSecret
- identityProofV2.enable
- identityProofV2.hashAlg
- identityProofV2.macAlg
- request.useSharedSecret
- request.privKeyId
如果 CA 需要，还要使用传递给 CMCRequest 工具的配置文件中的以下参数：
- popLinkWitnessV2.enable
- popLinkWitnessV2.keyGenAlg
- popLinkWitnessV2.macAlg

5.6.3.3. 为用户获取仅限加密的证书

本节论述了获取只使用加密的证书（使用现有用户签名证书签名的证书）的工作流：

注意

如果用户拥有多个用于不同使用情况的证书（在签名的情况下），用户必须首先获取签名证书。用户拥有签名证书后，就可以使用它进行概念验证，而无需设置并依赖 CMC 共享 Secret 机制。

有关获取用户的第一个签名证书的详情，请参考第 5.6.3.2 节 “获取用户的第一个签名证书”。

作为用户：

使用存储在网络安全服务(NSS)数据库中或包含用户签名证书和密钥的智能卡中的加密令牌。
以 PKCS #10 或 CRMF 格式生成 CSR。
注意
如果需要密钥归档，请使用 CRMF 格式。
生成 CMC 请求。
由于这是仅加密的证书，因此私钥无法签名。因此，不包括概念验证(POP)。因此，注册需要两个步骤：如果初始请求成功，则以 EncryptedPOP 控制形式生成 CMC 状态。然后，用户使用响应并生成包含 DecryptedPOP 控制的 CMC 请求，并在第二步提交它。
1. 对于第一步，除了默认参数外，用户还必须在传递到 CMCRequest 工具的配置文件中设置以下参数：
  - identification.enable
  - witness.sharedSecret
  - identityProofV2.enable
  - identityProofV2.hashAlg
  - identityProofV2.macAlg
  - popLinkWitnessV2.enable （CA 需要）
  - popLinkWitnessV2.keyGenAlg （CA 需要）
  - popLinkWitnessV2.macAlg （如果需要）
  - request.privKeyId
  详情请查看 CMCRequest(1) man page。
  响应包含：
  - CMC 加密 POP 控制
  - 使用 POP 所需 错误进行 CMCStatusInfoV2 控制
  - 请求 ID
2. 对于第二个步骤，除了默认参数外，用户还必须在传递到 CMCRequest 工具的配置文件中设置以下参数：
  - decryptedPop.enable
  - encryptedPopResponseFile
  - decryptedPopRequestFile
  - request.privKeyId
  详情请查看 CMCRequest(1) man page。

5.6.3.3.1. 使用密钥 Archival 的只加密证书示例

要执行密钥存档的注册，生成 CMC 请求，该请求包含在 CRMF 请求中包含该用户的加密私钥。以下流程假设该用户已经拥有了签名证书。此签名证书的 nickname 在流程中的配置文件中设置。

注意

以下步骤描述了两个条带的提示与加密密钥一起使用，该密钥无法用于签名。如果您使用可签署证书的密钥，请将 -q POP_SUCCESS 选项而不是 -q POP_NONE 传递给 single-trip 的 CRMFPopClient 实用程序。

有关将 CRMFPoPClient 与 POP_SUCCESS 搭配使用，请参阅第 5.2.1.3.1 节 “使用 CRMFPopClient 创建带有密钥 Archival 的 CSR” 和第 5.2.1.3.2 节 “使用 CRMFPopClient 为基于 SharedSecret 的 CMC 创建 CSR”。

搜索 KRA 传输证书。例如：

$ pki cert-find --name KRA_transport_certificate_subject_CN

使用您在上一步中检索的 KRA 传输证书的序列号，将证书存储在文件中。例如，要在 /home/user_name/kra.cert 文件中存储带有 12345 序列号的证书：
```
$ pki cert-show 12345 --output /home/user_name/kra.cert
```
使用 CRMFPopClient 实用程序：
- 使用密钥归档创建 CSR：
  1. 进入请求证书的用户或实体的证书数据库目录，例如：
    $ cd /home/user_name/
  2. 使用 CRMFPopClient 实用程序创建 CRMF 请求，其中 RSA 私钥由 KRA 传输证书包装。例如，将请求存储在 /home/user_name/crmf.req 文件中：
    $ CRMFPopClient -d . -p token_password -n subject_DN -q POP_NONE \ -b /home/user_name/kra.cert -w "AES/CBC/PKCS5Padding" \ -v -o /home/user_name/crmf.req
    记录命令显示的私钥的 ID。在第二个行的配置文件中，需要后续步骤中的 request.privKeyId 参数作为值。

为 CRMRequest 实用程序创建一个配置文件，如 /home/user_name/cmc.cfg，其中包含以下内容：

#numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#input: full path for the PKCS10 request or CRMF request,
#the content must be in Base-64 encoded format
input=/home/user_name/crmf.req

#output: full path for the CMC request in binary format
output=/home/user_name/cmc.req

#tokenname: name of token where agent signing cert can be found
#(default is internal)
tokenname=internal

#nickname: nickname for user certificate which will be used
#to sign the CMC full request.
nickname=signing_certificate

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert8.db which stores the agent certificate
password=password

#format: request format, either pkcs10 or crmf
format=crmf

创建 CMC 请求：
```
$ CMCRequest /home/user_name/cmc.cfg
```
如果命令成功，则 CMCRequest 程序会在请求配置文件的 output 参数中指定的文件中存储 CMC 请求。

为 HttpClient 创建配置文件，如 /home/user_name/cmc-submit.cfg，您要在以后的步骤中使用该文件来向 CA 提交 CMC 请求。在创建的文件中添加以下内容：

#host: host name for the http server
host=server.example.com

#port: port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be in
#binary format
input=/home/user_name/cmc.req

#output: full path for the response in binary format
output=/home/user_name/cmc-response_round_1.bin

#tokenname: name of token where TLS client authentication cert can be found
#(default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=/home/user_name/.dogtag/nssdb/

#clientmode: true for client authentication, false for no client authentication
#This parameter will be ignored if secure=false
clientmode=true

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=signing_certificate

#servlet: servlet name
servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserSignedCert

将 CMC 请求提交到 CA：
```
$ HttpClient /home/user_name/cmc-submit.cfg
```
如果命令成功，HTTPClient 程序会在配置文件的 output 参数中指定的文件中存储 CMC 响应。

通过将响应文件传递给 CMCResponse 实用程序来验证响应。例如：

$ CMCResponse -d /home/user_name/.dogtag/nssdb/ -i /home/user_name/cmc-response_round_1.bin

如果第一个条带成功，CMCResponse 会显示类似如下的输出：

Certificates:
		Certificate:
				Data:
						Version:  v3
						Serial Number: 0x1
						Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
						Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
						Validity:
								Not Before: Wednesday, May 17, 2017 6:06:50 PM PDT America/Los_Angeles
								Not  After: Sunday, May 17, 2037 6:06:50 PM PDT America/Los_Angeles
						Subject: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
...
Number of controls is 3
Control #0: CMC encrypted POP
	 OID: {1 3 6 1 5 5 7 7 9}
		 encryptedPOP decoded
Control #1: CMCStatusInfoV2
	 OID: {1 3 6 1 5 5 7 7 25}
	 BodyList: 1
	 OtherInfo type: FAIL
		 failInfo=POP required
Control #2: CMC ResponseInfo
	 requestID: 15

对于第二个条带，为 Decrypt edPOP 创建配置文件，如 /home/user_name/cmc_DecryptedPOP.cfg，您要在以后的步骤中使用。在创建的文件中添加以下内容：

#numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#input: full path for the PKCS10 request or CRMF request,
#the content must be in Base-64 encoded format
#this field is actually unused in 2nd trip
input=/home/user_name/crmf.req

#output: full path for the CMC request in binary format
#this field is actually unused in 2nd trip
output=/home/user_name/cmc2.req

#tokenname: name of token where agent signing cert can be found
#(default is internal)
tokenname=internal

#nickname: nickname for agent certificate which will be used
#to sign the CMC full request.
nickname=signing_certificate

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert8.db which stores the agent
#certificate
password=password

#format: request format, either pkcs10 or crmf
format=crmf

decryptedPop.enable=true
encryptedPopResponseFile=/home/user_name/cmc-response_round_1.bin
request.privKeyId=-25aa0a8aad395ebac7e6a19c364f0dcb5350cfef
decryptedPopRequestFile=/home/user_name/cmc.DecryptedPOP.req

创建 DecryptPOP CMC 请求：
```
$ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg
```
如果命令成功，CM CRequest 程序会在请求配置文件的 decryptedPopRequestFile 参数中指定的文件中存储 CMC 请求。

为 HttpClient 创建配置文件，如 /home/user_name/decrypted_POP_cmc-submit.cfg，您可以使用该文件来向 CA 提交 DecryptedPOP CMC 请求。在创建的文件中添加以下内容：

#host: host name for the http server
host=server.example.com

#port: port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be in binary format
input=/home/user_name/cmc.DecryptedPOP.req

#output: full path for the response in binary format
output=/home/user_name/cmc-response_round_2.bin

#tokenname: name of token where TLS client authentication cert can be found (default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=/home/user_name/.dogtag/nssdb/

#clientmode: true for client authentication, false for no client authentication
#This parameter will be ignored if secure=false
clientmode=true

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=singing_certificate

#servlet: servlet name
servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserCert

将 DecryptedPOP CMC 请求提交到 CA：
```
$ HttpClient /home/user_name/decrypted_POP_cmc-submit.cfg
```
如果命令成功，HTTPClient 程序会在配置文件的 output 参数中指定的文件中存储 CMC 响应。

要将 CMC 响应转换为 PKCS #7 证书链，将 CMC 响应文件传递给 CMCResponse 工具的 -i 参数。例如：

$ CMCResponse -i /home/user_name/cmc-response_round_2.bin -o /home/user_name/certs.p7

另外，要以 PEM 格式显示各个证书，请将 -v 传递给实用程序。

如果第二个条带成功，则 CMCResponse 会显示类似如下的输出：

Certificates:
		Certificate:
				Data:
						Version:  v3
						Serial Number: 0x2D
						Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
						Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
						Validity:
								Not Before: Thursday, June 15, 2017 3:43:45 PM PDT America/Los_Angeles
								Not  After: Tuesday, December 12, 2017 3:43:45 PM PST America/Los_Angeles
						Subject: CN=user_name,UID=example,OU=keyArchivalExample
...
Number of controls is 1
Control #0: CMCStatusInfo
	 OID: {1 3 6 1 5 5 7 7 1}
	 BodyList: 1
	 Status: SUCCESS

5.7. 执行大量问题

当管理员需要同时提交并生成大量证书时，可以有实例。与 CertificateCertificate Systemnbsp 提供的工具组合；系统可用于发布包含 CA 的证书请求的文件。这个示例步骤使用 PKCS10Client 命令生成 requests 和 sslget 命令，将请求发送到 CA。

由于已编写此过程，需要设置多个变量来识别 CA（主机、端口）以及用于身份验证的项目（代理证书和证书数据库和密码）。例如，通过在终端中导出会话设置这些变量：
```
export d=/var/tmp/testDir
export p=password
export f=/var/tmp/server.csr.txt
export nick="CA agent cert"
export cahost=1.2.3.4
export caport=8443
```
注意
本地系统必须具有一个有效的安全数据库，其中包含代理的证书。设置数据库：
1. 从浏览器中导出或下载代理用户证书和密钥，并保存到文件，如 agent.p12。
2. 如有必要，为安全数据库创建一个新目录。
  mkdir ${d}
3. 如有必要，创建新的安全数据库。
  certutil -N -d ${d}
4. 停止证书证书 Systemnbsp;System 实例。
  systemctl stop pki-tomcatd@instance_name.service
5. 使用 pk12util 导入证书。
  # pk12util -i /tmp/agent.p12 -d ${d} -W p12filepassword
  如果这个过程成功，命令会输出以下输出：
  pk12util: PKCS12 IMPORT SUCCESSFUL
6. 启动证书证书系统nbsp;System 实例。
  systemctl start pki-tomcatd@instance_name.service
必须设置两个额外的变量。标识要用于处理请求的 CA 配置集的变量，以及用于发送 post 语句的变量，以提供配置集表单的信息。
```
export post="cert_request_type=pkcs10&xmlOutput=true&profileId=caAgentServerCert&cert_request="
export url="/ca/ee/ca/profileSubmitSSLClient"
```
注意
本例将证书请求提交到 caAgentServerCert 配置集（在 post 语句的 profileId 元素中标识）。可以使用任何证书配置集，包括自定义配置集。

测试变量配置。

echo ${d} ${p} ${f} ${nick} ${cahost} ${caport} ${post} ${url}

使用（本例）Phy 10Client 生成证书 请求：

time for i in {1..10}; do /usr/bin/PKCS10Client -d ${d} -p ${p} -o ${f}.${i} -s "cn=testms${i}.example.com"; cat ${f}.${i} >> ${f}; done

perl -pi -e 's/\r\n//;s/\+/%2B/g;s/\//%2F/g' ${f}

wc -l ${f}

检查 CA 的状态和事务日志。

/etc/init.d/pki-ca status

tail -f /var/log/pki-ca/transactions&

使用 sslget 将上一步中创建的批量证书请求文件提交到 CA 配置集接口。4例如：

cat ${f} | while read thisreq; do /usr/bin/sslget -n "${nick}" -p ${p} -d ${d} -e ${post}${thisreq} -v -r ${url} ${cahost}:${caport}; done

5.8. 在 Cisco Router 上注册证书

简单的证书注册协议(SCEP)由 Cisco 设计，是路由器与证书授权机构（如 CA）进行通信的方法，为路由器注册证书。

通常，路由器安装程序在路由器中输入 CA 的 URL 和质询密码（也称为一次性 PIN），并发出命令来启动注册。然后，路由器通过 SCEP 与 CA 通信来生成、请求并检索证书。路由器也可以使用 SCEP 检查待处理请求的状态。

5.8.1. 启用 SCEP 注册

出于安全考虑，CA 中默认禁用 SCEP 注册。要允许路由器注册，必须为 CA 手动启用 SCEP 注册。

停止 CA 服务器，以便您可以编辑配置文件。
```
systemctl stop pki-tomcatd@instance_name.service
```

打开 CA 的 CS.cfg 文件。

vim /var/lib/pki/instance_name/ca/conf/CS.cfg

将 ca.scep.enable 设置为 true。如果参数不存在，则使用参数添加一行。
```
ca.scep.enable=true
```

重启 CA 服务器。

systemctl start pki-tomcatd@instance_name.service

5.8.2. 配置 SCEP 安全设置

管理员可通过几个不同的参数来设置 SCEP 连接的特定安全要求，如不使用相同的证书注册和常规证书注册，或者设置允许的加密算法以防止降级连接强度。这些参数在表 5.2 “SCEP 安全性的配置参数” 中列出。

表 5.2. SCEP 安全性的配置参数

参数	描述
ca.scep.encryptionAlgorithm	设置默认或首选的加密算法。
ca.scep.allowedEncryptionAlgorithms	设定以逗号分隔的加密算法列表。
ca.scep.hashAlgorithm	设置默认值或首选的哈希算法。
ca.scep.allowedHashAlgorithms	设定以逗号分隔的允许哈希算法列表。
ca.scep.nickname	为 SCEP 通信提供证书的别名。除非设置了此参数，否则默认值是使用 CA 的密钥对和证书。
ca.scep.nonceSizeLimit	设定 SCEP 请求的最大值（以字节为单位）。默认值为 16 字节。

为 SCEP 注册设置安全设置：

停止 CA 服务器，以便您可以编辑配置文件。
```
systemctl stop pki-tomcatd@instance_name.service
```

打开 CA 的 CS.cfg 文件。

vim /var/lib/pki/instance_name/ca/conf/CS.cfg

设置所需的安全参数，如表 5.2 “SCEP 安全性的配置参数” 中列出的。如果参数不存在，则将其添加到 CS.cfg 文件中。

ca.scep.encryptionAlgorithm=DES3
ca.scep.allowedEncryptionAlgorithms=DES3
ca.scep.hashAlgorithm=SHA1
ca.scep.allowedHashAlgorithms=SHA1,SHA256,SHA512
ca.scep.nickname=Server-Cert
ca.scep.nonceSizeLimit=20

重启 CA 服务器。

systemctl start pki-tomcatd@instance_name.service

5.8.3. 配置路由器进行服务注册

注意

并非所有路由器 IOS 版本都具有相关的加密功能。确保固件镜像具有认证认证机构的互操作性功能。CertificateCertificate Systemnbsp;System SCEP 支持在运行 IOS C2600 Software(C2600-JK9S-M)、版本 12.2(40)、RELEASE SOFTWARE(fc1)的 Cisco 2611 路由器上测试。

在路由器上注册 SCEP 证书之前，请确保正确配置了路由器：

路由器必须配置有 IP 地址、DNS 服务器和路由信息。
路由器的日期/时间必须正确。
必须配置路由器的主机名和 dnsname。

有关配置路由器硬件的说明，请参阅路由器文档。

5.8.4. 为路由器生成 SCEP 证书

以下过程详细介绍了如何为路由器生成 SCEP 证书。

选择随机 PIN。
将 PIN 和路由器的 ID 添加到 flatfile.txt 文件中，以便路由器可以直接与 CA 进行身份验证。例如：
```
vim /var/lib/pki/instance_name/ca/conf/flatfile.txt

UID:172.16.24.238
PWD:Uojs93wkfd0IS
```
务必在 PWD 行后插入空行。
路由器的 IP 地址可以是 IPv4 地址或 IPv6 地址。
第 9.2.4 节 “配置平面文件身份验证” 中描述了使用无格式文件身份验证。
登录到路由器的控制台。在本例中，路由器的名称为 scep ：
```
scep>
```
启用特权命令。
```
scep> enable
```
进入配置模式。
```
scep# conf t
```

从 root 用户开始，为证书链中每个 CA 导入 CA 证书。例如，以下命令序列将链中两个 CA 证书导入到路由器中：

scep(config)# crypto ca trusted-root1
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 1
scep(config)# crypto ca trusted-root0
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 0

设置 CA 身份，并输入用于访问 SCEP 注册程序的 URL。例如，对于 CA：

scep(config)# crypto ca identity CA
scep(ca-identity)# enrollment url http://server.example.com:8080/ca/cgi-bin
scep(ca-identity)# crl optional

获取 CA 的证书。

scep(config)# crypto ca authenticate CA
Certificate has the following attributes:
Fingerprint: 145E3825 31998BA7 F001EA9A B4001F57
% Do you accept this certificate? [yes/no]: yes

生成 RSA 密钥对。

scep(config)# crypto key generate rsa
The name for the keys will be: scep.server.example.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]:
Generating RSA keys ...
[OK]

最后，在路由器上生成证书。

scep(config)# crypto ca enroll CA
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.

Password: secret
Re-enter password: secret

% The subject name in the certificate will be: scep.server.example.com
% Include the router serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: 57DE391C
% Include an IP address in the subject name? [yes/no]: yes
% Interface: Ethernet0/0
% Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.

% Fingerprint:D89DB555 E64CC2F7 123725B4 3DBDF263

Jan 12 13:41:17.348: %CRYPTO-6-CERTRET: Certificate received from Certificate

关闭配置模式。
```
 scep(config)# exit
```

为确保路由器已正确注册，请列出存储在路由器中的所有证书。

scep# show crypto ca certificates
Certificate
 Status: Available
 Certificate Serial Number: 0C
 Key Usage: General Purpose
 Issuer:
	CN = Certificate Authority
	 O = Sfbay Red hat Domain 20070111d12
 Subject Name Contains:
	Name: scep.server.example.com
	IP Address: 10.14.1.94
	Serial Number: 57DE391C
 Validity Date:
	start date: 21:42:40 UTC Jan 12 2007
	end date: 21:49:50 UTC Dec 31 2008
 Associated Identity: CA

CA Certificate
 Status: Available
 Certificate Serial Number: 01
 Key Usage: Signature
 Issuer:
	CN = Certificate Authority
	 O = Sfbay Red hat Domain 20070111d12
 Subject:
	CN = Certificate Authority
	 O = Sfbay Red hat Domain 20070111d12
 Validity Date:
	start date: 21:49:50 UTC Jan 11 2007
	end date: 21:49:50 UTC Dec 31 2008
 Associated Identity: CA

5.8.5. 使用从属 CA

在路由器可以向 CA 验证前，CA 的证书链中的每个 CA 证书都必须导入到路由器中，从 root 开始。例如，以下命令序列将链中两个 CA 证书导入到路由器中：

scep(config)# crypto ca trusted-root1
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 1
scep(config)# crypto ca trusted-root0
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 0

如果 CA 证书没有设置 CRL 分布点扩展，请通过将它设置为可选来关闭 CRL 要求：

scep(ca-root)# crl optional

之后，按照第 5.8.4 节 “为路由器生成 SCEP 证书” 所述设置 CA 身份。

5.8.6. 重新注册路由器

在使用新证书重新注册路由器前，必须移除现有的配置。

删除（零化）现有密钥。

scep(config)# crypto key zeroize rsa
% Keys to be removed are named scep.server.example.com.
Do you really want to remove these keys? [yes/no]: yes

删除 CA 身份。

scep(config)# no crypto ca identity CA
% Removing an identity will destroy all certificates received from
the related Certificate Authority.

Are you sure you want to do this? [yes/no]: yes
% Be sure to ask the CA administrator to revoke your certificates.

No enrollment sessions are currently active.

5.8.7. 启用调试

路由器在 SCEP 操作期间通过启用 debug 语句提供额外的调试。

 scep# debug crypto pki callbacks
 Crypto PKI callbacks debugging is on

 scep# debug crypto pki messages
 Crypto PKI Msg debugging is on

 scep# debug crypto pki transactions
 Crypto PKI Trans debugging is on

 scep#debug crypto verbose
 verbose debug output debugging is on

5.8.8. 使用 SCEP 发出 ECC 证书

默认情况下，ECC CA 不支持 SCEP out。但是，可以通过使用指定的 RSA 证书来处理以下两个区域的每个区域来临时解决这个问题：

加密/解密证书 - 指定具有加密/解密能力的 RSA 证书；（以下示例中的scepRSAcert）
签名证书 - 获取要在客户端使用 RSA 证书以签名目的，而不是自签名证书。（以下示例中的认证证书）

例如，如果 scepRSAcert cert 是加密/解密证书，其签名证书是签名证书：

sscep enroll -c ca.crt -e scepRSAcert.crt -k local.key -r local.csr -K sign.key -O sign.crt -E 3des -S sha256 -l cert.crt -u 'http://example.example.com:8080/ca/cgi-bin/pkiclient.exe'

第 6 章使用并配置令牌管理系统：TPS 和 TKS

本章提供了使用硬件安全模块（也称为 HSM 或令牌）的步骤，以生成和存储证书证书证书证书证书证书和密钥。

本章仅包含管理过程。有关令牌管理系统后概念的常规信息，请查看 Red Hat 证书系统 9 规划、安装和部署指南。

6.1. TPS 配置集

注意

有关一般信息，请参阅 红帽认证系统 9 规划、安装和部署指南中的 TPS 配置集 部分。

与 CA 注册配置文件（在独立文件或 LDAP 中定义）不同，TPS 配置文件（也称为令牌类型）在 TPS 配置文件 CS.cfg 中定义。

TPS 配置集（令牌类型）配置参数以以下格式设置：

op.<explicit op>.<profile id>.<implicit op>.<key type>.*

在上面的中，<explicit op> 和 & lt;implicit op > 是下面 TPS Operations 部分讨论的显式和隐式操作之一，&lt ;key type& gt; 是为每个证书类型给出的名称。

配置参数示例可能类似以下示例：

op.enroll.userKey.keyGen.encryption.*

6.2. TPS 操作

显式操作

显式操作 是用户调用的操作。显式操作包括 注册 (op.enroll.*)、格式化 (op.format.*)和 pinReset (op.pinReset.*)。

隐式操作

一个隐式操作是操作，当处理显式操作时，会发生因为令牌的策略或状态而发生的操作。隐式操作包括 keyGen (op.enroll.userKey.keyGen.*)、续订 (op.enroll.userKey.renewal.*)、update.applet (op.enroll.userKey.update.applet.*)和密钥更新(op.enroll.userKey.update.symmetrics.*)。

一些隐式操作按密钥类型进行控制。这包括 恢复、serverKeygen 和 revocation 。

以下 TPS 配置集示例指定要在服务器端生成的用户密钥：

op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true

另外，以下示例告知 TPS，其密钥被入侵的令牌应在状态过渡过程中撤销撤销原因 1 的撤销证书：

op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert=true
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert.reason=1

根据 RFC 5280，可以撤销的原因及其代码，如下所示：

表 6.1. 撤销原因和代码

原因	代码
Unspecified	0
keyCompromise	1
CACompromise	2
affiliationChanged	3
取代	4
cessationOfOperation	5
certificateHold	6
removeFromCRL	8
privilegeWithdrawn	9
AACompromise	10

6.3. 令牌策略

本节提供了可基于 TPS UI 针对每个令牌应用的令牌策略列表。Ech 部分将显示每个策略如何反映在配置中。

注意

有关一般信息，请参阅 红帽认证系统 9 规划、安装和部署指南中的 令牌策略 部分。

策略是每个策略的集合，每个策略由分号(";"")分开。每个策略都可以打开或关闭关键字 YES 或 NO。以下列表中的每个策略都会在其默认值中引入 - 如果策略字符串中不存在该设置，则由 TPS 执行的操作。

RE_ENROLL=YES

此策略控制令牌是否允许重新注册操作。这允许重新注册的令牌（带有证书）并给出新的令牌。如果设置为 NO，则服务器在尝试重新注册时会返回错误。

这个策略不需要特殊配置。注册将继续进行标准注册配置文件，该配置文件可能会最初注册令牌。

RENEW=NO;RENEW_KEEP_OLD_ENC_CERTS=YES

续订可让令牌在其配置集生成的证书放置在令牌上。如果 RENEW 设为 YES，则从企业安全客户端(ESC)的简单注册将会导致续订，而不是如上所示的重新注册。

RENEW_KEEP_OLD_ENC_CERTS 设置决定续订操作是否保留加密证书的旧版本。保留前面的证书可让用户访问使用旧证书加密的数据。将此选项设置为 NO，表示任何使用旧证书加密的任何内容都将不再可以被恢复。

配置：

op.enroll.userKey.renewal.encryption.ca.conn=ca1
op.enroll.userKey.renewal.encryption.ca.profileId=caTokenUserEncryptionKeyRenewal
op.enroll.userKey.renewal.encryption.certAttrId=c2
op.enroll.userKey.renewal.encryption.certId=C2
op.enroll.userKey.renewal.encryption.enable=true
op.enroll.userKey.renewal.encryption.gracePeriod.after=30
op.enroll.userKey.renewal.encryption.gracePeriod.before=30
op.enroll.userKey.renewal.encryption.gracePeriod.enable=false
op.enroll.userKey.renewal.keyType.num=2
op.enroll.userKey.renewal.keyType.value.0=signing
op.enroll.userKey.renewal.keyType.value.1=encryption
op.enroll.userKey.renewal.signing.ca.conn=ca1
op.enroll.userKey.renewal.signing.ca.profileId=caTokenUserSigningKeyRenewal
op.enroll.userKey.renewal.signing.certAttrId=c1
op.enroll.userKey.renewal.signing.certId=C1
op.enroll.userKey.renewal.signing.enable=true
op.enroll.userKey.renewal.signing.gracePeriod.after=30
op.enroll.userKey.renewal.signing.gracePeriod.before=30
op.enroll.userKey.renewal.signing.gracePeriod.enable=false

这种类型的续订配置会对基本 用户Key 标准注册配置集进行镜像，并带有几个特定于续订的设置。需要这种奇偶校验的原因是，我们需要续订最初注册到令牌中的 certs 数量和类型，然后再进行续订。

FORCE_FORMAT=NO

如果启用，这个策略会导致每个注册操作都提示操作。这是一个最后一个步骤选项，允许在不用户将其返回到管理员的情况下重置令牌。如果设置为 YES，则用户启动的每个注册操作将导致格式发生，可能会将令牌重置为已格式化状态。

不需要额外的配置。为执行标准格式操作相同的 TPS 配置集出现简单的格式。

PIN_RESET=NO

此策略决定了已经注册的令牌是否可以使用 ESC 执行显式"pin reset"更改。此值必须设置为 YES，否则尝试的操作将拒绝服务器出错。

配置：

op.enroll.userKey.pinReset.enable=true
op.enroll.userKey.pinReset.pin.maxLen=10
op.enroll.userKey.pinReset.pin.maxRetries=127
op.enroll.userKey.pinReset.pin.minLen=4

在上例中，minLen 和 maxLen 的设置会限制选择密码的长度，maxRetries 设置将令牌设置为仅在锁定前重试次数。

可使用最新的 TPS 用户界面轻松编辑 TPS 策略。导航到需要更改策略的令牌，并点击 Edit。这将弹出一个对话框，供您编辑字段，该字段是连续运行半以冒号分隔的策略的集合。每个支持的策略都必须设置为 < POLICYNAME>=YES 或 <POLICYNAME> =NO，才能被 TPS 识别。

6.4. 令牌操作和策略处理

本节讨论涉及令牌的主要操作（显式和隐式）。以下列表将讨论每个功能及其配置。

注意

有关一般信息，请参阅 红帽认证系统 9 规划、安装和部署指南中的 令牌策略部分。

格式

Format 操作（用户发起）以完全空白状态获取令牌，由制造商提供，并在其上加载 Coolkey 小程序。

配置示例：

#specify that we want authentication for format. We almost always want this at true:
op.format.userKey.auth.enable=true
#specify the ldap authentication configuration, so TPS knows where to validate credentials:
op.format.userKey.auth.id=ldap1
#specify the connection the the CA
op.format.userKey.ca.conn=ca1
#specify id of the card manager applet on given token
op.format.userKey.cardmgr_instance=A0000000030000

#specify if we need to match the visa cuid to the nist sp800sp derivation algorithm KDD value. Mostly will be false:
op.format.userKey.cuidMustMatchKDD=false

#enable ability to restrict key changoever to a specific range of key set:
op.format.userKey.enableBoundedGPKeyVersion=true
#enable the phone home url to write to the token:
op.format.userKey.issuerinfo.enable=true
#actual home url to write to token:
op.format.userKey.issuerinfo.value=http://server.example.com:8080/tps/phoneHome
#specify whether to request a login from the client. Mostly true, external reg may want this to be false:
op.format.userKey.loginRequest.enable=true
#Actual range of desired keyset numbers:
op.format.userKey.maximumGPKeyVersion=FF
op.format.userKey.minimumGPKeyVersion=01
#Whether or not to revoke certs on the token after a format, and what the reason will be if so:
op.format.userKey.revokeCert=true
op.format.userKey.revokeCert.reason=0
#This will roll back the reflected keyyset version of the token in the tokendb. After a failed key changeover operation. This is to keep the value in sync with reality in the tokendb. Always false, since this version of TPS avoids this situation now:
op.format.userKey.rollbackKeyVersionOnPutKeyFailure=false

#specify connection to the TKS:
op.format.userKey.tks.conn=tks1
#where to get the actual applet file to write to the token:
op.format.userKey.update.applet.directory=/usr/share/pki/tps/applets
#Allows a completely blank token to be recognized by TPS. Mostly should be true:
op.format.userKey.update.applet.emptyToken.enable=true
#Always should be true, not supported:
op.format.userKey.update.applet.encryption=true
#Actual version of the applet file we want to upgrade to. This file will have a name something like: 1.4.54de7a99.ijc:
op.format.userKey.update.applet.requiredVersion=1.4.54de790f
#Symm key changeover:
op.format.userKey.update.symmetricKeys.enable=false
op.format.userKey.update.symmetricKeys.requiredVersion=1
#Make sure the token db is in sync with reality. Should always be true:
op.format.userKey.validateCardKeyInfoAgainstTokenDB=true

注册

基本注册操作采用格式化的令牌，并将 certs 和密钥放在令牌中以个性化令牌。以下配置示例将介绍如何控制它。

示例显示了不处理续订和内部恢复的基本注册。这里未讨论的设置在 Format 部分中提供，或者没有关键。

op.enroll.userKey.auth.enable=true
op.enroll.userKey.auth.id=ldap1
op.enroll.userKey.cardmgr_instance=A0000000030000
op.enroll.userKey.cuidMustMatchKDD=false

op.enroll.userKey.enableBoundedGPKeyVersion=true
op.enroll.userKey.issuerinfo.enable=true
op.enroll.userKey.issuerinfo.value=http://server.example.com:8080/tps/phoneHome

#configure the encryption cert and keys  we want on the token:

#connection the the CA, which issues the certs:
op.enroll.userKey.keyGen.encryption.ca.conn=ca1
#Profile id we want the CA to use to issue our encrytion cert:
op.enroll.userKey.keyGen.encryption.ca.profileId=caTokenUserEncryptionKeyEnrollment

#These two cover the indexes of the certs written to the token. Each cert needs a unique index or “slot”. In our sample the enc cert will occupy slot 2 and the signing cert, shown later, will occupy slot 1. Avoid overlap with these numbers:
op.enroll.userKey.keyGen.encryption.certAttrId=c2
op.enroll.userKey.keyGen.encryption.certId=C2

op.enroll.userKey.keyGen.encryption.cuid_label=$cuid$
#specify size of generated private key:
op.enroll.userKey.keyGen.encryption.keySize=1024
op.enroll.userKey.keyGen.encryption.keyUsage=0
op.enroll.userKey.keyGen.encryption.keyUser=0
#specify pattern for what the label of the cert will look like when the cert nickname is displayed in browsers and mail clients:
op.enroll.userKey.keyGen.encryption.label=encryption key for $userid$
#specify if we want to overwrite certs on a re-enrollment operation. This is almost always the case:
op.enroll.userKey.keyGen.encryption.overwrite=true

#The next several settings specify the capabilities that the private key on the final token will inherit. For instance this will determine if the cert can be used for encryption or digital signatures. There are settings for both the private and public key.

op.enroll.userKey.keyGen.encryption.private.keyCapabilities.decrypt=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.derive=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.encrypt=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.private=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.sensitive=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.sign=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.signRecover=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.token=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.unwrap=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.verify=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.verifyRecover=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.wrap=false
op.enroll.userKey.keyGen.encryption.privateKeyAttrId=k4
op.enroll.userKey.keyGen.encryption.privateKeyNumber=4
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.decrypt=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.derive=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.encrypt=true
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.private=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.sensitive=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.sign=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.signRecover=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.token=true
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.unwrap=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.verify=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.verifyRecover=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.wrap=true

#The following index numbers correspond to the index or slot that the private and public keys occupy. The common formula we use is that the public key index will be 2 * cert id + 1, and the private key index, shown above will be 2 * cert id. In this example the cert id is 2, so the key ids will be 4 and 5 respectively. When composing these, be careful not to create conflicts. This applies to the signing key section below.

op.enroll.userKey.keyGen.encryption.publicKeyAttrId=k5
op.enroll.userKey.keyGen.encryption.publicKeyNumber=5

#specify if, when a certificate is slated for revocation, based on other rules, we want to check to see if some other token is using this cert in a shared situation. If this is set to true, and this situation is found the cert will not be revoked until the last token wants to revoke this cert:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.holdRevocationUntilLastCredential=false

#specify, if we want server side keygen, if we want to have that generated key archived to the drm. This is almost always the case, since we want the ability to later recover a cert and its encryption private key back to a new token:
op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true
#connection to drm to generate the key for us:
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
#specify server side keygen of the encryption private key. This most often will be desired:
op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true

#This setting tells us how many certs we want to enroll for this TPS profile, in the case “userKey”. Here we want 2 total certs. The next values then go on to index into the config what two types of certs we want, signing and encryption:
op.enroll.userKey.keyGen.keyType.num=2
op.enroll.userKey.keyGen.keyType.value.0=signing
op.enroll.userKey.keyGen.keyType.value.1=encryption

#configure the signing cert and keys we want on the token the settings for these are similar to the encryption settings already discussed, except the capability flags presented below, since this is a signing key.

op.enroll.userKey.keyGen.signing.ca.conn=ca1
op.enroll.userKey.keyGen.signing.ca.profileId=caTokenUserSigningKeyEnrollment
op.enroll.userKey.keyGen.signing.certAttrId=c1
op.enroll.userKey.keyGen.signing.certId=C1
op.enroll.userKey.keyGen.signing.cuid_label=$cuid$
op.enroll.userKey.keyGen.signing.keySize=1024
op.enroll.userKey.keyGen.signing.keyUsage=0
op.enroll.userKey.keyGen.signing.keyUser=0
op.enroll.userKey.keyGen.signing.label=signing key for $userid$
op.enroll.userKey.keyGen.signing.overwrite=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.decrypt=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.derive=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.encrypt=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.private=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.sensitive=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.sign=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.signRecover=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.token=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.unwrap=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.verify=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.verifyRecover=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.wrap=false
op.enroll.userKey.keyGen.signing.privateKeyAttrId=k2
op.enroll.userKey.keyGen.signing.privateKeyNumber=2
op.enroll.userKey.keyGen.signing.public.keyCapabilities.decrypt=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.derive=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.encrypt=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.private=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.sensitive=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.sign=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.signRecover=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.token=true
op.enroll.userKey.keyGen.signing.public.keyCapabilities.unwrap=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.verify=true
op.enroll.userKey.keyGen.signing.public.keyCapabilities.verifyRecover=true
op.enroll.userKey.keyGen.signing.public.keyCapabilities.wrap=false
op.enroll.userKey.keyGen.signing.publicKeyAttrId=k3
op.enroll.userKey.keyGen.signing.publicKeyNumber=3

pin Reset

第 6.3 节 “令牌策略” 中讨论 pin reset 的配置，因为 pin reset 依赖于策略来决定其是否是合法执行的。

续订

第 6.3 节 “令牌策略” 中会讨论续订的配置，因为续订依赖于策略来确定是否必须按照已注册的令牌执行或不受注册的令牌执行。

恢复

当 TPS 用户界面用户将之前的活跃令牌标记为一个不良状态（如"lost"或"destroyed）"时，恢复会被隐式设置。发生这种情况后，下一个注册了同一用户的新令牌后，会遵循以下配置，以将证书从用户旧令牌恢复到这个新令牌。

此操作的最终结果是用户将具有一个新的物理令牌，该令牌可能包含从旧令牌中恢复的加密证书，以便用户可以根据需要继续加密和解密数据。通常还会将新的签名证书放在这个令牌上，如以下示例配置示例所示。

以下是支持状态列表，其中令牌可以手动放在 TPS 用户界面中，如配置中所示：

tokendb._069=# - DAMAGED(1): Corresponds 在恢复配置中 销毁。当令牌被物理损坏时使用。
tokendb._070=# - PERM_LOST(2): Corresponds to keyCompromisein recovery configuration.永久丢失令牌时使用。
tokendb._071=# - SUSPENDED(3): Corresponds to onHold in the restore configuration.临时使用令牌时，用户希望再次查找它。
tokendb._072=# - TERMINATED(6): Corresponds 在恢复配置中 终止。用于出于内部原因而取出来自服务的令牌。

恢复配置示例：

#When a token is marked destroyed, don’t revoke the certs on the token unless all other tokens do not have the certs included:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.holdRevocationUntilLastCredential=false
#specify if we even want to revoke certs a token is marked destroyed:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert=false
#if we want to revoke any certs here, specify the reason for revocation that will be sent to the CA:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert.reason=0
#speficy if we want to revoke expired certs when marking the token destroyed:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeExpiredCerts=false

其他设置用于指定在对新令牌进行恢复操作时应使用什么类型的静态恢复（当原始令牌被标记为销毁时）。支持以下方案：

恢复 Last(RecoverLast)：恢复要放置在令牌中的最新加密证书。
生成新密钥和 Recover Last(GenerateNewKeyAndRecoverLast): Same as Recover Last，但也会生成新的加密证书并将其上传到令牌。然后新令牌将有两个证书。
生成新密钥(GenerateNewKey): 生成新加密证书并将其放在令牌中。不要恢复任何旧的证书。

例如：

op.enroll.userKey.keyGen.encryption.recovery.destroyed.scheme=RecoverLast

以下配置示例确定如何恢复标记为永久丢失的令牌：

op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert=true
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert.reason=1
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeExpiredCerts=false
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.scheme=GenerateNewKey

# Section when a token is marked terminated.

op.enroll.userKey.keyGen.encryption.recovery.terminated.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeCert=true
op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeCert.reason=1
op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeExpiredCerts=false
op.enroll.userKey.keyGen.encryption.recovery.terminated.scheme=GenerateNewKey

# This section details the recovery profile with respect to which certs and of what kind get recovered on the token.

op.enroll.userKey.keyGen.recovery.destroyed.keyType.num=2
op.enroll.userKey.keyGen.recovery.destroyed.keyType.value.0=signing
op.enroll.userKey.keyGen.recovery.destroyed.keyType.value.1=encryption

最后，以下示例确定系统将对旧令牌上的签名证书做了哪些操作。在大多数情况下，应使用 GenerateNewKey 恢复方案来避免使用签名私钥的多个副本（例如：在新令牌中恢复的另外一个新令牌），另一个由其他人永久丢失但由其他人发现的旧令牌。

op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.0=signing
op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.1=encryption
op.enroll.userKey.keyGen.recovery.onHold.keyType.num=2
op.enroll.userKey.keyGen.recovery.onHold.keyType.value.0=signing
op.enroll.userKey.keyGen.recovery.onHold.keyType.value.1=encryption

op.enroll.userKey.keyGen.signing.recovery.destroyed.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert=true
op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert.reason=0
op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.destroyed.scheme=GenerateNewKey
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert=true
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert.reason=1
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.scheme=GenerateNewKey
op.enroll.userKey.keyGen.signing.recovery.onHold.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert=true

op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert.reason=6
op.enroll.userKey.keyGen.signing.recovery.onHold.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.onHold.scheme=GenerateNewKey
op.enroll.userKey.keyGen.signing.recovery.terminated.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.terminated.revokeCert=true
op.enroll.userKey.keyGen.signing.recovery.terminated.revokeCert.reason=1
op.enroll.userKey.keyGen.signing.recovery.terminated.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.terminated.scheme=GenerateNewKey

# Configuration for the case when we mark a token “onHold” or temporarily lost

op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.revokeCert=true
op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.revokeCert.reason=0
op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.scheme=RecoverLast
op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.num=2
op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.value.0=signing
op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.value.1=encryption
op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.revokeCert=true
op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.revokeCert.reason=0
op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.scheme=GenerateNewKey

小应用程序更新

以下示例演示了如何配置 Coolkey 小程序更新操作。此操作可以在格式、注册和 PIN 重置操作的过程中执行：

op.format.userKey.update.applet.directory=/usr/share/pki/tps/applets
op.format.userKey.update.applet.emptyToken.enable=true
op.format.userKey.update.applet.encryption=true
op.format.userKey.update.applet.requiredVersion=1.4.54de790f

其中一些选项已在 Format 部分进行了演示。它们提供必要的信息，以确定是否应该允许进行应用程序升级，在哪里查找小应用程序文件，以及将令牌升级到的小版本。requiredVersion 中的版本映射到 目录 下的文件名。

密钥更新

此操作可在格式、注册和 PIN 重置操作的过程中进行，允许用户从制造商提供的默认全局平台设置版本进行升级。

TPS

以下选项指示 TPS 在代表给定令牌请求的下一个格式操作时将密钥从 1 升级到 2。完成后，TKS 必须生成将写入令牌的三个新密钥，之后，令牌必须与同一 TPS 和 TKS 安装一起使用，否则它将被锁定。

op.format.userKey.update.symmetricKeys.enable=true
op.format.userKey.update.symmetricKeys.requiredVersion=2

您还可以指定小于当前版本来降级密钥集。

TKS

如上所述，必须将 TKS 配置为生成要写入令牌的新密钥。首先，新的 master 键标识符 02 必须映射到 TKS CS.cfg 中的 PKCS #11 对象 nickname，如下例所示：

tks.mk_mappings.#02#01=internal:new_master
tks.defKeySet.mk_mappings.#02#01=internal:new_master

以上会将一个键设置号映射到 TKS NSS 数据库中存在的实际 master 密钥。

Master 密钥由 ID 标识，如 01。TKS 将这些 ID 映射到映射的 masterKeyId 部分中指定的 PKCS #11 对象 nicknames。因此，第一个数字会在主密钥版本被更新时更新，第二个数字保持一致。

当尝试从 1 升级到版本 2 时，映射决定了如何查找主键别名，这些名称将用于生成新密钥集的 3 个部分。

上例中的 internal 设置引用主密钥所在的令牌的名称。它还可以是带有名称（如 nethsm ）的外部 HSM 模块。strong new_master 是 master 键 nickname 本身的示例。

6.5. 内部注册

注意

有关一般信息，请参阅 红帽认证系统 9 规划、安装和部署指南中的 TPS 配置集 部分。

如果是 内部注册，则 TPS 配置集（令牌类型）由 Mapping Resolver 决定。与外部 注册不同的是，在配置集本身中定义身份验证信息。例如：

op.enroll.userKey.auth.enable=true
op.enroll.userKey.auth.id=ldap1

外部注册的另一个区别在于，CA 和 KRA 连接器信息是在每个配置集的密钥类型下定义。例如：

op.enroll.userKey.keyGen.encryption.ca.conn=ca1
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1

但是，TKS 连接器信息为每个配置集定义：

op.enroll.userKey.tks.conn=tks1

注意

在内部和外部注册间切换注册类型意味着您必须格式化所有之前注册的令牌，然后才能继续使用它们。

6.6. 外部注册

外部注册从经过身份验证的用户 LDAP 记录中获取令牌类型（TPS 配置集）。它还允许在同一用户记录中指定证书/密钥恢复信息。

外部注册 TPS 配置集与前面讨论的内部注册配置文件类似。它允许您为客户端和服务器端密钥生成指定新证书注册。与内部注册不同，它允许您选择特定证书（及其匹配密钥）以检索并加载到令牌中。

注意

在内部和外部注册间切换注册类型意味着您必须格式化所有之前注册的令牌，然后才能继续使用它们。

6.6.1. 启用外部注册

外部注册只能为整个 TPS 实例全局启用。以下示例显示了与外部注册相关的一组全局配置参数：

externalReg.allowRecoverInvalidCert.enable=true
externalReg.authId=ldap1
externalReg.default.tokenType=externalRegAddToToken
externalReg.delegation.enable=true
externalReg.enable=true
externalReg.recover.byKeyID=false
externalReg.format.loginRequest.enable=true
externalReg.mappingResolver=keySetMappingResolver

6.6.2. 自定义用户 LDAP 记录属性名称

以下示例中显示了与外部注册相关的身份验证参数（具有其默认值）：

auths.instance.ldap1.externalReg.certs.recoverAttributeName=certsToAdd
auths.instance.ldap1.externalReg.cuidAttributeName=tokenCUID
auths.instance.ldap1.externalReg.tokenTypeAttributeName=tokenType

LDAP 记录属性名称可以在此处自定义。确保用户的 LDAP 记录的实际属性与此配置匹配。

6.6.3. 配置 certsToAdd 属性

certsToAdd 属性采用以下格式的多个值：

<cert serial # in decimal>,<CA connector ID>,<key ID>,<kra connector ID>

例如：

59,ca1,0,kra1

重要

默认情况下，密钥恢复会按证书搜索密钥，使 < key ID> 值不相关。但是，可以选择性地将 TPS 配置为使用此属性搜索键，因此通常更易于将值设为 0。该值无效，这可避免获得不匹配的密钥的可能性。

不建议通过密钥 ID 恢复，因为 KRA 无法验证证书是否与这种情况中的密钥匹配。

当只使用证书和 CA 信息指定 certsToAdd 属性时，TPS 会假定问题中的证书已在令牌中已存在，并且应该保留它。这一概念被称为 关键保留。

以下示例显示了用户 LDAP 记录中的相关属性：

tokenType: externalRegAddToToken
certstoadd: 59,ca1,0,kra1
certstoadd: 134,ca1,0,kra1
Certstoadd: 24,ca1

6.6.4. 用户匹配强制的令牌

另外，您可以设置系统以便用于注册的令牌必须与用户记录唯一 ID(CUID)属性匹配。如果记录中缺少此属性(tokencuid)，则不会强制执行 CUID 匹配。

Tokencuid: a10192030405028001c0

有关外部注册的另一个属性是绕过每个令牌上的令牌策略。

注意

对于要在外部注册中"接收"的证书和密钥，在用户 LDAP 记录中指定 CA 和 KRA 连接器信息。与证书/密钥相关的 TPS 配置集中指定的 CA 和/或 KRA 连接器信息都会被忽略。

certstoadd: 59,ca1,0,kra1

6.6.5. 委托支持

委托支持在身份验证（登录、数据加密和解密或签名方面）方面，用户就可代表其代表谁进行委托委托（例如，公司执行者具有一个或多个委托）。

一个示例场景可能是每个委托都有自己的令牌，用于代表执行执行。此令牌包含以下证书和密钥（由 TPS 配置集终止）的组合：

Authentication certificate/keys：CN 包含委派的名称和唯一 ID。主题备用名称(SAN)扩展包含执行的主名称(UPN)。
加密证书：执行主加密证书的确切副本。
签名证书：CN 包含委派的名称和唯一 ID。SAN 包含执行执行的 RFC822Name。

使用以下参数来启用委托支持：

externalReg.delegation.enable=true

重要

要临时解决这个问题，请手动将 op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId 参数设置为 /var/lib/pki/instance_name/tps/conf/CS.cfg 文件来 caTokenUserDelegateAuthKeyEnrollment:

op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId=caTokenUserDelegateAuthKeyEnrollment

6.6.6. SAN 和 DN 模式

auths.instance. <authID > .ldapStringAttributes in authentication instance configuration 指定在身份验证过程中检索哪些属性。例如：

auths.instance.ldap1.ldapStringAttributes=mail,cn,uid,edipi,pcc,firstname,lastname,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType

从用户的 LDAP 记录中检索后，可以引用这些属性的值，并使用它组成证书的 Subject Alternative Name(SAN)或以 $auth. <attribute name> $ .例如：

op.enroll.delegateIEtoken.keyGen.authentication.SANpattern=$auth.exec-edipi$.$auth.exec-pcc$@EXAMPLE.com
op.enroll.delegateIEtoken.keyGen.authentication.dnpattern=cn=$auth.firstname$.$auth.lastname$.$auth.edipi$,e=$auth.mail$,o=TMS Org

当在 SAN 和 DN 的 TPS 配置集中使用模式时，务必要确保正确设置 TPS 配置集中指定的 CA 注册配置集。例如：

在 TPS 上，在配置集 delegateIEtoken 中

op.enroll.delegateIEtoken.keyGen.authentication.ca.profileId=caTokenUserDelegateAuthKeyEnrollment

在 CA 中，在注册配置集 caTokenUserDelegateAuthKeyEnrollment 中

subjectDNInputImpl 插件必须指定为输入之一，以便上面的 TPS 配置集指定 DN：

input.i2.class_id=subjectDNInputImpl
input.i2.name=subjectDNInputImpl

同样，要允许上述 TPS 配置集指定 SAN，必须指定 subjectAltNameExtInputImpl 插件：

input.i3.class_id=subjectAltNameExtInputImpl
input.i3.name=subjectAltNameExtInputImpl

还必须指定 subjAltExtpattern:

policyset.set1.p6.default.params.subjAltExtPattern_0=(UTF8String)1.3.6.1.4.1.311.20.2.3,$request.req_san_pattern_0$

在上例中，OID 1.3.6.1.4.1.311.20.2.3 是 User Principal Name(UPN)的 OID，而 request.req_san_pattern_0 是 delegateIEtoken SAN 模式中指定的第一个 SAN 模式。

您可以同时指定多个 SAN。在 TPS 端，在 SANpattern 中指定多个 SAN，用逗号(",")分隔。在 CA 端，需要以以下格式定义对应的 subjAltExtPattern ：

policyset.<policy set id>.<policy id>.default.params.subjAltExtPattern_<ordered number>=

在上面的中，& lt;ordered number > 以 0 开头，并增加 TPS 端指定的每个 SAN 模式：

policyset.set1.p6.default.params.subjAltExtPattern_0=
policyset.set1.p6.default.params.subjAltExtPattern_1=
...

以下是一个完整的示例：

例 6.1. SANpattern 和 DNpattern 配置

LDAP 记录包含以下信息：

givenName: user1a
mail: user1a@example.org
firstname: user1a
edipi: 123456789
pcc: AA
exec-edipi: 999999999
exec-pcc: BB
exec-mail: user1b@EXAMPLE.com
tokenType: delegateISEtoken
certstoadd: 59,ca1,0,kra1

TPS External Registration 配置集 委派IEtoken 包含：

SANpattern:

op.enroll.delegateISEtoken.keyGen.authentication.SANpattern=$auth.exec-edipi$.$auth.exec-pcc$@EXAMPLE.com

DNPattern ：

op.enroll.delegateISEtoken.keyGen.authentication.dnpattern=cn=$auth.firstname$.$auth.lastname$.$auth.edipi$,e=$auth.mail$,o=TMS Org

CA caTokenUserDelegateAuthKeyEnrollment contains:

input.i2.class_id=subjectDNInputImpl
input.i2.name=subjectDNInputImpl
input.i3.class_id=subjectAltNameExtInputImpl
input.i3.name=subjectAltNameExtInputImpl

policyset.set1.p6.constraint.class_id=noConstraintImpl
policyset.set1.p6.constraint.name=No Constraint
policyset.set1.p6.default.class_id=subjectAltNameExtDefaultImpl
policyset.set1.p6.default.name=Subject Alternative Name Extension Default
policyset.set1.p6.default.params.subjAltExtGNEnable_0=true
policyset.set1.p6.default.params.subjAltExtPattern_0=(UTF8String)1.3.6.1.4.1.311.20.2.3,$request.req_san_pattern_0$
policyset.set1.p6.default.params.subjAltExtType_0=OtherName
policyset.set1.p6.default.params.subjAltNameExtCritical=false
policyset.set1.p6.default.params.subjAltNameNumGNs=1

然后，生成的证书包含：

Subject: CN=user1a..123456789,E=user1a@example.org,O=TMS Org
Identifier: Subject Alternative Name - 2.5.29.17
Critical: no
Value:
  OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,999999999.BB@EXAMPLE.com

6.7. 映射解析器配置

Token 处理系统默认提供一个映射解析器。解析器名为 FilterMappingResolver。本节将涵盖其配置。

注意

有关映射解析程序的一般信息，请参阅 红帽认证系统规划、安装和部署指南中的 映射解决问题部分。

6.7.1. key Set Mapping Resolver

在外部注册过程中，必须使用解析器解析密钥集，然后才能验证密钥。

键集映射解析器名称定义如下：

externalReg.mappingResolver=<keySet mapping resolver name>

例如：

externalReg.mappingResolver=keySetMappingResolver

以下配置示例显示了完整的实例配置：

mappingResolver.keySetMappingResolver.class_id=filterMappingResolverImpl
mappingResolver.keySetMappingResolver.mapping.0.filter.appletMajorVersion=0
mappingResolver.keySetMappingResolver.mapping.0.filter.appletMinorVersion=0
mappingResolver.keySetMappingResolver.mapping.0.filter.keySet=
mappingResolver.keySetMappingResolver.mapping.0.filter.tokenATR=
mappingResolver.keySetMappingResolver.mapping.0.filter.tokenCUID.end=a1000000000000000000
mappingResolver.keySetMappingResolver.mapping.0.filter.tokenCUID.start=a0000000000000000000
mappingResolver.keySetMappingResolver.mapping.0.target.keySet=defKeySet
mappingResolver.keySetMappingResolver.mapping.1.filter.appletMajorVersion=1
mappingResolver.keySetMappingResolver.mapping.1.filter.appletMinorVersion=1
mappingResolver.keySetMappingResolver.mapping.1.filter.keySet=
mappingResolver.keySetMappingResolver.mapping.1.filter.tokenATR=1234
mappingResolver.keySetMappingResolver.mapping.1.filter.tokenCUID.end=
mappingResolver.keySetMappingResolver.mapping.1.filter.tokenCUID.start=
mappingResolver.keySetMappingResolver.mapping.1.target.keySet=defKeySet
mappingResolver.keySetMappingResolver.mapping.2.filter.appletMajorVersion=
mappingResolver.keySetMappingResolver.mapping.2.filter.appletMinorVersion=
mappingResolver.keySetMappingResolver.mapping.2.filter.keySet=
mappingResolver.keySetMappingResolver.mapping.2.filter.tokenATR=
mappingResolver.keySetMappingResolver.mapping.2.filter.tokenCUID.end=
mappingResolver.keySetMappingResolver.mapping.2.filter.tokenCUID.start=
mappingResolver.keySetMappingResolver.mapping.2.target.keySet=jForte
mappingResolver.keySetMappingResolver.mapping.order=0,1,2

上面的示例定义了三个映射，名为 0、1 和 2。它们使用 mappingResolver.keySetMappingResolver.mapping.order=0,1,2 行排序。这个顺序表示将首先针对映射过滤器 0 运行输入参数；只有在它们不匹配该过滤器时，才会在映射顺序中尝试下一个参数。例如，如果评估具有以下特征的令牌：

CUID=a0000000000000000011
appletMajorVersion=0
appletMinorVersion=0

然后，它将传递映射 0 并为其分配目标（配置为 defKeySet ），因为小应用程序版本匹配，并且 CUID 不在该映射的 CUID 启动和结束范围内。

另外，如果令牌具有以下参数：

CUID=b0000000000000000000
ATR=2222
appletMajorVersion=1
appletMinorVersion=1

在这种情况下，此令牌无法映射 0， 因为它位于指定的 CUID 范围之外。它也会失败映射 1，因为应用程序版本匹配时 ATR 也会失败。以上令牌将分配给映射 2 及其目标 J Forte。

请注意，映射 2 如何为任何过滤器没有分配。这会导致映射与所有令牌匹配，并有效地使其成为"默认"值。像这样的映射顺序必须以映射顺序指定，因为不会评估任何其他映射。

6.7.2. 令牌类型(TPS)Mapping Resolver

Token Processing System 中定义的三个默认 tokenType 映射解析器： formatProfileMappingResolver、enrollProfileMappingResolver 和 pinResetProfileMappingResolver。与上一节中讨论的外部注册案例相比，内部注册案例实际是从定义的映射解析器计算的。

令牌类型映射解析器名称定义如下：

op.<op>.mappingResolver=<mapping resolver name>

例如：

op.enroll.mappingResolver=enrollProfileMappingResolver

以下配置示例描述了 enrollProfileMappingResolver ：

mappingResolver.enrollProfileMappingResolver.class_id=filterMappingResolverImpl
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.appletMajorVersion=1
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.appletMinorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenATR=
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenCUID.end=b1000000000000000000
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenCUID.start=b0000000000000000000
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenType=userKey
mappingResolver.enrollProfileMappingResolver.mapping.0.target.tokenType=userKey
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.appletMajorVersion=1
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.appletMinorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenATR=
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenCUID.end=a0000000000000001000
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenCUID.start=a0000000000000000000
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenType=soKey
mappingResolver.enrollProfileMappingResolver.mapping.1.target.tokenType=soKey
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.appletMajorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.appletMinorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenATR=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenCUID.end=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenCUID.start=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenType=
mappingResolver.enrollProfileMappingResolver.mapping.2.target.tokenType=userKey
mappingResolver.enrollProfileMappingResolver.mapping.order=1,0,2

在上例中为 register ProfileMappingResolver 定义了三个映射。映射名为 0、1 和 2。mappingResolver.enrollProfileMappingResolver.mapping.order=1,0,2 行定义处理映射的顺序。如果令牌与映射匹配，则不会对顺序进行进一步映射；如果与映射不匹配，就会尝试下一个映射。

如果令牌具有以下参数：

CUID=a0000000000000000011
appletMajorVersion=1
appletMinorVersion=0
extension: tokenType=soKey

使用这个配置的令牌将与映射 1 的过滤器匹配，小应用程序版本匹配，CUID 在指定的开始和结束范围内会失败，扩展名 tokenType 匹配。因此，此令牌将被分配该映射的目标 - soKey.

另外，如果令牌具有以下参数：

CUID=b0000000000000000010
appletMajorVersion=1
appletMinorVersion=1

在这种情况下，令牌将失败，因为 CUID 位于指定范围之外。然后它还将失败映射 0， 因为缺少 tokenType 扩展。然后，此令牌将匹配映射 2，因为它没有指定的过滤器以匹配上一个过滤器的任何令牌。

6.8. 身份验证配置

Token 处理系统默认支持使用用户 ID 和密码(UidPwdDirAuthentication)进行基于目录的身份验证。身份验证实例使用以下模式在 CS.cfg 文件中定义：

auths.instance.<auths ID>.*

& lt;auths ID > 是验证首选项的 TPS 配置集引用的 authenticator 名称。例如：

op.enroll.userKey.auth.id=ldap1

以下配置示例显示了身份验证实例的完整定义：

auths.impl.UidPwdDirAuth.class=com.netscape.cms.authentication.UidPwdDirAuthentication
auths.instance.ldap1.pluginName=UidPwdDirAuth
auths.instance.ldap1.authCredName=uid
auths.instance.ldap1.dnpattern=
auths.instance.ldap1.externalReg.certs.recoverAttributeName=certsToAdd
auths.instance.ldap1.externalReg.cuidAttributeName=tokenCUID
auths.instance.ldap1.externalReg.tokenTypeAttributeName=tokenType
auths.instance.ldap1.ldap.basedn=dc=sjc,dc=example,dc=com
auths.instance.ldap1.ldap.ldapauth.authtype=BasicAuth
auths.instance.ldap1.ldap.ldapauth.bindDN=
auths.instance.ldap1.ldap.ldapauth.bindPWPrompt=ldap1
auths.instance.ldap1.ldap.ldapauth.clientCertNickname=subsystemCert cert-pki-tomcat
auths.instance.ldap1.ldap.ldapconn.host=host1.EXAMPLE.com
auths.instance.ldap1.ldap.ldapconn.port=389
auths.instance.ldap1.ldap.ldapconn.secureConn=False
auths.instance.ldap1.ldap.ldapconn.version=3
auths.instance.ldap1.ldap.maxConns=15
auths.instance.ldap1.ldap.minConns=3
auths.instance.ldap1.ldapByteAttributes=
auths.instance.ldap1.ldapStringAttributes=mail,cn,uid,edipi,pcc,firstname,lastname,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType
auths.instance.ldap1.ldapStringAttributes._000=#################################
auths.instance.ldap1.ldapStringAttributes._001=# For isExternalReg
auths.instance.ldap1.ldapStringAttributes._002=#   attributes will be available as
auths.instance.ldap1.ldapStringAttributes._003=#       $<attribute>$
auths.instance.ldap1.ldapStringAttributes._004=#   attributes example:
auths.instance.ldap1.ldapStringAttributes._005=#mail,cn,uid,edipi,pcc,firstname,lastname,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType
auths.instance.ldap1.ldapStringAttributes._006=#################################
auths.instance.ldap1.pluginName=UidPwdDirAuth
auths.instance.ldap1.ui.description.en=This authenticates user against the LDAP directory.
auths.instance.ldap1.ui.id.PASSWORD.credMap.authCred=pwd
auths.instance.ldap1.ui.id.PASSWORD.credMap.msgCred.extlogin=PASSWORD
auths.instance.ldap1.ui.id.PASSWORD.credMap.msgCred.login=password
auths.instance.ldap1.ui.id.PASSWORD.description.en=LDAP Password
auths.instance.ldap1.ui.id.PASSWORD.name.en=LDAP Password
auths.instance.ldap1.ui.id.UID.credMap.authCred=uid
auths.instance.ldap1.ui.id.UID.credMap.msgCred.extlogin=UID
auths.instance.ldap1.ui.id.UID.credMap.msgCred.login=screen_name
auths.instance.ldap1.ui.id.UID.description.en=LDAP User ID
auths.instance.ldap1.ui.id.UID.name.en=LDAP User ID
auths.instance.ldap1.ui.retries=3
auths.instance.ldap1.ui.title.en=LDAP Authentication

TPS 验证实例配置方式与 CA 的 UidPwdDirAuthentication 身份验证实例类似，因为它们都使用相同的插件处理。但是，TPS 在 CA 配置之上需要几个额外的参数。

如果是常见的操作（用于内部和外部注册），调用此验证方法的配置集允许 TPS 项目在客户端上标记 UID 和密码。这由上例中的 auths.instance.ldap1.ui.id.UID.name.en=LDAP User ID 和 auths.instance.ldap1.ui.id.PASSWORD.name.en=LDAP 密码 参数控制；此配置可向客户端显示 UID/password 对为"LDAP User ID"和"LDAP Password"。这两个参数都可以自定义。

credMap.authCred 条目配置内部身份验证插件如何接受与之显示的信息，以及 credMap.msgCred 条目配置如何将此信息传递给 TPS。这些字段允许您使用自定义插件实施，并且应保留其默认值，除非您使用自定义身份验证插件。

第 6.6 节 “外部注册” 中讨论与外部注册相关的参数。

与 CA 身份验证配置类似，您可以为相同的身份验证实施定义多个身份验证实例。当 TPS 服务于多个用户组时，这很有用；您可以指示每个组使用其自己的 TPS 配置集，每个配置都配置为使用其自己的目录服务器身份验证。

6.9. 连接器

连接器定义 TPS 如何与其他子系统（即 CA、KRA 和 TKS）通信。通常，这些参数会在 TPS 安装过程中设置。以下是连接器配置示例：

tps.connector.ca1.enable=true
tps.connector.ca1.host=host1.EXAMPLE.com
tps.connector.ca1.maxHttpConns=15
tps.connector.ca1.minHttpConns=1
tps.connector.ca1.nickName=subsystemCert cert-pki-tomcat
tps.connector.ca1.port=8443
tps.connector.ca1.timeout=30
tps.connector.ca1.uri.enrollment=/ca/ee/ca/profileSubmitSSLClient
tps.connector.ca1.uri.getcert=/ca/ee/ca/displayBySerial
tps.connector.ca1.uri.renewal=/ca/ee/ca/profileSubmitSSLClient
tps.connector.ca1.uri.revoke=/ca/ee/subsystem/ca/doRevoke
tps.connector.ca1.uri.unrevoke=/ca/ee/subsystem/ca/doUnrevoke
tps.connector.kra1.enable=true
tps.connector.kra1.host=host1.EXAMPLE.com
tps.connector.kra1.maxHttpConns=15
tps.connector.kra1.minHttpConns=1
tps.connector.kra1.nickName=subsystemCert cert-pki-tomcat
tps.connector.kra1.port=8443
tps.connector.kra1.timeout=30
tps.connector.kra1.uri.GenerateKeyPair=/kra/agent/kra/GenerateKeyPair
tps.connector.kra1.uri.TokenKeyRecovery=/kra/agent/kra/TokenKeyRecovery
tps.connector.tks1.enable=true
tps.connector.tks1.generateHostChallenge=true
tps.connector.tks1.host=host1.EXAMPLE.com
tps.connector.tks1.keySet=defKeySet
tps.connector.tks1.maxHttpConns=15
tps.connector.tks1.minHttpConns=1
tps.connector.tks1.nickName=subsystemCert cert-pki-tomcat
tps.connector.tks1.port=8443
tps.connector.tks1.serverKeygen=true
tps.connector.tks1.timeout=30
tps.connector.tks1.tksSharedSymKeyName=sharedSecret
tps.connector.tks1.uri.computeRandomData=/tks/agent/tks/computeRandomData
tps.connector.tks1.uri.computeSessionKey=/tks/agent/tks/computeSessionKey
tps.connector.tks1.uri.createKeySetData=/tks/agent/tks/createKeySetData
tps.connector.tks1.uri.encryptData=/tks/agent/tks/encryptData

TPS 配置集根据其 ID 指代这些连接器。例如：

op.enroll.userKey.keyGen.signing.ca.conn=ca1

可以定义相同类型的多个连接器（例如，多个 CA 连接器）。当一个 TPS 实例为不同令牌组提供多个后端证书系统服务器时，这很有用。

注意

目前不支持 TPS 中连接器的自动故障切换。需要执行手动故障切换过程，以将 TPS 指向备用 CA、KRA 或 TKS，只要它们是原始系统的克隆。

6.10. 撤销路由配置

要配置撤销路由，您必须首先定义相关 CA 连接器列表，并以以下格式将它们添加到连接器列表中：

tps.connCAList=ca1,ca2

另外，您必须在 TPS nssdb 中添加 CA 签名证书并设置信任：

#cd <TPS instance directory>/alias

#certutil -d . -A -n <CA signing cert nickname> -t “CT,C,C” -i <CA signing cert b64 file name>

最后，必须使用以下选项将 CA 签名证书的别名添加到连接器中：

tps.connector.ca1.caNickname=caSigningCert cert-pki-tomcat CA

注意

在 CA 发现过程中，TPS 可以自动计算 CA 的授权密钥标识符并将其添加到连接器配置中。例如：

tps.connector.ca1.caSKI=i9wOnN0QZLkzkndAB1MKMcjbRP8=

这个行为是预期的。

6.11. 设置服务器端密钥生成

服务器端密钥生成意味着密钥由密钥恢复授权(KRA)生成，它是一个可选的证书系统子系统。需要 KRA 生成密钥，以允许在丢失或已损坏的令牌时恢复密钥，或者在外部注册时检索密钥。这部分论述了如何在 TMS 中配置服务器端密钥生成。

在 TPS 安装过程中，要求您指定您是否要使用密钥归档。如果您确认，设置将执行自动基本配置，特别是以下参数：

KRA 的 TPS 连接器参数：

tps.connector.kra1.enable=true
tps.connector.kra1.host=host1.EXAMPLE.com
tps.connector.kra1.maxHttpConns=15
tps.connector.kra1.minHttpConns=1
tps.connector.kra1.nickName=subsystemCert cert-pki-tomcat
tps.connector.kra1.port=8443
tps.connector.kra1.timeout=30
tps.connector.kra1.uri.GenerateKeyPair=/kra/agent/kra/GenerateKeyPair
tps.connector.kra1.uri.TokenKeyRecovery=/kra/agent/kra/TokenKeyRecovery

用于服务器端密钥生成的 TPS 配置集参数：

op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true

设置 serverKeygen.enable=true 选项，使 serverKeygen.archive 生效。

重要

LunaSA HSM 不支持 RSA 加密时比 2048 字节小的密钥大小。

例如：要将密钥大小为 2048 字节，请在 /var/lib/pki/instance_name/tps/conf/CS.cfg 文件中设置以下参数：

op.enroll.userKey.keyGen.encryption.keySize=2048

TKS 配置：

以下配置了用于 TKS 和 KRA（通过 TPS）通信的传输证书的别名：

tks.drm_transport_cert_nickname=transportCert cert-pki-tomcat KRA

引用的传输证书还必须存在于 TKS 实例安全模块中。例如：

transportCert cert-pki-tomcat KRA                            u,u,u

KRA 配置

根据 PKCS#11 令牌，参数 kra.keygen.temporaryPairs、kra.keygen.sensitivePairs 和 kra.keygen.keygen.extractablePairs 可以为密钥生成选项自定义。这些参数默认设置为 false。

这些参数的以下值已使用 Red Hat Certificate System 支持的一些安全模块进行了测试：

NSS（在 FIPS 模式中）：

kra.keygen.extractablePairs=true

nCipher nShield Connect 6000（默认情况下，不指定工作）:

指定 RSA 密钥：

kra.keygen.temporaryPairs=true

（不要指定任何其他参数。）

生成 ECC 密钥：

kra.keygen.temporaryPairs=true
kra.keygen.sensitivePairs=false
kra.keygen.extractablePairs=true

LunaSA CKE - 密钥导出模型（非FIPS 模式）：

kra.keygen.temporaryPairs=true
kra.keygen.sensitivePairs=true
kra.keygen.extractablePairs=true

注意

Gemalto SafeNet LunaSA 只支持 CKE - 密钥导出模型中的 PKI 私钥提取，且仅在非FIPS 模式中支持。LunaSA Cloning 模型和 FIPS 模式中的 CKE 模型不支持 PKI 私钥提取。

注意

当 LunaSA CKE - Key Export Model 处于 FIPS 模式时，无法提取 pki 私钥。

6.12. 设置新密钥设置

这部分论述了在 Token Processing System(TPS)和 Token Key Service(TKS)中设置的默认密钥的替代选择。

TKS 配置

在 TKS 中使用 /var/lib/pki/instance_name/tks/conf/CS.cfg 文件中的以下选项配置默认密钥：

tks.defKeySet._000=##
tks.defKeySet._001=## Axalto default key set:
tks.defKeySet._002=##
tks.defKeySet._003=## tks.defKeySet.mk_mappings.#02#01=<tokenname>:<nickname>
tks.defKeySet._004=##
tks.defKeySet.auth_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.defKeySet.kek_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.defKeySet.mac_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.defKeySet.nistSP800-108KdfOnKeyVersion=00
tks.defKeySet.nistSP800-108KdfUseCuidAsKdd=false

以上配置定义了特定于在 TMS 中可以使用的某些类型或类的设置。最重要的部分是 3 开发人员或（开箱即用）会话密钥，它们用于在对称密钥移交前创建安全频道。其他类型的键对这些键可能有不同的默认值。

描述 nistSP800 键实用程序方法的设置控制是否使用了此方法。具体来说，tks.defKeySet.nistSP800-108KdfOnKeyVersion 选项的值决定了将使用 NIST 版本。nistSP800-108KdfUseCuidAsKdd 选项允许您在处理过程中使用传统的密钥 ID 值 CUID。较新的 KDD 值最常被使用，因此默认禁用这个选项(false)。这可让您配置新密钥集，以启用对新类密钥的支持。

例 6.2. 为 jForte 类启用支持

要启用对 jForte 类的支持，请设置：

tks.jForte._000=##
tks.jForte._001=## SAFLink's jForte default key set:
tks.jForte._002=##
tks.jForte._003=## tks.jForte.mk_mappings.#02#01=<tokenname>:<nickname>
tks.jForte._004=##
tks.jForte.auth_key=#30#31#32#33#34#35#36#37#38#39#3a#3b#3c#3d#3e#3f
tks.jForte.kek_key=#50#51#52#53#54#55#56#57#58#59#5a#5b#5c#5d#5e#5f
tks.jForte.mac_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.jForte.nistSP800-108KdfOnKeyVersion=00
tks.jForte.nistSP800-108KdfUseCuidAsKdd=false

请注意，与上例相比，3 静态会话键的区别。

证书系统支持 Secure Channel Protocol 03(SCP03)用于 Giesecke & Devrient(G&D)Smart Cafe 6 智能卡。要在 TKS 中启用对那些智能卡的 SCP03 支持，请在 /var/lib/pki/instance_name/tks/conf/CS.cfg 文件中设置：

tks.defKeySet.prot3.divers=emv
tks.defKeySet.prot3.diversVer1Keys=emv
tks.defKeySet.prot3.devKeyType=DES3
tks.defKeySet.prot3.masterKeyType=DES3

TPS 配置

当支持的客户端试图对令牌执行操作时，必须将 TPS 配置为识别新密钥集。默认 defKeySet 最常被使用。

决定 TPS 中的 keySet 的主要方法涉及第 6.7 节 “映射解析器配置”。有关建立此解析器机制所需的具体设置，请查看链接部分。

如果 KeySet Mapping Resolver 不存在，则 TPS 提供了几个回退方法来确定正确的 keySet ：

您可以将 tps.connector.tks1.keySet=defKeySet =defKeySet 添加到 TPS 的 CS.cfg 配置文件中。
某些客户端可以配置为显式传递所需的 keySet 值。但是，企业安全客户端在此刻没有此功能。
当 TPS 根据所需方法计算正确的 keySet 时，到 TKS 的所有请求来帮助创建安全频道传递 keySet 值。然后 TKS 可以使用自己的 keySet 配置（上述步骤）来确定如何继续。

6.13. 设置新主密钥

本节将描述在 Token Key Service(TKS)中设置新主密钥所需的步骤和配置。有关背景信息，请参阅 红帽认证系统规划、安装和部署指南。

过程 6.1. 创建新主密钥

获取访问 TKS 安全数据库所需的内部 PIN：

# cat /var/lib/pki/pki-tomcat/tks/conf/password.conf
internal=649713464822
internaldb=secret12
replicationdb=-752230707

打开 TKS 实例 的别名/ 目录：
```
# cd /var/lib/pki/pki-tomcat/alias
```

使用 tkstool 程序生成新的 master 密钥。例如：

# tkstool -M -n new_master -d /var/lib/pki/pki-tomcat/alias -h <token_name>
Enter Password or Pin for "NSS Certificate DB":

Generating and storing the master key on the specified token . . .

Naming the master key "new_master" . . .

Computing and displaying KCV of the master key on the specified token . . .

new_master key KCV:  CA5E 1764

验证密钥是否已正确添加到数据库中：

# tkstool -L -d .


 slot:  NSS User Private Key and Certificate Services
token:  NSS Certificate DB

Enter Password or Pin for "NSS Certificate DB":
        <0> new_master

6.13.1. 生成和传输主密钥（主要 Ceremony）

如果主密钥将用于外部令牌或多个位置，则必须进行嵌套，以便安全地传输到硬件令牌。tkstool 实用程序可用于生成传输密钥，然后用于将主密钥发送到生成令牌的设备。传输嵌套的 master 密钥的进程通常称为密钥 Ceremony。

注意

传输密钥只能用于生成的主密钥。

过程 6.2. 生成并传输 Wrapped 主密钥

获取访问 Token Key Service 安全数据库所需的内部 PIN：

# cat /var/lib/pki/pki-tomcat/tks/conf/password.conf

internal=649713464822
internaldb=secret12
replicationdb=-752230707

打开 TKS 实例 别名/ 目录：
```
# cd /var/lib/pki/pki-tomcat/alias
```
创建名为 transport 的 传输 密钥：
```
# tkstool -T -d . -n transport
```
注意
tkstool 程序输出每个生成的三个会话键的密钥共享和 KCV 值。将这些文件保存到文件中，因为稍后会在这个流程中的新数据库中重新生成传输密钥，并在丢失密钥时重新生成密钥。

出现提示时，填写数据库密码。然后，根据屏幕的说明生成随机 seed。

A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|************************************************************|

Finished.


Type the word "proceed" and press enter

下一提示将生成一系列会话密钥。按照屏幕说明操作，直到最终消息：
```
Successfully generated, stored, and named the transport key!
```

使用 transport 密钥生成并打包一个 master 密钥，并将其存储在名为 的文件 ：

# tkstool -W -d . -n new_master -t transport -o file 
Enter Password or Pin for "NSS Certificate DB":
Retrieving the transport key (for wrapping) from the specified token . . .
Generating and storing the master key on the specified token . . .
Naming the master key "new_master" . . .
Successfully generated, stored, and named the master key!
Using the transport key to wrap and store the master key . . .
Writing the wrapped data (and resident master key KCV) into the
 file called "file" . . .

       wrapped data:   47C0 06DB 7D3F D9ED
                       FE91 7E6F A7E5 91B9
       master key KCV: CED9 4A7B
       (computed KCV of the master key residing inside the wrapped data)

将嵌套的 master 密钥复制到适当的位置或工具中。
如有必要，在 HSM 或设备中生成新安全数据库：
```
# tkstool -N -d <directory>
```
或者，添加 -I 选项来生成与最初在新数据库中生成的键相同。以这种方式重新生成 transport 密钥需要您输入会话密钥共享和 KCV，用于这个过程早期生成的每个会话密钥。
```
# tkstool -I -d <directory> -n verify_transport
```

使用 transport 密钥来取消包装存储在文件中的主密钥。提示时提供安全数据库 PIN：

# tkstool -U -d directory -n new_master -t verify_transport -i file
Enter Password or Pin for "NSS Certificate DB":
Retrieving the transport key from the specified token (for
 unwrapping) . . .
Reading in the wrapped data (and resident master key KCV) from
 the file called "file" . . .

     wrapped data:   47C0 06DB 7D3F D9ED
                     FE91 7E6F A7E5 91B9
     master key KCV: CED9 4A7B
     (pre-computed KCV of the master key residing inside the wrapped data)

Using the transport key to temporarily unwrap the master key to
recompute its KCV value to check against its pre-computed KCV value . . .
     master key KCV: CED9 4A7B
     (computed KCV of the master key residing inside the wrapped data)
     master key KCV: CED9 4A7B
     (pre-computed KCV of the master key residing inside the wrapped data)

Using the transport key to unwrap and store the master key on the
 specified token . . .
Naming the master key "new_master" . . .
Successfully unwrapped, stored, and named the master key!

验证密钥是否已正确添加到数据库中：

# tkstool -L -d
slot:  NSS User Private Key and Certificate Services
token:  NSS Certificate DB

Enter Password or Pin for "NSS Certificate DB":
			 <0> transport
			 <1> new_master

6.14. 设置 TKS/TPS Shared Symmetric Key

共享对称密钥必须存在于 TPS 和 TKS 子系统的 NSS 数据库中。创建 TPS 子系统时会自动生成此密钥。如果同一 Tomcat 实例中都安装了 TPS 和 TKS，则不需要额外的设置，因为 TKS 会自动使用 TPS 创建的密钥；但是，如果两个子系统位于单独的实例上，或者根据这部分描述的步骤，必须按照本小节中介绍的步骤安全地将密钥传输到 TKS。

有几种可能的方法可用于安全地传输 TPS 和 TKS 之间的共享密钥：

authomatic 方法：当 TPS 的子系统证书保存在软件 NSS 数据库中时，此方法可以正常工作。
如果上述方法失败，可以使用一个回退手动方法，其中使用 tkstool 程序在 TPS 上生成共享密钥，这样可将密钥从 TPS 嵌套，在不在传输中公开密钥的情况下进行安全传输，并取消将其嵌套在 TKS NSS 数据库中。

下面描述了 TPS 和 TKS 的一般配置，无论用于导入密钥的方法如何。请注意，自动方法会自动生成这些配置。

TKS

tks.useNewSharedSecretNames=true
tps.0.host=dhcp-16-206.sjc.example.com
tps.0.nickname=TPS-<tps host name>-8443 sharedSecret
tps.0.port=8443
tps.0.userid=,TPS-<tps host name>-8443
tps.list=0

注意

当一个 TKS 连接到多个 TPS 实例时，上述列表可以扩展。

TPS

conn.tks1.tksSharedSymKeyName=TPS-<tps host name>-8443 sharedSecret

注意

主机名必须与 TKS 端配置的名称相同。

6.14.1. 手动生成和传输共享统计密钥

这部分论述了如何手动生成和传输共享对称密钥。如果自动生成和传输失败时，这种方法很有用，但在其他情况下应避免。

manual 方法包含两个流程。第一个是在 Token Key Service 一侧执行，第二个在令牌处理系统中执行。

过程 6.3. Manual Shared Secret Key Method - TKS side

在第一个系统上安装令牌密钥服务。有关安装说明，请参阅 红帽认证系统规划、安装和部署指南。

停止 TKS 服务：

#systemctl stop pki-tomcatd@pki-tomcat.service

更改到 /var/lib/pki/pki-tomcat/alias 目录，并使用 tkstool 在 TKS 上创建共享密钥。在重启新的 TKS 实例前，请确保生成共享密钥。

重要

tkstool 脚本将在密钥创建过程中显示密钥的相关信息。确保记下这些信息，因为稍后需要将密钥导入到 TPS。

#cd /var/lib/pki/pki-tomcat/alias
#tkstool -T -d /var/lib/pki/pki-tomcat/tks/alias -n TPS-<tps host name>-8443 sharedSecret
Generating the first session key share . . .
    first session key share:      792F AB89 8989 D902
                                  9429 6137 8632 7CC4
    first session key share KCV:  D1B6 14FD
Generating the second session key share . . .
    second session key share:      4CDF C8E0 B385 68EC
                                   380B 6D5E 1C19 3E5D
    second session key share KCV:  1EC7 8D4B
Generating the third session key share . . .
    third session key share:      CD32 3140 25B3 C789
                                  B54F 2C94 26C4 9752
    third session key share KCV:  73D6 8633
Generating first symmetric key . . .
Generating second symmetric key . . .
Generating third symmetric key . . .
Extracting transport key from operational token . . .
    transport key KCV:  A8D0 97A2
Storing transport key on final specified token . . .
Naming transport key "sharedSecret" . . .
Successfully generated, stored, and named the transport key!

在 TKS 中配置新密钥：

tks.useNewSharedSecretNames=true
tps.0.host=dhcp-16-206.sjc.redhat.com
tps.0.nickname=TPS-<tps host name>-8443 sharedSecret
tps.0.port=8443
tps.0.userid=TPS-<tps host name>-8443 sharedSecret
tps.list=0

启动 TKS：

#systemctl start pki-tomcatd@pki-tomcat.service

过程 6.4. 手动共享 secret 密钥方法 - TPS 侧

在第二个系统上安装令牌处理系统。有关安装说明，请参阅 红帽认证系统 9 规划、安装和部署指南。

停止 TPS 服务：

#systemctl stop pki-tomcatd@pki-tomcat.service

更改到 /var/lib/pki/pki-tomcat/alias 目录，并使用 tkstool 将共享密钥导入到 NSS 软件令牌中：
```
#cd /var/lib/pki/pki-tomcat/alias
#tkstool -I -d . -n TPS-<tps host name>-8443 sharedSecret
```
此时，脚本会提示您生成并嵌套在上述流程中的 TKS 一侧显示的会话密钥共享。

在 TPS 中配置共享 secret：

conn.tks1.tksSharedSymKeyName=TPS-<tps host name>-8443 sharedSecret

启动 TPS 服务：

#systemctl start pki-tomcatd@pki-tomcat.service

6.15. 将不同的 Applets 用于不同的 SCP 版本

在证书系统中，/var/lib/instance_name/tps/conf/CS.cfg 文件中的以下参数指定应该为每个令牌操作载入哪个小应用程序：

op.operation.token_type.update.applet.requiredVersion=version

但是，您还可以通过添加以下参数来为特定的 SCP 版本设置单独的应用程序：

op.operation.token_type.update.applet.requiredVersion.prot.protocol_version=version

证书系统支持为以下操作设置单独的协议版本：

格式
enroll
pinReset

例 6.3. 为注册操作设置协议版本

在为 userKey 令牌执行注册操作时，要为 SCP03 和所有其他协议配置特定的小应用程序：

编辑 /var/lib/instance_name/tps/conf/CS.cfg 文件：
1. 设置 op.enroll.userKey.update.applet.requiredVersion 参数，以指定默认使用的小程序。例如：
```
op.enroll.userKey.update.applet.requiredVersion=1.4.58768072
```
2. 设置 op.enroll.userKey.update.applet.requiredVersion.prot.3 参数，以配置应用程序证书系统用于 SCP03 协议。例如：
```
op.enroll.userKey.update.applet.requiredVersion.prot.3=1.5.558cdcff
```

重启证书系统：

systemctl restart pki-tomcatd@instance_name.service

有关为 Giesecke 和 Devrient(G&D)智能 Cafe 6 智能卡在 TKS 中启用 SCP03 的详情，请参考第 6.12 节 “设置新密钥设置”。

第 7 章撤销证书和发布 CRL

CertificateCertificate Systemnbsp;System 提供了撤销证书的方法，以及生成撤销的证书列表，称为证书撤销列表(CRL)。本章论述了撤销证书的方法，描述了 CMC 撤销调用，并提供有关 CRL 和设置 CRL 的详情。

7.1. 关于撤销证书

证书可以被最终用户（证书的原始所有者）或证书管理器代理撤销。最终用户可以使用在端点页面中提供的撤销表单来撤销证书。代理可以使用代理服务接口中的适当形式来撤销最终用户证书。这两种情况下都需要使用基于证书的（SSL/TLS 客户端身份验证）。

最终用户只能撤销包含与用于身份验证的证书相同的主题名称的证书。身份验证成功后，服务器会列出属于最终用户的证书。然后，最终用户可以选择被撤销的证书，也可以撤销列表中的所有证书。最终用户还可指定其他详情，如每个证书的撤销日期和撤销原因，或针对整个列表指定列表。

代理可以基于一系列序列号或基于主题名称组件来撤销证书。提交撤销请求时，代理会收到一个证书列表，从中可以选择一个要撤销的证书。有关代理如何撤销终止证书的说明，请参阅 Red Hat 证书系统 9 规划、安装和部署指南。

撤销请求后，证书管理器会将其内部数据库中对应的证书记录标记为已撤销，如果配置为这样做，则从发布目录中删除已撤销的证书。这些更改反映在 CA 问题的下一个 CRL 中。

使用公钥证书的服务器和客户端应用程序作为 ID 令牌需要访问证书的有效性。由于确定证书的有效性的因素之一就是其撤销状态，所以这些应用程序需要了解要被验证的证书是否已被撤销。CA 负责执行以下操作：

如果 CA 收到了撤销请求并批准，则撤销证书。
将撤销的证书状态提供给需要验证其有效状态的第三方或应用程序。

每当证书被撤销时，证书管理器都会自动更新其内部数据库中证书的状态，它会将其内部数据库中的证书副本标记为已撤销状态并从发布目录中移除证书。如果证书管理器被配置为从数据库中删除证书。

用于分发证书的标准方法之一是发布已撤销的证书列表，称为证书撤销列表(CRL)。CRL 是一个公开可用证书列表，已撤销。

证书管理器可以被配置为生成 CRL。通过在 CRL 配置中启用特定于扩展的模块，可以创建这些 CRL 以符合 X.509 标准。服务器通过其 CRL 发出点框架支持标准 CRL 扩展 ; 有关为发出点设置 CRL 扩展的更多信息，请参阅第 7.3.3 节 “设置 CRL 扩展”。证书管理器可以在每次证书被撤销和定期间隔时生成 CRL。如果设置了发布，则 CRL 可以发布到文件、LDAP 目录或 OCSP 响应程序。

发布 CRL 并由发布 CRL 中列出的证书的 CA 发布或由该 CA 授权的实体发布并签名以发布 CRL 的实体。CA 可使用单个密钥对为证书和 CRL 签名它，或两个单独的密钥对，一个用于签名 CRL，另一个用于签名 CRL。

默认情况下，证书管理器使用一个密钥对对它生成的证书和 CRL 进行签名。要为证书管理器创建另一个密钥对，并专门用于签名 CRL，请参阅第 7.3.4 节 “将 CA 设置为使用其他证书来签名 CRL”。

在签发点时生成 CRL，并配置了启用了 CRL 生成的时间。

启用 CRL 后，服务器会在撤销证书时收集撤销信息。服务器会尝试将撤销的证书与设置的所有发布点匹配。给定证书无法匹配任何发布点、其中一个发布点、多个发布点或所有发布点。当被撤销的与发布点匹配的证书时，服务器会将有关证书的信息存储在发出点的缓存中。

缓存会复制到内部目录，并以为复制缓存设定的时间间隔。当达到创建 CRL 的时间间隔时，会从缓存创建一个 CRL。如果为此发布点设置了 delta CRL，此时也会创建一个 delta CRL。完整的 CRL 包含所有已撤销的证书信息，因为证书管理器开始收集这些信息。delta CRL 包含自完整 CRL 最后一次更新以来所有已撤销的证书信息。

完整的 CRL 按顺序编号，如 delta CRL。完整 CRL 和 delta CRL 可以有相同的数字；在这种情况下，delta CRL 的编号与 下一个 完整 CRL 相同。例如，如果完整的 CRL 是第一个 CRL，则代表 CRL 1。delta CRL 为 Delta CRL 2。CRL 1 和 Delta CRL 2 中的数据与下一个完整的 CRL 相同，即 CRL 2。

注意

当修改发布点的扩展时，不会使用发出该点的下一个完整 CRL 创建 delta CRL。使用创建 的第二个 完整 CRL 创建 delta CRL，然后所有后续完整 CRL。

内部数据库仅存储最新的 CRL 和 delta CRL。在创建每个新 CRL 时，旧的 CRL 将被覆盖。

当发布 CRL 时，对 CRL 和 delta CRL 每次更新都会发布到发布集合中指定的位置。发布方法决定了存储了多少个 CRL。对于文件发布，每个 CRL 使用 CRL 数量发布到文件中，因此不会覆盖任何文件。对于 LDAP 发布，发布的每个 CRL 都会替换包含目录条目中的 CRL 属性中的旧 CRL。

默认情况下，CRL 不包含关于已撤销过期证书的信息。服务器可通过为发出点启用该选项，包括撤销的过期证书。如果包含过期的证书，当证书过期时，不会从 CRL 中删除关于已撤销证书的信息。如果没有包含过期的证书，则在证书过期时从 CRL 中删除有关已撤销证书的信息。

7.1.1. 用户初始化的调用

当最终用户提交证书撤销请求时，撤销过程中的第一步就是证书管理器来识别和验证最终用户，以验证用户是否尝试撤销自己的证书，而不是属于他人的证书。

在 SSL/TSL 客户端身份验证中，服务器需要最终用户提供与要撤销的主题名称相同的证书，并将其用于身份验证目的。服务器通过在内部数据库中为客户端身份验证的证书中的主体名称映射，来验证撤销请求的真实性。只有在证书映射到其内部数据库中的一个或多个有效或过期证书时，服务器才会撤销证书。

身份验证成功后，服务器会列出与为客户端身份验证提供的证书的主题名称相匹配的有效或过期的证书。然后用户可以选择要撤销的证书或撤销列表中所有证书。

7.1.2. 撤销证书的原因

证书管理器可以撤销其发出的任何证书。通常，撤销 CRL 中通常包含的证书的接受原因代码，如下所示：

0.Unspecified; 没有特定原因。
1.与证书关联的私钥已被破坏。
2.与发布证书的 CA 关联的私钥已被破坏。
3.证书的所有者不再与证书颁发者相关，并且没有证书获得的访问权限或不再需要它的权限。
4.另一个证书取代了这个证书。
5.发布证书的 CA 已创建要操作的 CA。
6.该证书正在保存等待的进一步操作。它被视为已撤销，但将来可能会发生，以便证书再次激活并有效。
8.该证书将从 CRL 中删除，因为它已从拥有中移除。这只适用于 delta CRL。
9.该证书会被撤销，因为证书所有者的权限已被撤回。

证书可以被管理员、代理和最终实体撤销。带有代理权限的代理和管理员可使用代理服务页面中的表单撤销证书。最终用户可以使用端点接口的 Revocation 选项卡中的表单来撤销证书。最终用户只能撤销自己的证书，而代理和管理员可以撤销服务器发布的任何证书。为了撤销证书，还需要最终用户对服务器进行身份验证。

每当撤销证书时，证书管理器会在其内部数据库中更新证书的状态。服务器使用内部数据库中的条目来跟踪所有已撤销的证书，并在配置后，通过向中央存储库发布 CRL，以通知列表中的其他用户不再有效。

7.1.3. CRL 签发点

由于 CRL 可能会增长非常大，因此有几种方法可以尽量减少检索和交付大型 CRL 的开销。这些方法之一会对整个证书空间进行分区，并将一个单独的 CRL 与每个分区相关联。此分区称为 CRL 发布点，即维护所有已撤销证书的子集的位置。分区可以基于被撤销的证书是 CA 证书，无论是出于特定原因被撤销，还是使用特定配置集发布的。每个发布点都由其名称来标识。

默认情况下，证书管理器生成并发布单个 CRL，即 master CRL。发行点可为所有证书生成 CRL，仅适用于 CA 签名证书，或为所有证书（包括过期的证书）生成 CRL。

定义了发布点后，它们可以包含在证书中，以便需要检查证书的撤销状态的应用程序可以访问证书中指定的 CRL 发出点，而不是 master 或主 CRL。由于在发布点上维护的 CRL 比 master CRL 小，因此检查撤销状态更快。

通过设置 CRLDistributionPoint 扩展，可将 CRL 分发点与证书关联。

7.1.4. Delta CRLs

可以为任何定义的发布点发布 delta CRL。delta CRL 包含有关从最后更新到完整 CRL 后撤销的任何证书的信息。通过启用 DeltaCRLIndicator 扩展来创建发布点的 delta CRL。

7.1.5. 发布 CRL

证书管理器可将 CRL 发布到文件、LDAP 兼容目录或 OCSP 响应者。在证书管理器中发布 CRL 的位置和频率，如第 8 章 发布证书和 CRL 所述。

因为 CRL 可能非常大，所以发布 CRL 可能需要很长时间，所以可能会中断进程。可以将特殊发布程序配置为通过 HTTP1.1 将 CRL 发布到文件，如果进程中断，则 CA 子系统的 Web 服务器可以在其中断时恢复发布，而不必再次开始发布。第 8.8 节 “设置恢复 CRL 下载” 中描述的。

7.1.6. 证书调用页

证书管理器的端点页面包括默认 HTML 表单，用于撤销通过 SSL/TLS 客户端验证的调用。表单可从 Revocation 标签页访问。您可以点击 User Certificate 链接来查看此类撤销的表单。

要更改表单外观来满足机构的要求，请编辑 UserRevocation.html，它的格式允许 SSL/TSL 客户端被验证地撤销客户端或个人证书。该文件位于 /var/lib/instance_name/webapps/subsystem_type/ee/subsystem_type 目录中。

7.2. 执行 CMC Revocation

与证书管理 over CMS(CMC)注册类似，CMC revocation 允许用户设置撤销客户端，并使用代理证书或具有匹配 subjectDN 属性的用户证书签署撤销请求。然后用户可以向证书管理器发送签名请求。

另外，CMC 撤销程序也可以使用 Shared Secret Token 机制进行身份验证。详情请参阅 红帽认证系统规划、安装和部署指南。

无论用户或代理是否为请求签名，或者是否使用了共享 Secret 令牌，证书管理器会在收到有效撤销请求时自动撤销证书。

证书系统为 CMC 撤销请求提供以下工具：

CMCRequest.详情请查看第 7.2.1 节 “使用 CMCRequest撤销证书”。
CMCRevoke.详情请查看第 7.2.2 节 “使用 CMCRevoke撤销证书”。

重要

红帽建议使用 CMCRequest 工具生成 CMC 重新调用请求，因为它提供了大于 CMCRevoke 的选项。

7.2.1. 使用 `CMCRequest`撤销证书

使用 CMCRequest 撤销证书：

为 CMC 撤销请求创建一个配置文件，如 /home/user_name/cmc-request.cfg，其中包含以下内容：

#numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#output: full path for the CMC request in binary format
output=/home/user_name/cmc.revoke.userSigned.req

#tokenname: name of token where user signing cert can be found
#(default is internal)
tokenname=internal

#nickname: nickname for user signing certificate which will be used
#to sign the CMC full request.
nickname=signer_user_certificate

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert8.db which stores the user signing
#certificate and keys
password=myPass

#format: request format, either pkcs10 or crmf.
format=pkcs10

## revocation parameters
revRequest.enable=true
revRequest.serial=45
revRequest.reason=unspecified
revRequest.comment=user test revocation
revRequest.issuer=issuer
revRequest.sharedSecret=shared_secret

创建 CMC 请求：
```
# CMCRequest /home/user_name/cmc-request.cfg
```
如果命令成功，则 CMCRequest 程序会在请求配置文件的 output 参数中指定的文件中存储 CMC 请求。

创建配置文件，如 /home/user_name/cmc-submit.cfg，您可以在稍后的步骤中使用该文件，将 CMC 撤销请求提交到 CA。在创建的文件中添加以下内容：

#host: host name for the http server
host=>server.example.com

#port: port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be
#in binary format
input=/home/user_name/cmc.revoke.userSigned.req

#output: full path for the response in binary format
output=/home/user_name/cmc.revoke.userSigned.resp

#tokenname: name of token where SSL client authentication certificate
#can be found (default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=/home/user_name/.dogtag/nssdb/

#clientmode: true for client authentication, false for no client
#authentication. This parameter will be ignored if secure=false
clientmode=true

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=signer_user_certificate

重要

如果 CMC 撤销请求已签名，则将 secure 和 clientmode 参数设置为 true，再填充 nickname 参数。

根据对请求签名的，Http Client 配置文件中的 servlet 参数必须相应地设置：
- 如果代理对请求进行了签名，请设置：
```
servlet=/ca/ee/ca/profileSubmitCMCFull
```
- 如果用户签名了请求，请设置：
```
servlet=/ca/ee/ca/profileSubmitSelfSignedCMCFull
```

提交 CMC 请求：

# HttpClient /home/user_name/cmc-submit.cfg

有关使用 CMCRequest 撤销证书的详情，请查看 CMCRequest(1) man page。

7.2.2. 使用 `CMCRevoke`撤销证书

CMC 撤销程序 CMCRevoke 用于通过代理的证书为撤销请求签名。这个实用程序只传递必要的信息 - 证书序列号、签发者名称和撤销原因 - 来标识要撤销的证书，然后标识执行撤销的 CA 代理（certificate nickname 和带有证书的数据库）。

正在撤销证书的原因可以是以下任意一种（带有传递给 CMCRevoke 实用程序的值）：

0 - 未指定
1 - 密钥已被破坏
2 - CA 密钥已被破坏
3 - 员工附属机构已改变
4 - 证书已被替换
5 - 操作考虑
6 - 证书位于

有关可用工具参数的详细信息，请参阅 命令行工具指南。

7.2.2.1. 测试 CMCRevoke

为现有证书创建 CMC 撤销请求。
```
CMCRevoke -d/path/to/agent-cert-db -nnickname -iissuerName -sserialName -mreason -ccomment
```
例如，如果包含代理证书的目录是 ~jsmith/.mozilla/firefox/，则证书的别名为 AgentCert，并且命令的序列号为 22，如下所示：
```
CMCRevoke -d"~jsmith/.mozilla/firefox/" -n"ManagerAgentCert" -i"cn=agentAuthMgr" -s22 -m0 -c"test comment"
```
注意
在引号中包含空格的值会包括在引号中。
重要
在参数及其值之间没有空格。例如，指定序列号为 26 的序列号为 -s26，而不是 -s 26。

打开"终端"页面。

https://server.example.com:8443/ca/ee/ca

选择 Revocation 选项卡。
选择菜单上的 CMC Revoke 链接。
将 CMCRevoke 的输出粘贴到文本区域。
从粘贴的内容中删除 -----BEGIN NEW CERTIFICATE REQUEST----- 和 ----END NEW CERTIFICATE REQUEST-----。
点 Submit。
返回后的页面应确认已撤销了正确的证书。

7.3. 发出 CRL

证书管理器使用其 CA 签名证书密钥来签署 CRL。要为 CRL 使用单独的签名密钥对，请设置 CRL 签名密钥并更改证书管理器配置，以使用此密钥为 CRL 签名。如需更多信息，请参阅第 7.3.4 节 “将 CA 设置为使用其他证书来签名 CRL”。
设置 CRL 发行点。已经为 master CRL 设置并启用了一个发布点。
图 7.1. 默认 CRL 发行点
可以创建 CRL 的额外发布点。详情请查看第 7.3.1 节 “配置发行得分”。
根据配置发布点时所设置的选项，还会有五种 CRL 的 CRL 类型来定义 CRL 将列出的内容：
- Master CRL 包含来自整个 CA 的已撤销证书的列表。
- ARL 是一个授权撤销列表，仅包含已撤销的 CA 证书。
- 带有过期证书的 CRL 包括撤销在 CRL 中过期的证书。
- 证书配置集中的 CRL 决定基于最初创建证书的配置集包括的已撤销证书。
- 由原因代码的 CRL 决定 基于撤销原因代码中包含的已撤销证书。
为每个发布点配置 CRL。详情请查看第 7.3.2 节 “为每个发行点配置 CRL”。
设置为发出点配置的 CRL 扩展。详情请查看第 7.3.3 节 “设置 CRL 扩展”。
通过为该发出点、DeltaCRLIndicator 或 CRLumber 启用扩展来为发布点设置 delta CRL。
设置 CRLDistributionPoint 扩展，以包含有关发布点的信息。
将发布 CRL 设置为文件、LDAP 目录或 OCSP 响应程序。有关设置发布的详情，请参阅第 8 章 发布证书和 CRL。

7.3.1. 配置发行得分

发出点会定义哪些证书包括在新的 CRL 中。默认情况下，为 master CRL 创建一个 master CRL 发出点，其中包含证书管理器的所有已撤销证书列表。

要创建新发布点，请执行以下操作：

打开 CertificateCertificate Systemnbsp;System Console。
```
pkiconsole https://server.example.com:8443/ca
```
在 Configuration 选项卡中，从左侧导航菜单中展开 Certificate Manager。然后选择 CRLsuing Points。
要编辑发布点，请选择发布点，然后单击编辑。唯一可以编辑的参数是发出点的名称，以及发出点是否启用还是禁用。
要添加发布点，请单击 Add。CRL Issuing Point Editor 窗口将打开。
图 7.2. CRL Issuing Point Editor
注意
如果某些字段没有足够大来读取内容，请拖动该图标中的一个窗口。
填写以下字段：
- 启用。如果选择，启用发出点；取消选择"禁用"。
- CRL 签发者名称。为发出点指定名称；不允许使用空格。
- 描述。描述发布点。
点击 OK。

要查看并配置新的发布点，请关闭 CA 控制台，然后再次打开控制台。新的发布点列在导航树中的 CRLsuing Points 条目下。

为新的发布点配置 CRL，并设置任何 CRL 扩展来与 CRL 搭配使用。有关配置发布点的详情，请参阅第 7.3.2 节 “为每个发行点配置 CRL”。有关设置 CRL 扩展的详情，请参阅第 7.3.3 节 “设置 CRL 扩展”。创建的所有 CRL 会显示在代理服务页面的 Update Revocation List 页面中。

7.3.2. 为每个发行点配置 CRL

在发出点上，都可为 CRL 生成间隔、CRL 扩展和签名算法配置信息。必须为每个发出点配置 CRL。

打开 CA 控制台。

pkiconsole https://server.example.com:8443/ca

在导航树中，选择 Certificate Manager，然后选择 CRL Issuing Points。
选择 Issuing Points 条目下方的发布点名称。
通过提供发布点的 Update 选项卡中的信息，配置 CRL 如何和更新的频率。此选项卡有两个部分，即 Update Schema 和 Update Frequency。
- Update Schema 部分有以下选项：
  - 启用 CRL 生成。此复选框设置是否为该发出点生成 CRL。
  - 每 # delta(s)生成完整的 CRL。此字段根据更改数量设置如何创建 CRL 的频率。
  - 下次在完整的 CRL 中扩展更新时间。这提供了一个选项，可在生成的 CRLs 中设置 nextUpdate 字段。nextUpdate 参数显示发布下一个 CRL 的日期，无论它是完整的还是 delta CRL。当使用完整和 delta CRL 的组合时，在完整 CRL 中启用下一次 更新时间将使 下一个Update 参数在完整的 CRL 中显示，当下 一个完整的 CRL 时。否则，完整 CRL 中的 nextUpdate 参数会显示何时发出下一个 delta CRL，因为增量是要发布的下一个 CRL。
- Update Frequency 部分在生成 CRL 并发布到目录中时设置不同的间隔。
  - 每次证书被撤销或释放证书时，都会为。这会将证书管理器设置为在每次撤销证书时生成 CRL。证书管理器会在生成 CRL 时尝试向已配置的目录发出 CRL。如果 CRL 较大，则生成 CRL 会消耗大量时间。将证书管理器配置为在每次撤销证书时生成 CRL，可能会使服务器参与大量时间；在此期间，服务器将无法更新接收任何更改的目录。
    不建议在标准安装中使用此设置。应该选择这个选项来立即测试撤销，例如测试服务器是否将 CRL 发送到平面文件。
  - 更新位于的 CRL。此字段在应更新 CRL 时设置每日时间。要多次指定，请输入逗号分隔列表，如 01:50,04:55,06:55。要为多个天输入计划，请输入用逗号分开的列表，在同一天内设置时间，然后是分号隔开的列表来识别不同天数的时间。例如，这会在位于 1:50am、4:55am 和 6:55am，然后在第 2:am、5am 和 5pm 的第 2 天时设置撤销第 1 天：
    01:50,04:55,06:55;02:00,05:00,17:00
  - 每一次更新 CRL。这个复选框启用了在字段中设置的间隔生成 CRL。例如，要每天发出 CRL，请选择复选框，然后在此字段中输入 1440。
  - 下次更新宽限期。如果证书管理器以特定频率更新 CRL，可以将服务器配置为在下次更新时有一个宽限期，以允许创建 CRL 并发出它。例如，如果服务器被配置为每 20 分钟更新一次 CRL，则宽限期为 2 分钟，如果 CRL 在 16:00 上更新，则 CRL 会重新更新 16:18。
重要
由于一个已知问题，当当前设置 full 和 delta Certificate Revocation List 计划时，每次从 hold 选项撤销或释放证书时，更新 CRL 也要求您填充两个 宽限期 设置。因此，要选择此选项，首先需要选择 更新 CRL 每一个 选项，并为 下一步更新宽限期 # 分钟 输入数字。
Cache 选项卡设置是否启用缓存以及缓存频率。
图 7.3. CRL Cache 选项卡
- 启用 CRL 缓存。这个复选框启用了缓存，用于创建 delta CRL。如果禁用了缓存，则不会创建 delta CRL。有关缓存的详情请参考第 7.1 节 “关于撤销证书”。
- 更新每个缓存。此字段设定将缓存写入内部数据库的频率。设置为 0，在每次撤销证书时，将缓存写入数据库。
- 启用缓存恢复。这个复选框允许恢复缓存。
- 启用 CRL 缓存测试。此复选框为特定 CRL 发出点启用 CRL 性能测试。使用这个选项生成的 CRL 不应在部署的 CA 中使用，因为为测试目的发布的 CRL 包含只为性能测试生成的数据。
Format 选项卡设定创建的 CRL 的格式和内容。CRL Format 和 CRL 内容有两个部分。
图 7.4. CRL Format 选项卡
- CRL Format 部分有两个选项：
  撤销列表签名算法是一个允许加密 CRL 的密码的下拉列表。
  允许 CRL v2 的扩展是一个复选框，为发出点启用 CRL v2 扩展。如果启用了此项，请设置第 7.3.3 节 “设置 CRL 扩展” 中描述的所需 CRL 扩展。
  注意
  必须开启扩展来创建 delta CRL。
- CRL Contents 部分有三个复选框，用于设置要在 CRL 中包含哪些类型的证书：
  包括过期的证书。这包括已撤销已过期的证书。如果启用此项，有关已撤销证书的信息会在证书过期后保留在 CRL 中。如果没有启用此项，则证书过期时会删除关于已撤销证书的信息。
  仅 CA 证书.这只包括 CRL 中的 CA 证书。选择这个选项会创建一个授权 Revocation List(ARL)，它仅列出已撤销的 CA 证书。
  根据配置文件发布的证书.这只包括根据列出的配置集发布的证书 ; 指定多个配置集，输入用逗号分开的列表。
点 Save。
此发布点允许扩展，并可配置。详情请查看第 7.3.3 节 “设置 CRL 扩展”。

7.3.3. 设置 CRL 扩展

注意

只有在为该发出点选择了 Allow extensions for CRLs v2 复选框时，扩展才需要配置为发布点。

创建发布点时，会自动启用三个扩展： CRLReason、InvalidityDate 和 CRLNumber。其他扩展可用，但默认为禁用。这些可以被启用和修改。有关可用 CRL 扩展的更多信息，请参阅第 B.4.2 节 “标准 X.509 v3 CRL 扩展参考”。

要配置 CRL 扩展，请执行以下操作：

打开 CA 控制台。

pkiconsole https://server.example.com:8443/ca

在导航树中，选择 Certificate Manager，然后选择 CRL Issuing Points。
选择发行点条目下的发布点名称，并在发布点下选择 CRL Extension 条目。
右窗格显示 CRL Extensions Management 选项卡，它列出了配置的扩展。
图 7.5. CRL 扩展
要修改规则，请选择它，再单击 Edit/View。
大多数扩展有两个选项，启用它们并对其进行设置，无论它们是否至关重要。有些人需要更多信息。提供所有必填值。有关每个扩展以及这些扩展的参数，请参阅第 B.4.2 节 “标准 X.509 v3 CRL 扩展参考”。
点击 OK。
点 Refresh 查看所有规则的更新状态。

7.3.4. 将 CA 设置为使用其他证书来签名 CRL

有关如何通过编辑 CS.cfg 文件配置此功能的说明，请参阅在 Red Hat Certificate System Planning、安装和部署指南中的设置 CA 使用其他证书来签名 CRL 部分。

7.3.5. 从缓存生成 CRL

默认情况下，CRL 从 CA 的内部数据库生成。但是，可以收集撤销信息，因为证书会被撤销并保存在内存中。然后，可以使用这个撤销信息从内存中更新 CRL。绕过从内部数据库生成 CRL 所需数据库搜索，显著提高性能。

注意

由于从缓存生成 CRL 的性能增强，请在大多数环境中启用 enableCRLCache 参数。但是，在生产环境中不应 启用 Enable CRL 缓存测试 参数。

7.3.5.1. 在控制台中配置 CRL Generation from Cache

打开控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，展开 Certificate Manager 文件夹和 CRL 签发点子文件夹。
选择 MasterCRL 节点。
选择 Enable CRL cache。
保存更改。

7.3.5.2. 在 CS.cfg 中配置 CRL Generation from Cache

有关如何通过编辑 CS.cfg 文件配置此功能的说明，请参考 红帽认证系统规划、安装和部署指南中的 CS.cfg 中的缓存配置 CRL Generation。

7.4. 设置 Full 和 Delta CRL Schedules

CRL 定期生成。在第 7.3.2 节 “为每个发行点配置 CRL” 中的配置中涉及该周期。

根据基于时间的时间表发布 CRL。每次证书被在特定时间或每一天一次撤销一次 CRL 时，可以发布一次 CRL。

基于时间的 CRL 生成计划适用于生成的每个 CRL。有两种类型的 CRL，完整的 CRL 和 delta CRL。完整的 CRL 拥有每个已撤销的证书，而 delta CRL 仅包含自上次 CRL（增量或完整）被撤销的证书。

默认情况下，按照调度的每个指定间隔生成完整的 CRL。通过生成增量 CRL，可以在生成完整 CRL 之间耗尽时间。在 CRL 模式 中配置生成间隔，它会设置生成 delta 和完整 CRL 的方案。

如果间隔设为 3，例如，生成的第一个 CRL 将是 full 和 delta CRL，那么下一个生成的更新仅是 delta CRL，则第四个间隔同时是 full 和 delta CRL。换句话说，每个第三代间隔都有完整的 CRL 和 delta CRL。

Interval   1, 2, 3, 4, 5, 6, 7 ...
Full CRL   1        4        7 ...
Delta CRL  1, 2, 3, 4, 5, 6, 7 ...

注意

除了完整的 CRL 外，要生成 delta CRL，必须启用 CRL 缓存。

7.4.1. 在控制台中配置 CRL 更新间隔

打开控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，展开 Certificate Manager 文件夹和 CRL 签发点子文件夹。
选择 MasterCRL 节点。
在 Generate full CRL every # delta(s) 字段中输入所需的间隔。
通过指定证书重新调用、循环间隔或设置更新所需的时间来设置更新频率：
- 每次证书被撤销或释放证书时，选择更新 CRL。每次从 hold 选项撤销或释放证书时，更新 CRL 还需要填写两个 Grace period 设置。这是一个已知问题，错误会在 Red Hat Bugzilla 中跟踪。
- 每次证书被撤销或释放证书时，选择更新 CRL。
- 选中 Update CRL at 复选框，并输入以逗号分开的特定时间，如 01:50,04:55,06:55。
- 选择更新 CRL 并输入所需间隔，如 240。
保存更改。

重要

每次从 hold 选项撤销或释放证书时，更新 CRL 还需要填写两个宽限期设置。这是一个已知问题，错误会在 Red Hat Bugzilla 中跟踪。

注意

按间隔更新 CRL 时可能会出现调度偏移。通常，偏移会因手动更新和 CA 重启而出现。

要防止调度偏移，请选中 Update CRL at 复选框，然后输入一个值。更新间隔更新将每 24 小时重新同步更新 CRL 的值。

当按间隔更新 CRL 时，只接受值的更新 CRL。

7.4.2. 为 CS.cfg 中的 CRL 配置更新间隔

有关如何通过编辑 CS.cfg 文件配置此功能的说明，请参阅 红帽认证系统规划、安装和部署指南中的 CS.cfg 中的 CRL 配置更新间隔 部分。

7.4.3. 在多天配置 CRL Generation Schedules

默认情况下，CRL 生成计划时间 24 小时。另外，如果启用了 full 和 delta CRLs，则默认以特定间隔发生完整的 CRL，即每个第三个更新一次或全部 delta CRL。

要在多个天内设置 CRL 生成调度，时间列表使用逗号将同一天内次数隔离，并将分号分隔为分隔符：

ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00;02:00,05:00,17:00

本例在每天 01:00、03:00 和 18:00 的时间更新 CRL，调度时间为 02:00、05:00 和 17:00。在第三天，周期再次开始。

注意

分号表示新日期。使用分号开始列表会导致生成没有 CRL 的初始日。同样，以分号结束的列表将最后一天添加到不生成 CRL 的时间表中。两分号一起会导致每天没有 CRL 生成。

要设置独立于 delta 更新的完整 CRL 更新，则时间值会加上星号，以指示应该发生完整的 CRL 更新：

ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00,*23:00;02:00,05:00,21:00,*23:30

这个示例在一天 01:00、03:00 和 18:00 中生成 delta CRL 更新，并在 23:00 完整且增量型 CRL 更新。在第二天，增量 CRLs 在 02:00、05:00 和 21:00 进行了更新，并在 23:30 完整且增量型 CRL 更新中。第三天，周期会再次启动。

注意

分号和星号语法在控制台以及手动编辑 CS.cfg 文件时工作。

7.5. 启用撤销检查

撤销检查意味着 CertificateCertificate Systemnbsp;System 子系统验证证书是否有效，并在代理或管理员试图访问实例的安全接口时撤销。这会利用本地 OCSP 服务（CA 的内部 OCSP 服务或单独的 OCSP 响应程序）检查证书的撤销状态。

OCSP 配置包括在第 7.6 节 “使用在线证书状态协议(OCSP)响应” 中。

请参阅 红帽认证系统规划、安装和部署指南中的 对 CA 启用自动撤销检查。

请参阅 红帽证书系统规划、安装和部署指南中的启用证书撤销检查功能。

7.6. 使用在线证书状态协议(OCSP)响应

7.6.1. 设置 OCSP Responder

如果在配置了 Online Certificate Status Manager 时选择了安全域中的 CA，则不需要额外的步骤来配置 OCSP 服务。CA 的 CRL 发布会自动设置，其签名证书会在在线证书状态管理器的证书数据库中自动添加和信任。但是，如果选择了非安全域 CA，必须在配置在线证书状态管理器后手动配置 OCSP 服务。

注意

在配置了 OCSP Manager 时，OCSP Manager 将自动信任 OCSP Manager 中的每个 CA。在 CA 面板中配置的 CA 证书链中的每个 CA 都由 OCSP Manager 自动信任。安全域中的其他 CA，但不能在证书链中被手动信任。

要为安全域以外的证书管理器设置在线证书状态管理器：

为每个将发布到 OCSP 响应器的 CA 配置 CRL。
启用发布、设置发布程序，并在 OCSP 服务将处理每个 CA 中设置发布规则(第 8 章 发布证书和 CRL)。如果证书管理器发布到 LDAP 目录，并且将在线证书状态管理器设置为从该目录中读取，则不需要这一步。
证书配置集必须被配置为包括授权信息访问扩展，指向证书管理器在哪个位置侦听 OCSP 服务请求(第 7.6.4 节 “启用证书管理器的内部 OCSP 服务”)。
配置 OCSP Responder。
- 配置 Revocation Info 存储（第 7.6.2.2 节 “配置 Revocation Info Stores: Internal Database” 和第 7.6.2.3 节 “配置 Revocation Info Stores: LDAP Directory”）。
- 识别每个发布证书管理器到 OCSP 响应器(第 7.6.2 节 “将 CA 识别到 OCSP Responder”)。
- 如有必要，配置对对 OCSP 签名证书(第 16.7 节 “更改 CA 证书的信任设置”)的 CA 的信任设置。
在配置这两个子系统后，重启这两个子系统。
验证 CA 是否已正确连接到 OCSP 响应器(第 7.6.2.1 节 “验证证书管理器和在线证书状态管理器连接”)。

7.6.2. 将 CA 识别到 OCSP Responder

在将 CA 配置为将 CRL 发布到在线证书 Status Manager 之前，必须通过将 CA 签名证书存储在在线证书管理器的内部数据库中来识别 CAL。证书管理器使用与此证书关联的密钥对签名 CRL；在线证书状态管理器对已存储的证书验证签名。

注意

如果在配置了在线证书状态管理器时选择了安全域中的 CA，则不需要额外的步骤来配置在线证书状态管理器来识别 CA；在线证书管理器在 Online Certificate Status Manager 的证书数据库中自动添加并信任 CA 签名证书。但是，如果选择了非安全域 CA，必须在配置了在线证书 Status Manager 后手动将 CA 签名证书添加到证书数据库中。

不需要为 CA 导入证书链，它将将其 CRL 发布到在线证书 Status Manager。OCSP 服务只需要证书链的唯一时间是，如果 CA 在发布其 CRL 时通过 SSL/TLS 身份验证连接到在线证书状态管理器。否则，在线证书状态管理器不需要具有完整的证书链。

但是，在线证书状态管理器必须具有对 CRL 签名的证书（CA 签名证书或单独的 CRL 签名证书），在其证书数据库中。OCSP 服务将 CRL 的证书与数据库中的证书（而不是针对证书链）进行比较来验证 CRL。如果 root CA 和其下从属 CAs 将 CRL 发布到在线证书 Status Manager，在线证书 Status Manager 需要两个 CA 的 CA 签名证书。

要导入用于签署 CA 或 CRL 签名证书的 CA 或 CRL 签名证书，并将其发布到在线证书 Status Manager，请执行以下操作：

从 CA 的最终页面获取证书管理器的 base-64 CA 签名证书。
打开 Online Certificate Status Manager 代理页面。URL 的格式是 https://hostname:SSLport/ocsp/agent/ocsp。
在左侧框中，点 Add Certificate Authority。
在表单中，将编码的 CA 签名证书粘贴到标记为 Base 64 编码证书的文本区域中（包括标题和页脚）。
要验证证书是否已成功添加，请在左边框中点击 List Certificate Authorities。

生成的表单应该显示有关新 CA 的信息。此更新、下一次更新和 Requests Served Since Startup 字段应显示为零(0)的值。

7.6.2.1. 验证证书管理器和在线证书状态管理器连接

当证书管理器重启时，它会尝试连接到在线证书状态管理器的 SSL/TLS 端口。要验证证书管理器是否确实与在线证书 Status Manager 通信，请检查此更新和下一个更新字段，该字段应该根据 CA 最后一次通信与在线证书状态管理器进行更新。Requests Served Since Startup 字段应该仍然显示零(0)，因为没有客户端试图查询 OCSP 服务以获取证书撤销状态。

7.6.2.2. 配置 Revocation Info Stores: Internal Database

Online 证书状态管理器将每个证书管理器的 CRL 存储在其内部数据库中，并将其用作 CRL 存储来验证证书的撤销状态。要更改在线证书状态管理器用来将 CRL 存储在其内部数据库中的配置：

打开 Online Certificate Status Manager 控制台。
```
pkiconsole https://server.example.com:8443/ocsp
```
在 Configuration 选项卡中，选择 Online Certificate Status Manager，然后选择 Revocation Info Stores。
右侧窗格显示在线证书状态管理器可以使用的两个存储库；默认情况下，它使用其内部数据库的 CRL。
选择 defStore，再单击 Edit/View。
编辑 defStore 值。
- notFoundAsGood.如果问题中的任何 CRL 中找不到证书，则设置 OCSP 服务会返回 GOOD 的 OCSP 响应。如果没有选择此项，则响应是 UNKNOWN，当客户端遇到时，会出现错误消息。
- byName.OCSP Responder 仅支持基本响应类型，其中包括对 OCSP Responder 的 ID。基本响应类型中的 ResponderID 字段由 ocsp.store.defStore.byName 参数的值决定。如果 byName 参数为 true 或缺失，则 OCSP 授权签名证书主题名称将用作 OCSP 响应的 ResponderID 字段。如果 byName 参数为 false，则 OCSP 授权签名证书密钥哈希值将是 OCSP 响应的 ResponderID 字段。
- includeNextUpdate.包括下一次 CRL 更新时间的时间戳。

7.6.2.3. 配置 Revocation Info Stores: LDAP Directory

虽然 OCSP Manager 默认将 CA CRL 存储在其内部数据库中，但您可以将它配置为使用发布到 LDAP 目录的 CRL。

重要

如果启用了 ldapStore 方法，则 OCSP 用户界面不会检查证书状态。

将在线证书状态管理器配置为使用 LDAP 目录：

打开 Online Certificate Status Manager 控制台。
```
pkiconsole https://server.example.com:8443/ocsp
```
在 Configuration 选项卡中，选择 Online Certificate Status Manager，然后选择 Revocation Info Stores。
右侧窗格显示在线证书状态管理器可以使用的两个存储库；默认情况下，它使用其内部数据库的 CRL。
要在 LDAP 目录中使用 CRLs，请单击 Set Default 以启用 ldapStore 选项。
选择 ldapStore，再单击 Edit/View。
设置 ldapStore 参数。
- numConns.OCSP 服务应检查的 LDAP 目录总数。默认情况下，它被设置为 0。设置此值可显示对应的主机、端口、baseDN 和 refreshInSec 字段。
- 主机.LDAP 目录的完全限定 DNS 主机名。
- 端口。LDAP 目录的非 SSL/TLS 端口。
- baseDN.开始搜索 CRL 的 DN。例如： O=example.com。
- refreshInSec.刷新连接的频率。默认值为 86400 秒(daily)。
- caCertAttr.保留默认值 cACertificate;binary，因为它是.它是证书管理器发布其 CA 签名证书的属性。
- crlAttr.保留默认值 certificateRevocationList;binary，因为它是。它是证书管理器发布 CRL 的属性。
- notFoundAsGood.如果问题中的任何 CRL 中找不到证书，则设置 OCSP 服务会返回 GOOD 的 OCSP 响应。如果没有选择此项，则响应是 UNKNOWN，当客户端遇到时，会出现错误消息。
- byName.OCSP Responder 仅支持基本响应类型，其中包括对 OCSP Responder 的 ID。基本响应类型中的 ResponderID 字段由 ocsp.store.defStore.byName 参数的值决定。如果 byName 参数为 true 或缺失，则 OCSP 授权签名证书主题名称将用作 OCSP 响应的 ResponderID 字段。如果 byName 参数为 false，则 OCSP 授权签名证书密钥哈希值将是 OCSP 响应的 ResponderID 字段。
- includeNextUpdate.Online Certificate Status Manager 可以包括下一个 CRL 更新时间的时间戳。

7.6.2.4. 测试 OCSP 服务设置

通过执行以下操作测试证书管理器是否可以正确服务 OCSP 请求：

在浏览器或客户端中打开撤销检查。
从为 OCSP 服务启用的 CA 请求证书。
批准请求。
将证书下载到浏览器或客户端。
确保 CA 由浏览器或客户端信任。
检查证书管理器的内部 OCSP 服务的状态。
打开 CA 代理服务页面，然后选择 OCSP Services 链接。
测试独立在线证书状态管理器子系统。
打开 Online Certificate Status Manager agent services 页面，然后单击 List Certificate Authorities 链接。
该页面应显示有关证书管理器的信息，以将 CRL 发布到在线证书状态管理器。该页面还总结了自上次启动以来在线证书状态管理器的活动。
撤销证书。
在浏览器或客户端中验证证书。服务器应该返回证书已被撤销。
再次检查证书管理器的 OCSP-service 状态，以验证是否发生了这些问题：
- 浏览器将 OCSP 查询发送到证书管理器。
- 证书管理器向浏览器发送 OCSP 响应。
- 浏览器用于响应验证证书并返回其状态，该浏览器无法验证证书。
再次检查独立的 OCSP 服务子系统，以验证是否发生了这些问题：
- 证书管理器将 CRL 发布到在线证书状态管理器。
- 浏览器将 OCSP 响应发送到在线证书状态管理器。
- 在线证书状态管理器将 OCSP 响应发送到浏览器。
- 浏览器用于响应验证证书并返回其状态，该浏览器无法验证证书。

7.6.3. 为 Bad Serial Numbers 设置响应

OCSP 响应者在确定证书是否有效前检查证书的撤销状态和过期日期。默认情况下，OCSP 不会验证证书上的其他信息。

notFoundAsGood 参数设置 OCSP 如何使用无效序列号处理证书。这个参数会被默认启用。这意味着，如果证书存在错误的序列号，但证书无法有效，OCSP 会为证书返回 GOOD 状态。

要让 OCSP 检查并拒绝基于错误序列号和撤销状态的证书，请更改 notFoundAsGood 设置。在这种情况下，OCSP 使用带有错误序列号的证书返回 UNKNOWN 状态。客户端解析为错误并可以相应地做出响应。

打开 Online Certificate Status Manager 控制台。
```
pkiconsole https://server.example.com:8443/ocsp
```
在 Configuration 选项卡中，选择 Online Certificate Status Manager，然后选择 Revocation Info Stores。
选择 defStore，再单击 Edit/View。
编辑 notFoundAsGood 值。选择复选框意味着 OCSP 返回 GOOD 值，即使证书中的序列号不正确。取消选择复选框意味着 OCSP 发送 UNKNOWN 的值，因为客户端可能会将错误作为错误。

重启 OCSP Manager。

]# systemctl restart pki-tomcatd@instance-name.service

7.6.4. 启用证书管理器的内部 OCSP 服务

证书管理器中有一个内置 OCSP 服务，它可供 OCSP 兼容客户端用于查询证书管理器，以直接与证书的撤销状态进行查询。安装证书管理器后，会发出 OCSP 签名证书，默认启用 OCSP 服务。此 OCSP 签名证书用于签署对 OCSP 服务请求的所有响应。由于内部 OCSP 服务检查存储在证书管理器内部数据库中的证书状态，因此发布不必配置为使用此服务。

客户端可以通过证书管理器的非 SSL/TLS 端点端口查询 OCSP 服务。查询证书的撤销状态时，证书管理器将搜索其内部数据库以获取证书，检查其状态，并响应客户端。由于证书管理器具有其发布的所有证书的实时状态，因此这种撤销检查方法是最准确的。

每个 CA 内置 OCSP 服务在安装时打开。但是，为了使用此服务，CA 需要使用授权信息访问扩展发布证书。

进入 CA 的最终用户页面。例如：
```
https://server.example.com:8443/ca/ee/ca
```
查找 CA 签名证书。
在证书中查找 Authority Info Access 扩展，并记录 Location URIName 值，如 https://server.example.com:8443/ca/ocsp。
更新注册配置集，以启用授权信息访问扩展，并将 Location 参数设置为证书管理器的 URI。有关编辑证书配置集的详情请参考第 3.2 节 “设置证书配置集”。

重启 CA 实例。

]# systemctl restart pki-tomcatd@instance-name.service

注意

要禁用证书管理器的内部 OCSP 服务，请编辑 CA 的 CS.cfg 文件，并将 ca.ocsp 参数的值更改为 false。

ca.ocsp=false

7.6.5. 使用 OCSPClient 程序提交 OCSP 请求

OCSPClient 程序可用于执行 OCSP 请求。例如：

]# OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2
CertID.serialNumber=2
CertStatus=Good

OCSPClient 命令可用于以下命令行选项：

表 7.1. 可用的 OCSPClient 选项

选项	描述
-d database	安全数据库位置（默认：当前目录）
-h hostname	OCSP 服务器主机名（默认： example.com）
-p port	OCSP 服务器端口号（默认： 8080）
-t path	OCSP 服务路径（默认：/ocsp/ee/ocsp）
-c nickname	CA 证书别名(defaut: CA Signing Certificate)
-n times	提交数（默认：1）
--serial serial_number	要检查的证书的序列号
--input input_file	包含 DER 编码的 OCSP 请求的输入文件
--output output_file	保存 DER 编码的 OCSP 响应的输出文件
-v, --verbose	在详细模式下运行
--help	显示帮助信息

7.6.6. 使用 GET 方法提交 OCSP 请求

OCSP 请求可以使用 GET 方法提交到在线证书状态管理器，如 RFC 6960 所述。要通过 GET 提交 OCSP 请求：

为要查询的证书生成 OCSP 请求。例如：

]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64

MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=

粘贴 Web 浏览器的地址栏中的 URL，返回状态信息。浏览器必须能够处理 OCSP 请求。

https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=

OCSP Manager 使用浏览器可解释的证书状态进行响应。可能的状态是 GOOD、REVOKED 和 UNKNOWN。

或者，使用 curl 等工具从命令行运行 OCSP，以发送请求和 openssl 来解析响应。例如：

为要查询的证书生成 OCSP 请求。例如：

]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64

MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=

使用 curl 连接到 OCSP Manager，以发送 OCSP 请求。

curl https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE= > ocspresp.der

使用 openssl 解析响应：

openssl ocsp -respin ocspresp.der -resp_text

对于带有授权信息访问扩展的 7.1 CA 发布的证书，需要使用 GET 方法发送到 OCSP，需要创建一个重定向来将请求转发到适当的 URL，如第 7.6.7 节 “为证书证书系统主任设置重定向：System 7.1 和 Earlier” 所述。

7.6.7. 为证书证书系统主任设置重定向：System 7.1 和 Earlier

OCSP 用户页面的位置，在文件 root /ocsp/ ocsp/ocsp/ 的 URL 中指定，与证书证书系统nbsp;System 9 或 CertificateCertificate Systemnbsp;System 9 or CertificateCertificate Systemnbsp;System 8.1 的位置与证书证书系统nbsp;System 7.1，只是 .对于要发送到 OCSP 的授权信息访问扩展的 7.1 或更早的 CA 发布的证书，请创建一个重定向以将请求转发到适当的 URL。

注意

设定重定向只需要管理 7.1 或更早的 CA 使用授权信息访问扩展发布的证书。如果证书由后续证书管理器发布，或者不包含授权信息访问扩展，则不需要此配置。

停止 OCSP Responder。

]# systemctl stop pki-tomcatd@instance-name.service

进入 OCSP 的最终用户 web 应用程序目录。例如：
```
]# cd /var/lib/pki-ocsp/webapps/ocsp
```
更改到 OCSP Web 应用程序目录的 ROOT /WEB-INF/ 目录。例如：
```
]# cd /var/lib/pki-ocsp/webapps/ocsp/ROOT/WEB-INF/
```
在 OCSP 的 web 应用程序目录的 ROOT 文件夹中创建并打开 lib/ 目录。
```
]# mkdir lib
]# cd lib/
```
创建链接回 /usr/share/java/pki/cms.jar JAR 文件的符号链接。例如：
```
]# ln -s /usr/share/java/pki/cms.jar cms.jar
```
移到主 web 应用目录。例如：
```
]# cd /var/lib/pki-ocsp/webapps/ocsp/
```

重命名当前实例(ocsp)目录。例如：

]# mv /var/lib/pki-ocsp/webapps/ocsp/ocsp /var/lib/pki-ocsp/webapps/ocsp/ocsp2

更改到原始 ocsp/ 目录中的 WEB-INF/ 目录。例如：
```
]# cd  /var/lib/pki-ocsp/webapps/ocsp/ocsp/WEB-INF
```

在原始的 ocsp/WEB-INF/ 目录中，编辑 web.xml 文件并在 eeocspAddCRL 和 csadmin-wizard servlets 之间添加行映射。

   <servlet-mapping>
      <servlet-name>  ocspOCSP  </servlet-name>
      <url-pattern>   /ee/ocsp/*  </url-pattern>
   </servlet-mapping>

在 ROOT 目录中创建并安装 web.xml 文件。例如：

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app>

  <display-name>Welcome to Tomcat</display-name>
  <description>
     Welcome to Tomcat
  </description>

  <servlet>
    <servlet-name>ocspProxy</servlet-name>
    <servlet-class>com.netscape.cms.servlet.base.ProxyServlet</servlet-class>
    <init-param>
      <param-name>destContext</param-name>
      <param-value>/ocsp2</param-value>
    </init-param>
    <init-param>
      <param-name>destServlet</param-name>
      <param-value>/ee/ocsp</param-value>
    </init-param>
  </servlet>

  <servlet>
    <servlet-name>ocspOther</servlet-name>
    <servlet-class>com.netscape.cms.servlet.base.ProxyServlet</servlet-class>
    <init-param>
      <param-name>destContext</param-name>
      <param-value>/ocsp2</param-value>
    </init-param>
    <init-param>
      <param-name>srcContext</param-name>
      <param-value>/ocsp</param-value>
    </init-param>
    <init-param>
      <param-name>destServlet</param-name>
      <param-value></param-value>
    </init-param>
    <init-param>
      <param-name>matchURIStrings</param-name>

<param-value>/ocsp/registry,/ocsp/acl,/ocsp/jobsScheduler,/ocsp/ug,/ocsp/server,/ocsp/log,
            /ocsp/auths,/ocsp/start,/ocsp/ocsp,/ocsp/services,/ocsp/agent,/ocsp/ee,
            /ocsp/admin</param-value>
    </init-param>
    <init-param>
      <param-name>destServletOnNoMatch</param-name>
      <param-value>/ee/ocsp</param-value>
    </init-param>
    <init-param>
      <param-name>appendPathInfoOnNoMatch</param-name>
      <param-value>/ocsp</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
    <servlet-name>ocspProxy</servlet-name>
    <url-pattern>/ocsp</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>ocspOther</servlet-name>
    <url-pattern>/ocsp/*</url-pattern>
  </servlet-mapping>

</web-app>

编辑 /var/lib/pki-ocsp/conf/context.xml 文件，更改以下行：
```
<Context>
 to 
<Context crossContext="true" >
```
编辑 /var/lib/pki-ocsp/webapps/ocsp2/services.template 文件并更改以下行：
```
result.recordSet[i].uri);
 to 
result.recordSet[i].uri + "/");
```

启动 OCSP 实例。

]# systemctl restart pki-tomcatd@instance-name.service

部分 III. 管理 CA 服务的其他配置

第 8 章发布证书和 CRL

Red Hat Certificate Systemnbsp;Hat Certificate Red Hat Certificate Systemnbsp;System 为证书管理器包含一个自定义的发布框架，使证书颁发机构能够发布证书、证书撤销列表(CRL)以及任何受支持存储库的其他证书相关的对象：LDAP 兼容目录、平面文件以及在线验证机构。本章论述了如何配置证书管理器，以将证书和 CRL 发布到文件，以及在线证书状态管理器。

配置发布的一般过程如下：

配置发布到文件、LDAP 目录或 OCSP 响应程序。
根据所使用的位置数量，可以使用单个发布程序或多个发布者。可以通过证书和 CRL 分割位置，或者分配范围定义，如证书类型。规则通过与发布者关联，确定要发布哪些类型，并告知什么位置。
设置规则以确定将哪些证书发布到位置。激活证书或 CRL 匹配的任何规则，因此同一证书可以通过与基于文件的规则匹配并匹配基于目录的规则，将相同的证书发布到文件以及 LDAP 目录中。
可以为每个对象类型设置规则： CA 证书、CRL、用户证书和跨对证书。禁用不使用的所有规则。
配置 CRL。必须配置 CRL，然后才能发布。请参阅第 7 章 撤销证书和发布 CRL。
在设置发布程序、映射程序和规则后发布。启用发布后，服务器开始立即发布。如果没有完全配置发布程序、映射程序和规则，发布可能无法正常工作。

8.1. 关于发布

CertificateCertificate Systemnbsp;System 能够将证书发布到文件或 LDAP 目录，以及将 CRL 发布到文件、LDAP 目录或 OCSP 响应程序。

为了获得额外的灵活性，可以将特定类型的证书或 CRL 发布到单一格式或全部三个格式。例如，CA 证书只能发布到某个目录而不是文件，用户证书可以被发布到一个文件和目录。

注意

OCSP 响应者仅提供有关 CRL 的信息；证书不会发布到 OCSP 响应者。

可以为证书文件和 CRL 文件设置不同的发布位置，以及不同类型的证书文件或不同类型的 CRL 文件的不同发布位置。

同样，可以将不同类型的证书和不同类型的 CRL 发布到目录中的不同位置。例如，公司 West Coast 部门的用户的证书可以在目录的一个分支中发布，而 East Coast division 中的用户的证书可以发布到目录中的另一个分支。

启用发布后，每次发布证书或 CRL 时，会调用发布系统。证书或 CRL 由规则评估，以查看它是否与规则中设置的类型和 predicate 匹配。类型指定对象是 CRL、CA 证书或任何其他证书。predicate 为被评估的对象类型设置更多条件。例如，它可以指定用户证书，或者指定 West Coast 用户证书。要使用 predicates，需要在发布规则的 predicate 项中输入值，并且对应的值（尽管格式有不同）需要包含在证书或证书请求中以匹配。证书或证书请求中的值可能源自证书中的信息，如证书类型，或者派生自以请求形式放置的隐藏值。如果没有设置 predicate，则该类型的所有证书都将被视为匹配。例如，如果 CRL 设置为类型，则所有 CRL 都匹配规则。

每个匹配的规则都会根据规则中指定的方法和位置发布证书或 CRL。给定证书或 CRL 可以不匹配任何规则、一条规则、多个规则或所有规则。发布系统尝试与针对所有规则发布的每个证书和 CRL 相匹配。

匹配规则时，会根据与该规则关联的发布程序中指定的方法和位置发布证书或 CRL。例如，如果某个规则与向用户发布的所有证书匹配，且该规则有一个发布者，它将发布到位置 /etc/CS/certificates 中的文件，该证书将作为文件发布到该位置。如果另一个规则与用户发布的所有证书匹配，并且该规则有一个发布者，它发布到 LDAP 属性 userCertificate;binary 属性，则会在用户条目的此属性中启用 LDAP 发布时指定的目录。

对于指定要发布到文件的规则，会在被取用的目录中发布证书或 CRL 时创建新文件。

对于指定要发布到 LDAP 目录的规则，证书或 CRL 则在指定的属性中发布到目录中指定的条目。CA 使用任何后续证书或 CRL 来覆盖已发布的证书或 CRL 属性的值。只需放置即可，已经发布的任何现有证书或 CRL 都由下一个证书或 CRL 替代。

对于指定要发布到在线证书状态管理器的规则，此管理器将发布 CRL。证书不会发布到在线证书状态管理器。

对于 LDAP 发布，需要确定用户条目的位置。映射程序用于确定要发布的条目。mappers 可以包含该条目的精确 DN，一些变量关联了可以从证书获取的信息，以创建 DN 或足够信息，用于搜索条目中唯一属性或设置条目的正确 DN。

撤销证书时，服务器使用发布规则从 LDAP 目录或从文件系统中删除对应的证书。

当证书过期时，服务器可以从配置的目录中删除该证书。服务器不会自动执行此操作；服务器必须配置为运行适当的作业。详情请查看第 12 章 设置自动化任务。

设置发布涉及配置发布程序、映射程序和规则。

8.1.1. publishers

publishers 指定发布证书和 CRL 的位置。当发布到文件时，发布者指定了文件系统发布目录。当发布到 LDAP 目录时，发布程序会指定存储证书或 CRL 的目录中的属性；mapper 用于确定条目的 DN。对于每个 DN，为推断该 DN 设置一个不同的公式。启用 LDAP 发布时指定 LDAP 目录的位置。将 CRL 发布到 OCSP 响应程序时，发布者指定在线证书 Status Manager 的主机名和 URI。

8.1.2. 映射程序

映射程序 仅在 LDAP 发布中使用。映射程序根据证书或证书请求的信息构建条目的 DN。服务器具有证书的主题名称的信息和证书请求，并需要了解如何使用此信息为该条目创建 DN。映射器提供了一个公式，用于将信息转换为 DN 或某些可在目录中搜索的唯一信息，以获取该条目的 DN。

8.1.3. 规则

文件、LDAP 和 OCSP 发布的规则会告知服务器是否以及如何发布证书或 CRL。通过为规则设置 type 和 predicate，规则首先定义要发布的内容、与特定特征匹配的证书或 CRL。然后，通过与发布者和 LDAP 发布程序（通过映射程序程序）关联来指定发布方法和位置。

规则可以像 PKI 部署所需一样简单或复杂，并且足够灵活，以适应不同的场景。

8.1.4. 发布到文件

服务器可以将证书和 CRL 发布到平面文件，然后将其导入到任何存储库，如关系数据库。当服务器被配置为将证书和 CRL 发布到文件时，公布的文件为 DER 编码的二进制 blob、base-64 编码的文本 blob 或两者。

对于每个服务器问题，它会以 DER-encoded 或 base-64 编码的格式创建一个包含证书的文件。每个文件都命名为 cert-serial_number.der 或 cert-serial_number.b64。serial_number 是文件中包含的证书的序列号。例如，使用序列号 1234 的 DER 编码证书的文件名是 cert-1234.der。
每次服务器生成 CRL 时，它会以 DER-encoded 或 base-64 编码的格式创建一个包含新 CRL 的文件。每个文件都命名为 issuing_point_name- this_update.der 或 issuing_point_name- this_update.b64，具体取决于格式。issued_point_name 标识发布 CRL 的 CRL 发出点，this_update 指定从文件中包含的 CRL 独立更新值派生的值。例如，DER 编码 CRL 的文件名以及值 This update: Friday 1:36:00 PST 2020，是 MasterCRL-20200128-153600.der。

8.1.5. OCSP 发布

有两种形式的 CertificateCertificate Systemnbsp;System OCSP 服务，它是证书管理器和在线证书状态管理器的内部服务。内部服务检查证书管理器的内部数据库，以报告证书的状态。内部服务未设置为发布；它使用存储在其内部数据库中的证书来确定证书的状态。Online Certificate Status Manager 检查由证书管理器发送到的 CRL。为每个发送 CRL 的每个位置设置一个发布程序，并为每个发送的 CRL 的规则设置一个规则。

有关两个 OCSP 服务的详情，请参考第 7.6 节 “使用在线证书状态协议(OCSP)响应”。

8.1.6. LDAP 发布

在 LDAP 中，服务器会使用 LDAP 或 LDAPS 将证书、CRL 和其他与证书相关的对象发布到目录中。它发布的目录的分支称为 发布目录。

对于每个证书，它会在用户条目的指定属性中创建一个带有证书的 DER 编码格式的 Blob。证书以 DER 编码的二进制 blob 的形式发布。
每次服务器生成 CRL 时，它都会创建一个 blob，它将以 CA 条目的指定属性的 DER 编码格式包含新的 CRL。

服务器可以使用 LDAP 协议或 LDAP 通过 SSL(LDAPS)协议将证书和 CRL 发布到 LDAP 兼容目录，应用可以通过 HTTP 检索证书和 CRL。支持通过 HTTP 检索证书和 CRL，一些浏览器可以从服务器接收定期更新的目录自动导入最新的 CRL。然后，浏览器可以使用 CRL 自动检查所有证书，以确保它们没有被撤销。

要使 LDAP 发布正常工作，用户条目必须位于 LDAP 目录中。

如果服务器和发布目录因某种原因而未同步，则特权用户（管理员和代理）也可以手动启动发布过程。具体说明请查看第 8.12.2 节 “手动更新目录中的 CRL”。

8.2. 配置发布到文件

配置发布的一般过程涉及设置发布发布程序，以将证书或 CRL 发布到特定位置。根据所使用的位置数量，可以使用单个发布程序或多个发布者。可以通过证书和 CRL 或精细定义（如证书类型）来分割位置。规则通过与发布者关联，确定要发布哪些类型，并告知什么位置。

发布到文件只是将 CRL 或证书发布到给定主机上的文本文件。

必须为每个发布位置创建和配置发布程序；不会自动生成发布发布程序以发布到文件。要将所有文件发布至单一位置，请创建一个发布程序。要发布到不同的位置，请为每个位置创建一个发布程序。位置可以包含对象类型，如用户证书，或者对象类型子集，如 West Coast 用户证书。

创建发布至文件的发布程序：

登录到证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择发布，然后选择发布软件软件。
publishers Management 选项卡（列出配置的发布程序实例）会在右侧打开。
点 Add 打开 Select publisher Plug-in Implementation 窗口，它列出了注册的发布程序模块。
选择 FileBasedPublisher 模块，然后打开编辑器窗口。
这是让证书管理器将证书和 CRL 发布到文件的模块。
配置发布证书的信息：
- publisher ID，它是一个字母数字字符串，没有空格，如 PublishCertsToFile
- 证书管理器应发布文件的目录的路径。该路径可以是绝对路径，也可以是相对于 CertificateCertificate Systemnbsp;System 实例目录。例如： /export/CS/certificates。
- 要发布的文件类型，选中 DER 编码文件的复选框、base-64 编码文件或两者。
- 对于 CRL，时间戳的格式。公布的证书在文件名中包括序列号，而 CRL 使用时间戳。
- 对于 CRL，是否在文件中生成链接以进入最新的 CRL。如果启用，则该链接假定要与扩展一起使用的 CRL 发出的名称将在 crlLinkExt 字段中提供。
- 对于 CRL，是否压缩(zip)CRL 以及要使用的压缩级别。

配置发布程序后，为已发布的证书和 CRL 配置规则，如第 8.5 节 “创建规则” 所述。

8.3. 配置发布到 OCSP

发布到 OCSP Manager 是一种将 CRL 发布到特定位置以进行客户端验证的方法。

必须为每个发布位置创建和配置发布程序；不会自动创建发布发布程序以发布到 OCSP 响应者。创建一个发布程序，将所有内容发布到单个位置，或为发布 CRL 的每个位置创建一个发布发布发布发布发布器。每个位置都可以包含不同类型的 CRL。

8.3.1. 启用通过客户端身份验证发布到 OCSP

登录到证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择发布，然后选择发布软件软件。
点 Add 打开 Select publisher Plug-in Implementation 窗口，它列出了注册的发布程序模块。
选择 OCSPPublisher 模块，然后打开编辑器窗口。这是让证书管理器将 CRL 发布到在线证书状态管理器的 publisher 模块。
- publisher ID 必须是字母数字字符串，没有空格，如 PublishCertsToOCSP。
- 主机可以是完全限定的域名，如 ocspResponder.example.com，也可以是 IPv4 或 IPv6 地址。
- 默认路径是要将 CRL 发送到的目录，如 /ocsp/agent/ocsp/addCRL。
- 如果使用了客户端身份验证（选中了enableClientAuth ），则 nickname 字段则提供要用于身份验证的证书的 nickname。此证书必须已存在于 OCSP 安全数据库中，这通常是 CA 子系统证书。
在 OCSP Manager 上为 CA 创建用户条目。在发送新 CRL 时，用户用于对 OCSP 进行身份验证。需要两个操作：
- 在 CA 服务器后面命名 OCSP 用户条目，如 CA-hostname-EEport。
- 使用 publisher 配置中指定的任何证书作为 OCSP 用户帐户中的用户证书。这通常是 CA 的子系统证书。
设置子系统用户包括在第 14.3.2.1 节 “创建用户” 中。

配置发布程序后，为已发布的证书和 CRL 配置规则，如第 8.5 节 “创建规则” 所述。

8.4. 配置发布到 LDAP 目录

配置 LDAP 发布过程与其他发布流程类似，但有额外的步骤来配置目录：

配置将发布到证书的目录服务器。某些属性必须添加到条目中，并且必须配置绑定身份和身份验证方法。
为发布的每种对象类型配置发布程序： CA 证书、跨对证书、CRL 和用户证书。publisher 会声明将对象存储在哪一属性中。默认设置的属性是用于存储每个对象类型的 X.500 标准属性。此属性可以在发布器中更改，但通常不需要更改 LDAP 发布程序。
设置映射程序，使条目的 DN 从证书的主题名称派生出来。这通常不需要为 CA 证书、CRL 和用户证书设置。可为一种证书设置多个映射程序。例如，这可以发布来自位于目录树不同部分公司的两组用户的证书。为每个组创建一个映射程序来指定不同的树分支。
有关设置映射程序的详情，请参考第 8.4.3 节 “创建映射程序”。
创建将发布程序连接到映射程序的规则，如第 8.5 节 “创建规则” 所述。
启用发布，如第 8.6 节 “启用发布” 所述。

8.4.1. 配置 LDAP 目录

在发布证书和 CRL 之前，必须将 Directory 服务器配置为与发布系统一起使用。这意味着，用户条目必须具有允许它们接收证书信息的属性，而且必须创建条目来代表 CRL。

为 CA 设置条目。要让证书管理器发布其 CA 证书和密钥 CRL，该目录必须包含 CA 的条目。
提示
配置 LDAP 发布后，证书管理器会在目录中自动创建或转换 CA 的条目。这个选项同时在 CA 和 CRL 映射程序实例中被设置，并默认启用。如果目录限制证书管理器在目录中创建条目，请在这些映射程序实例中关闭此选项，并在目录中手动添加 CA 的条目。
将 CA 的条目添加到目录时，根据 CA 的 DN 选择条目类型：
- 如果 CA 的 DN 以 cn 组件开头，请为 CA 创建一个新的人条目。选择其他类型的条目可能不允许指定 cn 组件。
- 如果 CA 的 DN 从组件开始，请为 CA 创建新的 organizationalunit 条目。
该条目不必处于 pkiCA 或 certificationAuthority 对象类中。证书管理器通过发布其 CA 的签名证书，自动将此条目转换为 pkiCA 或 certificationAuthority 对象类。
注意
pkiCA 对象类在 RFC 4523 中定义，而 Certified Authority 对象类在(obsolete)RFC 2256 中定义。根据 Directory 服务器使用的 schema 定义，可以接受任一对象类。在某些情况下，两个对象类都可用于同一 CA 条目。
有关创建目录条目的更多信息，请参阅 Red Hat Directory Server 文档。

在 CA 和用户目录条目中添加正确的模式元素。

要让证书管理器将证书和 CRL 发布到某个目录，必须配置有特定属性和对象类。

对象类型	模式	原因
最终用户证书	userCertificate;binary (attribute)	这是证书管理器发布证书的属性。这是一个多值属性，每个值都是 DER 编码的二进制 X.509 证书。名为 inetOrgPerson 的 LDAP 对象类允许此属性。strongAuthenticationUser 对象类允许此属性，并可与其他对象类结合使用，以允许将证书与其他对象类一起发布到目录条目。证书管理器不会自动将此对象类添加到相应 Directory 服务器的 schema 表中。如果它找到的目录对象不允许 userCertificate;binary 属性，添加或删除证书会失败。
CA 证书	caCertificate;binary (attribute)	这是证书管理器发布证书的属性。服务器启动时，证书管理器将自己的 CA 证书发布到自己的 LDAP 目录条目。该条目对应于证书管理器的签发者名称。这是 pkiCA 或 certificationAuthority 对象类的必要属性。如果证书管理器可以找到 CA 的目录条目，则证书管理器将此对象类添加到 CA 的目录条目中。
CRL	certificateRevocationList;binary (attribute)	这是证书管理器发布 CRL 的属性。证书管理器将 CRL 发布到自己的 LDAP 目录条目。该条目对应于证书管理器的签发者名称。这是 pkiCA 或 certificationAuthority 对象类的属性。属性的值是 DER 编码的二进制 X.509 CRL。CA 的条目必须已经包含 pkiCA 或 certificationAuthority 对象类，才能将 CRL 发布到该条目。
Delta CRL	deltaRevocationList;binary (attribute)	这是证书管理器发布 delta CRL 的属性。证书管理器将 delta CRL 发布到自己的 LDAP 目录条目，独立于完整的 CRL。delta CRL 条目对应于证书管理器的签发者名称。此属性属于 deltaCRL 或 Certification Authority-V2 对象类。属性的值是 DER 编码的二进制 X.509 delta CRL。

为证书管理器设置绑定 DN，以用于访问目录服务器。
证书管理器用户必须对目录具有读写权限，才能将证书和 CRL 发布到该目录，以便证书管理器可以修改与证书相关的信息的用户条目，以及 CA 的证书和 CRL 相关信息的 CA 条目。
绑定 DN 条目可以是以下任意一种：
- 具有写入权限的现有 DN，如 Directory Manager。
- 被授予写入访问权限的新用户。条目可以通过证书管理器的 DN 识别，如 cn=testCA、ou=Research Dept、o=Example Corporation、st=California, c=US。
  注意
  请仔细考虑为此用户授予什么权限。通过为帐户创建 ACL，可以限制该用户在目录中写入的内容。有关授予证书管理器条目的写入权限的说明，请参阅目录服务器文档。
设置目录验证方法，以便证书管理器如何向 Directory 服务器进行身份验证。有三个选项：基本身份验证（简单用户名和密码）；没有客户端身份验证的 SSL（简单用户名和密码）；以及通过客户端身份验证（基于证书）的 SSL。
有关设置这些与服务器通信的说明，请查看 Red Hat Directory Server 文档。

8.4.2. 配置 LDAP 发布程序

证书管理器创建、配置并启用与 LDAP 发布相关的一组发布程序。默认发布程序（用于 CA 证书、用户证书、CRL 和跨对证书）已遵循 X.500 标准属性来存储证书和 CRL，不需要更改。

表 8.1. LDAP 发布程序

publisher	描述
LdapCaCertPublisher	将 CA 证书发布到 LDAP 目录。
LdapCrlPublisher	将 CRL 发布到 LDAP 目录。
LdapDeltaCrlPublisher	将 delta CRL 发布到 LDAP 目录。
LdapUserCertPublisher	将所有类型的终止证书发布到 LDAP 目录。
LdapCrossCertPairPublisher	将跨签名证书发布到 LDAP 目录。

8.4.3. 创建映射程序

映射程序只与 LDAP 发布一起使用。映射程序定义了证书主题名称和发布证书的目录条目的 DN 之间的关系。证书管理器需要从证书或证书请求中获取条目的 DN，以便它能够决定使用哪个条目。映射映射定义了用户条目的 DN 之间的关系以及证书或其他输入信息的主体名称，以便可以确定条目的确切 DN 并位于目录中。

配置后，证书管理器会自动创建一组定义最常见的关系的映射程序。默认映射程序在表 8.2 “默认映射程序” 中列出。

表 8.2. 默认映射程序

mapper	描述
LdapUserCertMap	在目录中找到用户条目的正确属性，以发布用户证书。
LdapCrlMap	在目录中找到 CA 条目的正确属性，以发布 CRL。
LdapCaCertMap	在目录中找到 CA 条目的正确属性，以发布 CA 证书。

要使用默认映射程序，通过指定 DN 模式以及是否在目录中创建 CA 条目来配置每个宏。要使用其他映射程序，请创建和配置映射程序的实例。更多信息请参阅第 C.2 节 “映射器插件模块 ”。

登录到证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择发布，然后选择映射程序。
映射程序管理标签页（列出配置的映射程序）会在右侧打开。
要创建新映射程序实例，请单击 Add。将打开 Select Mapper Plugin Implementation 窗口，它列出了已注册映射程序模块。选择一个模块并进行编辑。有关这些模块的完整信息，请参阅第 C.2 节 “映射器插件模块 ”。
编辑映射程序实例，然后单击确定。
有关每个映射器的详细信息，请参阅第 C.2 节 “映射器插件模块 ”。

8.4.4. 完成配置：规则并启用

为 LDAP 发布配置映射程序后，为公布的证书和 CRL 配置规则，如第 8.5 节 “创建规则” 所述。

配置完成后，启用发布，如第 8.6 节 “启用发布” 所述。

8.5. 创建规则

规则决定了在什么位置发布哪些证书对象。规则可以独立工作，而不是以 tandem 工作。正在发布的证书或 CRL 与任何规则都匹配。任何与之匹配的规则都会被激活。这样，可以将相同的证书或 CRL 发布到文件、在线证书状态管理器以及通过匹配基于文件的规则、OCSP 规则并匹配基于目录的规则来发布到 LDAP 目录。

可以为每个对象类型设置规则： CA 证书、CRL、用户证书和跨对证书。这些规则对不同类型的证书或不同种类的 CRL 更为详细。

规则首先确定对象是否与规则中设置的类型和 predicate 匹配。发布匹配对象的位置由与该规则关联的发布程序和映射程序决定。

针对证书管理器问题，创建每种类型的规则。

通过执行以下操作修改发布规则：

登录到证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择发布，然后选择 Rules。
Rules Management 标签页（列出配置的规则）在右侧打开。
要编辑现有规则，请从列表中选择该规则，然后点 Edit。这将打开 Rule Editor 窗口。
要创建规则，请单击 Add。这将打开 Select Rule Plug-in Implementation 窗口。
选择 Rule 模块。这是唯一默认模块。如果已经注册了任何自定义模块，它们也会可用。
编辑规则。
- 键入。这是规则适用的证书类型。对于 CA 签名证书，值为 cacert。对于跨签名证书，值为 xcert。对于所有其他证书类型，值为 certs。对于 CRLs，指定 crl。
- predicate.这为规则应用到的证书或 CRL 发出类型设置 predicate 值。CRL 发出点、delta CRL 和证书的 predicate 值列在表 8.3 “predicate 表达式” 中。
- 启用。
- 映射器.发布到文件时不需要映射程序，只有 LDAP 发布版需要它们。如果此规则与发布到 LDAP 目录的发布者关联，请在这里选择一个适当的映射程序。所有其他形式的发布留空。
- 发布程序.将发布程序设置为与该规则关联。

表 8.3 “predicate 表达式” 列出可用于识别 CRL 发出点和 delta CRLs 和证书配置集的 predicates。

表 8.3. predicate 表达式

predicate 类型	predicate
CRL 签发点	issuingPointId==Issuing_Point_Instance_ID && isDeltaCRL==[true\|false] 要只发布 master CRL，设置为DeltaCRL==false。要只发布 delta CRL，请设置 DeltaCRL==true。要发布这两个情况，请为 master CRL 以及 delta CRL 中的一个规则设置一个规则。
证书配置集	profileId==profile_name 要根据用来发布它们的配置集发布证书，请将 profileId== 设置为配置集名称，如 caServerCert。

8.6. 启用发布

只能针对文件（仅限 LDAP 或两者）启用发布。在设置发布者、规则和映射程序后，应启用发布程序。启用后，服务器会尝试开始发布。如果在启用前，如果发布没有被正确配置，发布可能会带来不所需行为，否则可能会失败。

注意

配置 CRL。必须配置 CRL，然后才能发布。请参阅第 7 章 撤销证书和发布 CRL。

登录到证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择发布。
右窗格显示了发布到与 LDAP 兼容的目录的详细信息。
要仅启用发布到文件，请选择 Enable Publishing。
要启用 LDAP 发布，请选择 Enable Publishing and Enable Default LDAP Connection。
在 Destination 部分中，设置 Directory Server 实例的信息。
- 主机名.如果为 SSL 客户端通过身份验证的通信配置了 Directory 服务器，该名称必须与目录服务器的 SSL 服务器证书主体 DN 中的 cn 组件匹配。
  主机名可以是完全限定域名或 IPv4 或 IPv6 地址。
- 端口号.
- 目录管理器 DN.这是具有 Directory Manager 特权的目录条目的可分辨名称(DN)。证书管理器使用此 DN 访问目录树，并发布到目录。为此 DN 设置的访问控制决定了证书管理器是否可以执行发布。可以创建另一个具有有限读写权限的 DN，只针对发布系统实际需要写入的属性。
- 密码。这是 CA 用来绑定到发布证书或 CRL 的 LDAP 目录的密码。证书管理器将此密码保存在其 password.conf 文件中。例如：
```
CA LDAP Publishing:password
```
  注意
  标识发布密码(CA LDAP Publishing)的参数名称在 ca.publish.ldappublish.ldap.ldapauth.bindPWPrompt 参数中的 Certificate Manager 的 CS.cfg 文件中设置，并可编辑。
- 客户端证书。这将设置证书管理器用于在发布目录中进行 SSL 客户端身份验证的证书。默认情况下，证书管理器使用其 SSL 服务器证书。
- LDAP 版本.选择 LDAP 版本 3.
- 身份验证.证书管理器向 Directory 服务器进行身份验证的方式。选择是 基本身份验证 和 SSL 客户端身份验证。
  如果目录服务器是为基本身份验证或没有客户端身份验证的 SSL 通信而配置的，请选择 基本身份验证，并指定 Directory 管理器 DN 和密码的值。
  如果目录服务器被配置为与客户端身份验证进行 SSL 通信，请选择 SSL 客户端身份验证 和使用 SSL 通信 选项，并识别证书管理器必须用于 SSL 客户端身份验证的证书，以便对该目录进行 SSL 客户端身份验证。

服务器尝试连接到 Directory 服务器。如果信息不正确，服务器会显示错误消息。

8.7. 启用发布队列

注册过程的一部分，包括向任何目录或文件发布发布证书。这基本上会关闭初始证书请求。但是，将证书发布到外部网络可能会显著降低了运行过程，这样会使请求处于打开状态。

为避免这种情况，管理员可以启用 发布队列。发布队列将发布操作（可能涉及外部 LDAP 目录）与请求和注册操作（使用单独的请求队列）分开。请求队列会立即更新，以显示注册过程已完成，而发布队列则以网络流量的速度发送信息。

发布队列设置已定义、有限的线程数发布生成的证书，而不是为每个批准的证书打开一个新线程。

发布队列默认是禁用的。它可以在 CA 控制台中启用，同时启用发布。

注意

虽然发布队列默认为禁用，但 在控制台中 启用 LDAP 发布时，队列会自动启用。否则，可以手动启用队列。

图 8.1. 启用发布队列

提示

通过编辑 CS.cfg 文件启用发布队列可让管理员设置发布的选项，如用于发布操作的线程数量和队列页面大小。

有关如何通过编辑 CS.cfg 文件配置此功能的说明，请参阅 红帽证书系统规划、安装和部署指南中的 启用 Publishing Queue 部分。

8.8. 设置恢复 CRL 下载

CertificateCertificate Systemnbsp;System 提供一些不中断的 CRL 下载方案。这可以通过通过 HTTP 发布 CRL 作为普通文件来完成。这种下载 CRL 的方法提供了检索 CRL 和降低整体网络拥塞的灵活性。

8.8.1. 使用 wget 检索 CRL

由于 CRL 可通过 HTTP 作为文本文件发布，因此可以使用 wget 等工具从 CA 手动检索。wget 命令可用于检索任何已发布的 CRL。例如，要检索一个比前面的完整 CRL 的最新 CRL：

[root@server ~]# wget --no-check-certificate -d https://server.example.com:8443/ca/ee/ca/crl/MasterCRL.bin

表 8.4 “wget 选项用于检索 CRL” 中总结了 wget 的相关参数。

表 8.4. wget 选项用于检索 CRL

参数	描述
no 参数	检索完整的 CRL。
-N	检索比本地副本(delta CRL)更新的 CRL。
-c	检索部分下载的文件。
--no-check-certificate	跳过连接的 SSL，因此不需要在主机和客户端之间配置 SSL。
-d	打印调试信息。

8.9. 发布跨Pair 证书

跨对证书可以作为 跨CertificatePair 条目发布到 LDAP 目录或文件，这默认是启用的。如果禁用了它，可以通过证书管理器控制台重新启用它：

打开 CA 控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，选择左侧窗格中的证书管理器链接，然后选择 Publishing 链接。
单击发布下的 Rules 链接。这会打开右侧的 Rules Management 窗格。
如果规则存在并且已禁用，请选择启用复选框。如果规则已被删除，请单击 Add 并创建一个新规则。
1. 从类型下拉菜单中选择 xcerts。
2. 确保选中了启用复选框。
3. 从 mapper 下拉菜单中选择 LdapCaCertMap。
4. 从发布程序下拉菜单中选择 LdapCrossCertPairPublisher。

发布规则中指定的映射程序和发布程序均列在 CA 控制台左侧导航窗口的 Publishing 下方。默认情况下，映射程序 LdapCaCertMap 指定将 crossCertificatePair 存储到 LdapCaSimpleMap LDAP 条目。默认情况下，发布程序( LDAPCrossPairPublisher )设置属性，以在 CA 条目中将跨密钥对证书存储在 CA 条目中，以 跨CertificatePair;binary。

有关使用跨对证书的更多信息，请参阅第 16.5 节 “使用跨Pair 证书”。

有关创建跨对证书配置集的更多信息，请参阅 红帽认证系统 9 规划、安装和部署指南中的 配置跨Pair 配置集 部分。

8.10. 测试发布到文件

验证证书管理器是否在正确发布证书和 CRL 以进行文件：

打开 CA 的最终用户页面，再请求证书。
如果需要，请通过代理服务页面批准请求。
从终端页面检索证书，并将证书下载到浏览器中。
检查服务器是否生成了包含证书的 DER 编码文件。
打开应发布证书的二进制 blob 的目录。证书文件应命名为 cert-serial_number.der。
使用 Binary Binary 将 DER 编码的证书转换为其基本 64 编码的格式。有关此工具的更多信息，请参阅 BtoA(1) man page。
```
BtoA input_file output_file
```
input_file 设置包含 DER 编码证书的文件的路径，而 output_file 设置文件的路径，以写入 base-64 编码证书。

打开 ASCII 文件; base-64 编码证书与所示的证书类似：

使用 Pretty Print Certificate 工具将基本 64 编码的证书转换为可读的表单。有关此工具的更多信息，请参阅 PrettyPrintCert(1) man page。
```
PrettyPrintCert input_file [output_file]
```
input_file 设置 ASCII 文件的路径，其中包含 base-64 编码证书，以及 output_file （可选）设置要写入证书的路径。如果没有设置输出文件，证书信息将写入到标准输出中。
将输出与发布的证书进行比较；检查证书中的序列号和文件名中使用的序列号。
如果一切匹配，证书管理器将正确配置为将文件发布证书。
撤销证书。
检查服务器是否生成了包含 CRL 的 DER 编码文件。
打开服务器将 CRL 发布为二进制 blob 的目录。CRL 文件应当具有格式为 crl-this_update.der 的名称。this_update 指定从 CRL 依赖时间的 This Update 变量获取的值。
使用 Binary Binary 将 DER 编码的 CRL 转换为其基本 64 编码的格式。
```
BtoA input_file output_file
```
使用 Pretty Print CRL 工具，将 base 64 编码的 CRL 转换为可读格式。
```
PrettyPrintCrl input_file [output_file]
```
比较输出。

8.11. 查看证书和 CRLs 发布到文件

证书和 CRL 可以发布到两类文件：base-64 编码或 DER-encoded。可以使用 dumpasn1 工具或 PrettyPrintCert 或 PrettyPrintCrl 工具，查看这些文件的内容。

查看 base-64 编码文件中的内容：

将 base-64 文件转换为二进制文件。例如：
```
AtoB /tmp/example.b64 /tmp/example.bin
```
使用 PrettyPrintCert 或 PrettyPrintCrl 工具将二进制文件转换为 prettyprint 格式。例如：
```
PrettyPrintCert example.bin example.cert
```

要查看 DER 编码文件的内容，只需运行 dumpasn1、 PrettyPrintCert 或 PrettyPrintCrl 工具（使用 DER 编码文件）。例如：

PrettyPrintCrl example.der example.crl

8.12. 更新目录中的证书和 CRL

如果在 Directory 服务器停机期间签发或撤销证书，则证书管理器和发布目录可能会不同步。发布或撤销的证书需要在 Directory 服务器备份时手动发布或取消发布。

要找到与目录不同步的证书 - 不在目录中有效证书，并撤销了仍在目录中或过期的证书 - 证书管理器会在其内部数据库中保留一条记录，无论其内部数据库中的证书是否已发布到该目录。如果证书管理器和发布目录未同步，请使用证书管理器代理服务页面中的 Update Directory 选项，将发布目录与内部数据库同步。

以下选择可用于与内部数据库同步目录：

搜索不同步和发布或未发布或取消发布的证书的内部数据库。
发布在 Directory 服务器停机期间发布的证书。同样，未发布在 Directory 服务器停机期间被撤销或过期的证书。
根据序列号发布或取消发布范围证书，从序列号 xx 向序列号 yy。

证书管理器的发布目录只能由证书管理器代理手动更新。

8.12.1. 手动更新目录中的证书

证书管理器代理服务页面中的 Update Directory Server 表单可以用来使用与证书相关的信息手动更新目录。这个表单启动以下操作的组合：

使用证书更新目录。
从目录中删除过期的证书。
通过调度自动作业，可以从发布目录中删除过期的证书。详情请查看第 12 章 设置自动化任务。
从目录中删除撤销的证书。

通过执行以下操作手动更新目录：

打开证书管理器代理服务页面。
选择 Update Directory Server 链接。
选择适当的选项，然后单击 Update Directory。
证书管理器开始使用其内部数据库中的证书信息来更新目录。如果更改非常大，更新目录可能需要较长时间。在此期间，通过证书管理器进行的任何更改，包括发布任何证书或被撤销的任何证书，则可能不会包含在更新中。如果在更新目录的同时发布或撤销任何证书，请再次更新目录以反映这些更改。

目录更新完成后，证书管理器会显示状态报告。如果进程中断，服务器会记录错误消息。

如果证书管理器作为 root CA 安装，则在使用代理接口更新带有有效证书的目录时，可以使用发布规则为用户证书发布 CA 签名证书。这可能会返回一个对象类违反错误，或者映射器中的其他错误。选择适当的序列号范围来排除 CA 签名证书，可以避免此问题。CA 签名证书是第一个证书 root CA 问题。

通过将 predicate 参数的值更改为 profileId!=caCACert 来修改用户证书的默认发布规则。
使用 LdapCaCertPublisher publisher 插件模块添加另一个规则，使用 predicate 参数设置为 profileId=caCACert，以发布子协调 CA 证书。

8.12.2. 手动更新目录中的 CRL

证书管理器代理服务页面中的证书撤销列表表单需要使用 CRL 相关信息手动更新目录。

通过执行以下操作手动更新 CRL 信息：

打开证书管理器代理服务页面。
选择 Update Revocation List。
点 Update。

证书管理器开始在其内部数据库中使用 CRL 更新目录。如果 CRL 较大，更新目录需要相当长的时间。在此期间，对 CRL 所做的任何更改可能不会包含在更新中。

更新目录时，证书管理器会显示状态报告。如果进程中断，服务器会记录错误消息。

8.13. 注册自定义映射程序和发布程序插件模块

可以在证书管理器的发布框架中注册新的映射程序或发布程序插件模块。可以删除不需要的 mapper 或 publisher 插件模块。在删除模块之前，请删除基于此模块的所有规则。

创建自定义作业类。在本例中，自定义发布程序插件名为 MyPublisher.java。

编译新类。

javac -d . -classpath $CLASSPATH MyPublisher.java

在 CA 的 WEB-INF Web 目录中创建用于存放自定义类的目录，以便 CA 可以访问它们。
```
mkdir /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes
```

将新插件文件复制到 新类 目录中，并将所有者设置为证书证书系统nbsp;System 系统用户(pkiuser)。

cp -pr com /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes

chown -R pkiuser:pkiuser /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes

注册插件。
1. 登录到证书管理器控制台。
```
pkiconsole https://server.example.com:8443/ca
```
2. 在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择发布。
3. 要注册映射程序模块，请选择映射程序，然后选择映射程序插件注册选项卡。
  要注册发布程序模块，请选择 publishers，然后选择 publisher Plug-in Registration 选项卡。
4. 要注册插件，请点击 Register。
5. 设置插件名称和插件类名称。类名称是实施 Java 类的路径。如果这个类是软件包的一部分，请包含软件包名称。例如，要在名为 com.customplugins 的软件包中注册名为 customMapper 的类，其名称是 com.customplugins.customMapper。

第 9 章注册证书的身份验证

本章论述了如何注册端到端实体证书、如何创建和管理服务器证书、证书证书系统中的身份验证方法；系统在注册端点实体证书时使用，以及如何设置这些身份验证方法。

注册即向最终实体发布证书的过程。该进程正在创建和提交请求，对请求进行身份验证，然后批准请求并发布证书。

用于验证最终实体的方法决定了整个注册过程。证书Certificate Systemnbsp;System 可以验证实体的方法有三种：

在 代理批准的 注册中，终端请求将发送到代理进行批准。代理批准证书请求。
在自动注册中，终端请求通过插件进行身份验证，然后处理证书请求；不会参与注册流程中的代理。
在 CMC 注册 中，第三方应用程序可以创建由代理签名并自动处理的请求。

最初为代理批准的注册和 CMC 身份验证配置证书管理器。通过配置其中一个身份验证插件模块来启用自动注册。可以在子系统的单一实例中配置多个身份验证方法。

注意

通过配置自动通知，可为任何身份验证方法签发证书时，可将电子邮件自动发送到终端实体。有关通知的更多信息，请参阅第 11 章 使用自动通知。

9.1. 配置代理(Approved Enrollment)

证书管理器最初是为代理批准的注册配置。最终实体发出请求，请求发送到代理队列以进行代理批准。代理可以修改请求，更改请求的状态，拒绝请求或批准请求。批准请求后，签署的请求将发送到证书管理器进行处理。证书管理器处理请求并发布证书。

代理批准的注册方法不可配置。如果没有为任何其他注册方法配置证书管理器，服务器会自动将所有与证书相关的请求发送到其等待代理批准的队列。这样可确保所有缺少身份验证凭据的请求都发送到请求队列进行代理批准。

要使用代理批准的注册，请将验证方法 留空。例如：

auth.instance_id=

9.2. 自动注册

在自动注册中，用户已成功通过身份验证插件模块中设定的方法验证验证后，会立即处理终端注册请求；不需要代理批准。提供了以下身份验证插件模块：

基于目录的注册。最终实体使用其用户 ID 和密码其 DN 和密码通过 LDAP 目录进行身份验证。请参阅第 9.2.1 节 “设置基于目录的身份验证”。
基于 PIN 的注册。使用其目录 ID、密码和 PIN 在目录条目中设置的 PIN，对最终用户实体进行身份验证。请参阅第 9.2.2 节 “设置基于 PIN 的注册”。
基于证书的身份验证.某种实体（如服务器或令牌）的实体使用 CA 发布的证书向 CA 进行身份验证，该实体证明其身份。这最常用于续订，其中显示原始证书以验证续订过程。请参阅第 9.2.3 节 “使用基于证书的验证”。
AgentCertAuth.如果提交请求的实体作为子系统代理进行身份验证，此方法会自动批准证书请求。用户通过提供代理证书作为代理进行身份验证。如果所提供的证书由子系统识别为代理证书，则 CA 会自动处理证书请求。
此形式的自动身份验证可与用于注册服务器证书的证书配置集关联。
此插件默认启用，且没有参数。
基于文件格式的注册.用于路由器(SCEP)注册，会使用一个文本文件，其中包含 IP 地址、主机名或其他标识符列表，它是一个随机的 PIN。路由器使用其 ID 和 PIN 验证 CA，然后 CA 会将提供的凭证与文本文件中的身份列表进行比较。请参阅第 9.2.4 节 “配置平面文件身份验证”。

9.2.1. 设置基于目录的身份验证

UidPwdDirAuth 和 UdnPwdDirAuth 插件模块实现基于目录的身份验证。最终用户通过在 LDAP 目录中提供用户 ID 或 DN 和密码来注册证书。

创建 UidPwdDirAuth 或 UdnPwdDirAuth 身份验证插件模块并配置实例的实例。
1. 打开 CA 控制台。
```
pkiconsole https://server.example.com:8443/ca
```
2. 在 Configuration 选项卡中，在导航树中选择 Authentication。
  右窗格显示 Authentication Instance 选项卡，它列出了当前配置的验证实例。
  注意
  UidPwdDirAuth 插件默认启用。
3. 点 Add。
  此时会出现 Select Authentication Plug-in Implementation 窗口。
4. 为用户 ID 和密码身份验证选择 UidPwdDirAuth，或者选择 UdnPwdDirAuth 用于 DN 和密码身份验证。
5. 在 Authentication Instance Editor 窗口中填写以下字段：
  - 身份验证实例 ID。接受默认实例名称，或输入新名称。
  - dnpattern.指定一个字符串，代表主题名称模式，以便根据目录属性和条目 DN 进行公式限制。
  - ldapStringAttributes.指定端点实体应被视为身份验证的 LDAP 字符串属性列表。如果指定，与这些属性对应的值将从身份验证目录中复制到身份验证令牌，并由证书配置集用于生成主题名称。此参数输入值是可选的。
  - ldapByteAttributes.指定端点实体应被视为身份验证的 LDAP 字节（二进制）属性列表。如果指定，与这些属性对应的值将从身份验证目录中复制到身份验证令牌，供其他模块使用，如向用户证书添加额外信息。
    此参数输入值是可选的。
  - ldap.ldapconn.host.指定身份验证目录的完全限定 DNS 主机名。
  - ldap.ldapconn.port.指定验证目录侦听请求的 TCP/IP 端口；如果选择了 ldap.ldapconn.secureConn. 复选框，则应为 SSL 端口号。
  - ldap.ldapconn.secureConn.指定身份验证目录监听来自证书证书系统nbsp 的请求的端口类型 SSL 或非 SSL；系统.如果这是 SSL 端口，请选择此项。
  - ldap.ldapconn.version.指定 LDAP 协议版本，可以是 2 或 3。默认值为 3，因为版本 3.x 以后所有目录服务器都是 LDAPv3。
  - ldap.basedn.指定用于搜索身份验证目录的基本 DN。服务器使用 HTTP 输入的 uid 字段的值（用户在注册表单中输入的用户）和基本 DN 来构造 LDAP 搜索过滤器。
  - ldap.minConns.指定身份验证目录允许的最小连接数。允许的可能值为 1 到 3。
  - ldap.maxConns.指定身份验证目录允许的最大连接数。可见的值有 3 到 10。
6. 点击 OK。身份验证实例已设置并启用。
通过为特定证书设置策略，设置证书配置集用于注册用户。通过在证书配置集中配置输入来自定义注册表单，并包括插件验证用户身份所需的信息输入。如果默认输入不包含需要收集的所有信息，请提交使用第三方工具创建的请求。
有关配置配置集的详情请参考第 3.7.2 节 “在 Subject Alt Name 中插入 LDAP 目录属性值和其他信息”。

设置绑定 LDAP 连接

有些环境需要禁止匿名绑定用于身份验证的 LDAP 服务器。要在 CA 和 LDAP 服务器之间建立绑定连接，您需要进行以下配置更改：

根据 CS.cfg 中的以下示例设置基于目录的身份验证：

auths.instance.UserDirEnrollment.ldap.ldapBoundConn=true
auths.instance.UserDirEnrollment.ldap.ldapauth.authtype=BasicAuth
auths.instance.UserDirEnrollment.ldap.ldapauth.bindDN=cn=Directory Manager
auths.instance.UserDirEnrollment.ldap.ldapauth.bindPWPrompt=externalLDAP
externalLDAP.authPrefix=auths.instance.UserDirEnrollment
cms.passwordlist=internaldb,replicationdb,externalLDAP

其中 bindPWPrompt 是 password.conf 文件中使用的标签或提示 ; 它也是 optionpasswordlist 和 authPrefix 选项下使用的名称。

在 password.conf 中添加来自 CS.cfg 的标签或提示：
```
externalLDAP=your_password
```

设置外部授权

还可配置基于目录的身份验证插件来评估用户的组成员资格进行身份验证。要以这种方式设置插件，必须在 CS.cfg 中配置以下选项：

groupsEnable 是一个布尔值选项，用于启用检索组。默认值为 false。
基于组 的基本 DN。当它不同于 基于默认n 时，需要指定它。
组是 组的 DN 组件。默认值为 ou=groups。
groupObjectClass 是以下组对象类之一： groupofquenames、groupofnames。默认值为 groupofquenames。
groupUseridName 是 group object member 属性中用户 ID 属性的名称。默认值为 cn。
useridName 是用户 ID DN 组件的名称。默认值为 uid。
searchGroupUserByUserdn 是一个布尔值选项，决定是否搜索 userdn 或 ${groupUserIdName}=${uid} 属性的组对象 member 属性。默认值为 true。

例如：

auths.instance.UserDirEnrollment.pluginName=UidPwdDirAuth
auths.instance.UserDirEnrollment.ldap.basedn=cn=users,cn=accounts,dc=local
auths.instance.UserDirEnrollment.ldap.groupObjectClass=groupofnames
auths.instance.UserDirEnrollment.ldap.groups=cn=groups
auths.instance.UserDirEnrollment.ldap.groupsBasedn=cn=accounts,dc=local
auths.instance.UserDirEnrollment.ldap.groupsEnable=true
auths.instance.UserDirEnrollment.ldap.ldapconn.host=local
auths.instance.UserDirEnrollment.ldap.ldapconn.port=636
auths.instance.UserDirEnrollment.ldap.ldapconn.secureConn=true

最后，您必须修改 /instance_path/ca/profiles/ca/profile_id.cfg 文件，以配置配置集以使用 CS.cfg 中定义的 UserDirEnrollment auth 实例，并在适当的情况下为基于组的授权提供 ACL。例如：

auth.instance_id=UserDirEnrollment
auths.acl=group="cn=devlab-access,ou=engineering,dc=example,dc=com"

9.2.2. 设置基于 PIN 的注册

基于 PIN 的身份验证涉及为 LDAP 目录中的每个用户设置 PIN，将这些 PIN 分发到用户，然后让用户在填写证书请求时提供 PIN 和 password。然后，用户使用其用户 ID 和密码 LDAP 条目对 LDAP 目录进行身份验证，并使用其 LDAP 条目中的 PIN 进行验证。当用户成功验证时，请求会自动处理，并发出新证书。

CertificateCertificate Systemnbsp;System 提供了一个工具 setpin，它为 Directory Server 添加所需的 schema，并为每个用户生成 PIN。

PIN 工具执行以下功能：

在 LDAP 目录中为 PIN 添加所需的 schema。
在设置的 PIN manager 用户中添加具有读写权限的 PIN manager 用户。
设置 ACI 以允许在使用 PIN 后删除 PIN，为 PIN 提供读写权限，并阻止用户创建或更改 PIN。
在每个用户条目中创建 PIN。

注意

此工具记录在 证书系统命令行工具指南中。

使用 PIN 工具添加 PINs 所需的 schema，将 PIN 添加到用户条目，然后将 PINs 分发到用户。
1. 打开 /usr/share/pki/native-tools/ 目录。
2. 在文本编辑器中打开 setpin.conf 文件。
3. 按照文件中概述的说明进行操作，并进行适当的更改。
  通常，需要更新的参数是 Directory Server 的主机名、Directory Manager 的绑定密码以及 PIN 管理器的密码。
4. 使用 optfile 选项运行 setpin 命令，指向 setpin.conf 文件。
```
setpin optfile=/usr/share/pki/native-tools/setpin.conf
```
  该工具使用新属性（默认为 pinPerson）和一个新的对象类（默认为 pinPerson）修改 schema，并创建一个 pinmanager 用户，并只设置 ACI 以允许 pinmanager 用户修改 pin 属性。
5. 要为特定用户条目生成 PIN，或提供用户定义的 PIN，创建一个输入文件，其中包含列出的条目的 DN。对于 ezample：
```
dn:uid=bjensen,ou=people,dc=example,dc=com
dn:uid=jsmith,ou=people,dc=example,dc=com
dn:jtyler,ou=people,dc=example,dc=com
...
```
  有关构建输入文件的详情，请参考 证书系统命令行工具指南中的 PIN 生成器章节。
6. 禁用 setpin 命令的设置模式。注释掉 setup 行，或者将值更改为 no。
```
vim /usr/share/pki/native-tools/setpin.conf

setup=no
```
  设置模式会创建所需的 uers 和对象类，但工具在设置模式下不会生成 PIN。
7. 运行 setpin 命令在目录中创建 PIN。
  提示
  在不使用 write 选项的情况下运行该工具来生成 PIN 列表，而无需实际更改该目录。
  例如：
```
setpin host=yourhost port=9446 length=11 input=infile output=outfile write "binddn=cn=pinmanager,o=example.com" bindpw="password" basedn=o=example.com "filter=(uid=u*)" hash=sha256
```
  WARNING
  不要将 hash 参数设置为 none。使用 hash=none 运行 setpin 命令会导致 pin 以纯文本形式存储在用户 LDAP 条目中。
8. 完成设置所需的身份验证方法后，使用输出文件向用户提供 PIN。
  确认基于 PIN 的注册工作后，将 PIN 提供给用户，以便在注册期间使用它们。要保护 PIN 的隐私，请使用安全的带外交付方法。
在证书配置集中设置特定证书的策略以注册用户。有关证书策略的详情，请参阅第 3 章 制作发行证书规则（证书配置文件）。
创建并配置 UidPwdPinDirAuth 身份验证插件的实例。
1. 打开 CA 控制台。
```
pkiconsole https://server.example.com:8443/ca
```
2. 在 Configuration 选项卡中，在导航树中选择 Authentication。
  右窗格显示 Authentication Instance 选项卡，它列出了当前配置的验证实例。
3. 点 Add。
  此时会出现 Select Authentication Plug-in Implementation 窗口。
4. 选择 UidPwdPinDirAuth 插件模块。
5. 在 Authentication Instance Editor 窗口中填写以下字段：
  - 身份验证实例 ID。接受默认实例名称或输入新名称。
  - removePin.设置在最终用户成功验证后是否从身份验证目录中删除 PIN。从目录中删除 PIN 会限制用户多次注册，从而防止他们获得多个证书。
  - pinAttr.指定 PIN 的身份验证目录属性。PIN Generator 程序将属性设置为 setpin.conf 文件中的 objectclass 参数的值；此参数的默认值是 pin。
  - dnpattern.指定一个字符串，代表主题名称模式，以便根据目录属性和条目 DN 进行公式限制。
  - ldapStringAttributes.指定端点实体应被视为身份验证的 LDAP 字符串属性列表。此参数输入值是可选的。
  - ldapByteAttributes.指定端点实体应被视为身份验证的 LDAP 字节（二进制）属性列表。如果指定，与这些属性对应的值将从身份验证目录中复制到身份验证令牌，供其他模块使用，如向用户证书添加额外信息。
    此参数输入值是可选的。
  - ldap.ldapconn.host.指定身份验证目录的完全限定 DNS 主机名。
  - ldap.ldapconn.port.指定身份验证目录侦听来自证书证书系统nbsp 的 TCP/IP 端口；系统.
  - ldap.ldapconn.secureConn.指定身份验证目录侦听请求的端口的类型 SSL 或非 SSL。如果这是 SSL 端口，请选择此项。
  - ldap.ldapconn.version.指定 LDAP 协议版本，可以是 2 或 3。默认情况下，这是 3，因为除 3.x 之后的所有目录服务器版本都是 LDAPv3。
  - ldap.ldapAuthentication.bindDN.指定在从身份验证目录中删除 PIN 时要绑定的用户条目。仅在选择了 removePin 复选框时指定此参数。建议有一个单独的用户条目，该用户条目只能修改目录中创建和使用目录中的 PIN 属性。例如，不要使用 Directory Manager 的条目，因为它具有修改整个目录内容的特权。
  - 密码。指定与 ldap.ldapauthbindDN 参数指定的 DN 关联的密码。保存更改后，服务器会将密码存储在单点登录密码缓存中，并使用它来后续启动。只有在选择了 removePin 复选框时，才需要设置此参数。
  - ldap.ldapAuthentication.clientCertNickname.指定用于对认证目录进行 SSL 客户端身份验证的证书 nickname 来删除 PIN。确保证书有效且已由身份验证目录的证书数据库中信任的 CA 签名，并且身份验证目录的 certmap.conf 文件已配置为将证书正确映射到目录中的 DN。只适用于 PIN 才可以删除。
  - ldap.ldapAuthentication.authtype.指定从身份验证目录中删除 PIN 所需的身份验证类型、基本身份验证或 SSL 客户端身份验证。
    Basic auth 指定基本身份验证。使用此选项时，为 ldap.ldapAuthentication.bindDN 和 password 参数输入正确的值，服务器使用 ldap.ldapAuthentication.bindDN 属性中的 DN 绑定到该目录。
    SslClientAuth 指定 SSL 客户端身份验证。使用此选项时，将 ldap.ldapconn.secureConn 参数的值设置为 true，将 ldap.ldapAuthentication.clientCertNickname 参数的值设置为用于 SSL 客户端身份验证的 nickname。
  - ldap.basedn.指定用于搜索身份验证目录的基本 DN；服务器使用 HTTP 输入中的 uid 字段的值（用户在注册表单中输入的用户）和基本 DN 来构造 LDAP 搜索过滤器。
  - ldap.minConns.指定身份验证目录允许的最小连接数。允许的可能值为 1 到 3。
  - ldap.maxConns.指定身份验证目录允许的最大连接数。可见的值有 3 到 10。
6. 点击 OK。
通过在证书配置集中配置输入来自定义注册表单。包括插件验证用户身份所需的信息。如果默认输入不包含需要收集的所有信息，请提交使用第三方工具创建的请求。

9.2.3. 使用基于证书的验证

提供的 证书认证是验证请求者的身份并自动验证提交的请求时，基于证书的身份验证。这通常用于续订过程，当用户、服务器和应用程序提供原始证书时，会使用该证书来验证请求。

在最初请求证书时，使用基于证书的身份验证可能很有用。例如，令牌可以批量加载通用证书，然后用于对用户注册用户证书时验证用户，或者，也可以向用户签发证书，以供用户用于验证其加密证书的请求。

基于证书的验证模块( SSLclientCertAuth )默认是启用的，这个验证方法可在任何自定义证书配置集中引用。

9.2.4. 配置平面文件身份验证

使用随机生成的 PIN 注册并进行身份验证。CA 使用 flatFileAuth 身份验证模块处理包含路由器身份验证凭据的文本文件。

9.2.4.1. 配置 flatFileAuth 模块

已为 SCEP 注册配置了无格式文件身份验证，但可以编辑平面文件及其身份验证参数的位置。

打开 CA 控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡中，在导航树中选择 Authentication。
选择 flatFileAuth 身份验证模块。
单击编辑/查看。
要更改文件位置和名称，请重置 fileName 字段。
要更改身份验证名称参数，请将 keyAttributes 值重置为 SCEP 注册表单中提交的另一个值，如 CN。也可以通过逗号（如 UID、CN ）来分隔多个名称参数，也可以使用多个名称参数。要更改 password 参数名称，请重置 authAttributes 字段。
保存编辑。

9.2.4.2. 编辑 flatfile.txt

相同的 flatfile.txt 文件用于验证每个 SCEP 注册。每次向路由器发布新的 PIN 时，都必须手动更新此文件。

默认情况下，这个文件位于 /var/lib/pki/pki-ca/ca/ 中，并为每个身份验证条目指定两个参数，站点的 UID（通常是它的 IP 地址，可以是 IPv4 或 IPv6），以及路由器发出的 PIN。

UID:192.168.123.123
PIN:HU89dj

每个条目都必须跟一个空行。例如：

UID:192.168.123.123
PIN:HU89dj

UID:12.255.80.13
PIN:fiowIO89

UID:0.100.0.100
PIN:GRIOjisf

如果身份验证条目没有用空行分隔，那么当路由器尝试对 CA 进行身份验证时，将失败。例如：

... flatfile.txt entry ...
UID:192.168.123.123
PIN:HU89dj
UID:12.255.80.13
PIN:fiowIO89

... error log entry ...
[13/Jun/2020:13:03:09][http-9180-Processor24]: FlatFileAuth: authenticating user: finding user from key: 192.168.123.123
[13/Jun/2020:13:03:09][http-9180-Processor24]: FlatFileAuth: User not found in password file.

9.3. CMC 身份验证插件

CMC 注册程序可让注册的客户端使用 CMC 身份验证插件进行身份验证，该插件由证书请求在代理证书或用户证书中预签名，具体取决于插件。当收到使用有效证书签名的 CMC 请求时，证书管理器会自动发布证书。

CMC 身份验证插件还为客户端提供 CMC 撤销程序。CMC 撤销程序可让客户端具有由代理证书签名的证书请求，或者验证拥有证书的用户，然后将此类请求发送到证书管理器。当收到使用有效证书签名的 CMC 撤销请求时，证书管理器会自动撤销证书。

证书系统提供以下 CMC 身份验证插件：

CMCAuth

当 CA 代理为 CMC 请求签名时，请使用此插件。

要使用 CMCAuth 插件，请在注册配置集中设置以下内容：

auth.instance_id=CMCAuth

默认情况下，以下注册配置集使用 CMCAuth 插件：

对于系统证书：
- caCMCauditSigningCert
- caCMCcaCert
- caCMCECserverCert
- caCMCECsubsystemCert
- caCMCECUserCert
- caCMCkraStorageCert
- caCMCkraTransportCert
- caCMCocspCert
- caCMCserverCert
- caCMCsubsystemCert
对于用户证书：
- caCMCUserCert
- caECFullCMCUserCert
- caFullCMCUserCert

CMCUserSignedAuth

当用户提交签名或基于 SharedSecret 的 CMC 请求时，请使用此插件。

要使用 CMCUserSignedAuth 插件，请在注册配置集中设置以下内容：

auth.instance_id=CMCUserSignedAuth

用户签名的 CMC 请求必须由用户的证书签名，该证书包含与请求的证书相同的 subjectDN 属性。如果用户已获取了一个签名证书，则您只能使用用户签名的 CMC 请求，以证明其用于其他证书的身份。

基于 SharedSecret 的 CMC 请求表示请求由请求本身的私钥签名。在这种情况下，CMC 请求必须使用 Shared Secret 机制进行身份验证。基于 SharedSecret 的 CMC 请求通常是用来获取用户的第一个签名证书，稍后用于获取其他证书。详情请查看第 9.4 节 “CMC SharedSecret 身份验证”。

默认情况下，以下注册配置集使用 CMCUserSignedAuth 插件：

caFullCMCUserSignedCert
caECFullCMCUserSignedCert
caFullCMCSharedTokenCert
caECFullCMCSharedTokenCert

9.4. CMC SharedSecret 身份验证

使用 Shared Secret 功能可让用户向服务器发送未签名的 CMC 请求。例如，如果用户要获取第一个签名证书，则需要这样做。之后，可以使用此签名证书对这个用户的其他证书进行签名。

9.4.1. 创建共享 secret 令牌

Red Hat Certificate System planning、Installing 和 Deployment Guide 中的 Shared Secret Workflow 部分描述了使用 Shared Secret Token 时的工作流。根据情况，最终用户或管理员创建共享 Secret 令牌。

注意

要使用共享 secret 令牌，证书系统必须使用 RSA 保障证书。详情请参阅 RHCS 规划、安装和部署指南中的启用 CMC 共享 Secret 功能部分。

要创建共享 Secret 令牌，请输入：

# CMCSharedToken -d /home/user_name/.dogtag/ -p NSS_password \
	     -s "CMC_enrollment_password" -o /home/user_name/CMC_shared_token.b64 \
	     -n "issuance_protection_certificate_nickname"

如果使用 HSM，则额外将 -h token_name 选项传递给命令，以设置 HSM 安全令牌名称。

有关 CMCSharedToken 工具程序的详情，请查看 CMCSharedToken(8) man page。

注意

生成的令牌已加密，只有生成的用户才知道密码。如果 CA 管理员为用户生成令牌，管理员必须以安全的方式向用户提供密码。

创建 Shared Token 后，管理员必须将令牌添加到用户或证书记录中。详情请查看第 9.4.2 节 “设置 CMC 共享 Secret”。

9.4.2. 设置 CMC 共享 Secret

根据计划的操作，管理员必须在用户或证书的 LDAP 条目中生成一个 Shared Secret Token。

有关工作流和使用共享 Secret 的详情，请查看 Red Hat 证书系统规划、安装和部署指南中的 " 共享 Secret 工作流 "部分。

9.4.2.1. 将 CMC 共享 Secret 添加到用于证书注册的用户条目

要将 Shared Secret Token 用于证书注册，请将它作为管理员存储在用户的 LDAP 条目中：

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

	dn: uid=user_name,ou=People,dc=example,dc=com
	changetype: modify
	replace: shrTok
	shrTok: base64-encoded_token

9.4.2.2. 将 CMC 共享 Secret 添加到证书撤销的证书

要将 Shared Secret Token 用于证书撤销，请将它作为管理员存储在要撤销的证书的 LDAP 条目中：

 # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

	dn: cn=certificate_id,ou=certificateRepository,ou=ca,o=pki-tomcat-CA
	changetype: modify
	replace: shrTok
	shrTok: base64-encoded_token

9.5. 测试注册

有关通过配置集测试注册的详情，请参考第 3 章 制作发行证书规则（证书配置文件）。测试最终用户是否可以使用验证方法集成功注册证书：

打开"终端"页面。

https://server.example.com:8443/ca/ee/ca

在 Enrollment 选项卡中，打开自定义注册表单。
填写值并提交请求。
提示时输入密钥数据库的密码。
输入正确的密码时，客户端会生成密钥对。
不要中断密钥进程。在完成密钥生成后，请求将提交到服务器以发布证书。服务器对证书配置文件的请求进行约束，只有在请求满足所有要求时才会发布证书。
签发证书后，在浏览器中安装证书。
验证证书是否在浏览器的证书数据库中安装。
如果基于 PIN 的目录身份验证配置了 PIN 删除，则使用同一 PIN 为另一个证书重新注册。请求应该被拒绝。

9.6. 注册自定义身份验证插件

自定义身份验证插件模块可以通过 CA 控制台进行注册。身份验证插件模块也可以通过 CA 控制台删除。在删除模块之前，删除基于该模块的实例。

注意

要编写自定义插件，请参阅身份验证插件。

创建自定义身份验证类。在本例中，自定义身份验证插件名为 UidPwdDirAuthenticationTestms.java。

编译新类。

javac -d . -classpath $CLASSPATH UidPwdDirAuthenticationTestms.java

在 CA 的 WEB-INF web 目录中创建一个目录来存放自定义类，以便 CA 可以访问它们以获取报名表。
```
mkdir /usr/share/pki/ca/webapps/ca/WEB-INF/classes
```

将新插件文件复制到 新类 目录中，并将所有者设置为证书证书系统nbsp;System 系统用户(pkiuser)。

cp -pr com /usr/share/pki/ca/webapps/ca/WEB-INF/classes

chown -R pkiuser:pkiuser /usr/share/pki/ca/webapps/ca/WEB-INF/classes

登录到控制台。

pkiconsole https://server.example.com:8443/ca

注册插件。
1. 在 Configuration 选项卡中，单击导航树中的 Authentication。
2. 在右侧窗格中，单击 Authentication Plug-in Registration 选项卡。
  选项卡中列出了已经注册的模块。
3. 要注册插件，请点击 Register。
  此时会出现 Register Authentication Plug-in Implementation 窗口。
4. 通过填写以下两个字段来注册的模块：
  - 插件名称。模块的名称。
  - 类名称。此模块的类全名。这是实现 Java™ 类的路径。如果这个类是软件包的一部分，请包含软件包名称。例如，要在名为 com.customplugins 的软件包中注册名为 customAuth 的类，类名称为 com.customplugins.customAuth。
在注册该模块后，将模块添加为活跃的身份验证实例。
1. 在 Configuration 选项卡中，单击导航树中的 Authentication。
2. 在右侧窗格中，单击 Authentication Instance 选项卡。
3. 点 Add。
4. 从列表中选择自定义模块 UidPwdDirAuthenticationTestms.java 以添加模块。填写该模块的适当配置。

创建新的端到端注册表，以使用新的身份验证模块。

cd /var/lib/pki/pki-tomcat/ca/profiles/ca

cp -p caDirUserCert.cfg caDirUserCertTestms.cfg

vi caDirUserCertTestms.cfg

desc=Test ms - This certificate profile is for enrolling user certificates with directory-based authentication.
visible=true
enable=true
enableBy=admin
name=Test ms - Directory-Authenticated User Dual-Use Certificate Enrollment
auth.instance_id=testms
...

将新配置集添加到 CA 的 CS.cfg 文件中。

提示

编辑前备份 CS.cfg 文件。

vim /var/lib/pki/instance-name/ca/conf/CS.cfg

profile.list=caUserCert,caDualCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caOtherCert,caCACert,caInstallCACert,caRACert,caOCSPCert,caTransportCert,caDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthKRAstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,DomainController,caDirUserCertTestms
...
profile.caDirUserCertTestms.class_id=caEnrollImpl
profile.caDirUserCertTestms.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDirUserCertTestms.cfg

重启 CA。

systemctl restart pki-tomcatd@instance_name.service

9.7. 使用命令行手动检查证书状态

要检查证书请求，请确保您已通过正确权限进行身份验证，以批准证书请求。有关配置 pki 命令行界面的详情，请参考第 2.5.1.1 节 “pki CLI initialization”。

查看请求：

显示待处理的证书请求列表：
```
$ pki agent_authentication_parameters ca-cert-request-find --status pending
```
此命令列出所有待处理的证书请求。

下载特定证书请求：

$ pki agent_authentication_parameters ca-cert-request-review id --file request.xml

在编辑器或一个单独的终端中打开 request.xml 文件，并查看请求的内容以确保其是合法的。然后，回答提示：如果请求有效，回答"批准并按 Enter 键。如果请求无效，请回答 reject 并按 Enter。组织可以订阅语义差别 以拒绝 和取消；它们都无法发布证书。

9.8. 使用 Web 界面手动检查证书状态

在网页浏览器中打开以下 URL：

https://server_host_name:8443/ca/agent/ca

作为代理进行身份验证。有关以用户身份进行身份验证和配置浏览器的详情，请参考第 2.4.1 节 “浏览器初始化”。
在左侧的边栏中，单击 List requests 链接。
选择 Show all requests for Request type and Show pending requests for Request status 来过滤请求。
点右下角的 Find。
results 页面会列出等待查看的所有待处理请求。点击请求号来查看请求。
检查请求信息并确保它是合法的请求。如有必要，修改策略信息以更正任何错误，或对证书进行任何更改，例如更改未有效的 after 字段。（可选）保留额外的备注。
下拉菜单包括几个检查状态更新。选择 Approve request 以批准批准请求或拒绝请求以拒绝它，然后单击 Submit。机构可以订阅语义差别，以拒绝请求和取消请求；它们都没有签发证书。

第 10 章注册证书授权（访问 Evaluators）

本章论述了使用访问评估器的授权机制。

10.1. 授权机制

除了身份验证机制外，每个注册的配置文件也可以配置为具有自己的 授权机制。授权机制仅在成功身份验证后执行。

授权机制由 Access Evaluator 插件框架提供。访问评估器是用于评估访问控制指令(ACI)条目的可插入类。机制提供了一种评估方法，它采用预定义的参数列表（即 类型、op、值），评估表达式，如 group='Certificate Manager Agents'，并根据评估结果返回布尔值。

10.2. 默认评估器

Red Hat Certificate Systemnbsp;Hat Certificate Red Hat Certificate Systemnbsp;System 提供 4 个默认评估器。在 CS.cfg 文件中会默认列出以下条目：

accessEvaluator.impl.group.class=com.netscape.cms.evaluators.GroupAccessEvaluator
accessEvaluator.impl.ipaddress.class=com.netscape.cms.evaluators.IPAddressAccessEvaluator
accessEvaluator.impl.user.class=com.netscape.cms.evaluators.UserAccessEvaluator
accessEvaluator.impl.user_origreq.class=com.netscape.cms.evaluators.UserOrigReqAccessEvaluator

组 访问评估器评估用户的组成员资格属性。例如，在以下注册配置集条目中，只有 CA 代理才可以使用该配置集进行注册：

authz.acl=group="Certificate Manager Agents"

ipaddress access evaluator 评估请求主体的 IP 地址。例如，在以下注册配置集条目中，只有指定 IP 地址的主机才可以使用该配置集进行注册：

authz.acl=ipaddress="a.b.c.d.e.f"

用户访问 evaluator 评估用户 ID 完全匹配。例如，在以下注册配置集条目中，只有与列出的用户匹配的用户才可以使用该配置集进行注册：

authz.acl=user="bob"

user_origreq 访问 evaluator 根据前一个匹配的请求评估经过身份验证的用户。此特殊评估器专门设计用于续订的用户，确保请求续订的用户是拥有原始请求的用户。例如，在以下续订注册配置集条目中，经过身份验证的用户的 UID 必须与请求续订的用户 UID 匹配：

authz.acl=user_origreq="auth_token.uid"

新的评估器可以在当前框架中编写，并可通过 CS 控制台进行注册。默认的 evaluators 可用作模板，以展开和自定义到更目标的插件。

第 11 章使用自动通知

CertificateCertificate Systemnbsp;System 可以配置为在签发或撤销证书时向最终用户发送自动电子邮件通知，或者在新请求到达代理请求队列中时向代理发送。本章论述了自动通知和详情如何启用、配置和自定义发送的通知电子邮件消息。

注意

自动通知不会与自动化作业混淆。有关此主题的更多信息，请参阅第 12 章 设置自动化任务。

注意

由于可以发送的通知类型，只有证书管理器才能够为通知配置；此选项不可用于其他子系统。

11.1. 关于 CA 自动通知

自动化通知是发生指定事件时发送的电子邮件消息。系统使用监控系统的监听程序来决定特定事件发生的时间；事件发生时，会触发系统向配置的接收者发送电子邮件。每种通知都使用纯文本或 HTML 模板来构造通知消息。模板包含文本和令牌，被扩展以填充特定事件的正确信息。可以通过更改模板中包含的文本和令牌来自定义消息。也可以针对不同的外观和格式自定义 HTML 模板。

11.1.1. 自动通知的类型

有三种自动通知类型：

证书颁发的.
通知消息会自动发送给已签发证书的用户。如果用户的证书请求被拒绝，则会向用户发送拒绝消息。
证书撤销.
在撤销用户证书时，会自动向用户发送通知消息。
在 Queue 中请求。
当请求使用为代理设置的电子邮件地址时，当请求进入代理时，通知消息会自动发送到一个或多个代理。此通知类型在每次消息进入队列时发送电子邮件。有关队列作业中请求的更多信息，请参阅第 12.1.2.2 节 “requestInQueueNotifier (RequestInQueueJob)”。
还有一个作业，将通知发送到队列状态的代理，其中包括队列状态在特定时间段内的摘要。

11.1.2. 确定最终用户地址

通知系统首先检查证书请求或撤销请求来确定端点的电子邮件地址，然后检查证书的主题名称，如果证书包含此扩展，则会确定证书的 Subject Alternative Name 扩展。如果无法找到电子邮件地址，则将通知发送到通知面板的 Sender 的 Email Address 字段中指定的电子邮件地址。

11.2. 为 CA 设置自动通知

11.2.1. 在控制台中设置自动通知

打开证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

打开 Configuration 选项卡。
在左侧的导航树中打开 Certificate Manager 标题。然后选择通知。
Notification 标签页会出现在窗口的右侧。
可以为三种事件发送通知：新发布的证书、撤销证书和新证书请求。要为任何事件发送通知，选择选项卡，选中" 启用 "复选框，并在以下字段中指定信息：
- 发件人的电子邮件地址 .键入收到发送问题的用户的发件人完整电子邮件地址。
- 收件人的电子邮件地址 .这些是将检查队列的代理的电子邮件地址。要列出多个接收者，请使用逗号将电子邮件地址分开。仅适用于队列中的新请求。
- 主题.键入通知的主题标题。
- 内容模板路径.键入路径，包括文件名，到包含模板用来构造消息内容的目录。
点 Save。
注意
确保邮件服务器设置正确。请参阅第 11.4 节 “为证书证书系统配置邮件服务器; 系统通知”。
自定义通知消息模板。如需更多信息，请参阅第 11.3 节 “自定义通知消息”。
测试配置。请参阅第 11.2.3 节 “测试配置”。

11.2.2. 通过编辑 CS.cfg 文件配置特定通知

停止 CA 子系统。

systemctl stop pki-tomcatd@instance_name.service

打开该实例的 CS.cfg 文件。此文件位于实例的 conf/ 目录中。

编辑正在启用的通知类型的所有配置参数。

对于证书发出通知，有四个参数：

ca.notification.certIssued.emailSubject
ca.notification.certIssued.emailTemplate
ca.notification.certIssued.enabled
ca.notification.certIssued.senderEmail

对于证书撤销通知，有四个参数：

ca.notification.certRevoked.emailSubject
ca.notification.certRevoked.emailTemplate
ca.notification.certRevoked.enabled
ca.notification.certRevoked.senderEmail

对于证书请求通知，有五个参数：

ca.notification.requestInQ.emailSubject
ca.notification.requestInQ.emailTemplate
ca.notification.requestInQ.enabled
ca.notification.requestInQ.recipientEmail
ca.notification.requestInQ.senderEmail

通知消息的参数在第 11.2 节 “为 CA 设置自动通知” 中解释。

保存该文件。

重启 CA 实例。

systemctl start pki-tomcatd@instance_name.service

如果创建了作业来发送自动化消息，请检查邮件服务器是否已正确配置。请参阅第 11.4 节 “为证书证书系统配置邮件服务器; 系统通知”。
自动发送的消息可以自定义；如需更多信息，请参阅第 11.3 节 “自定义通知消息”。

11.2.3. 测试配置

要测试子系统是否按配置发送电子邮件通知，请执行以下操作：

将队列通知中请求的通知电子邮件地址更改为可访问代理或管理员电子邮件地址。
打开终端页面，并使用代理批准的报名表请求证书。
当请求排队进行代理批准时，应该发送 request-in-queue 电子邮件通知。检查消息以查看它是否包含配置信息。
登录到代理接口，并批准请求。
当服务器发布证书时，用户会向请求中列出的地址收到证书签发的电子邮件通知。检查消息以查看它是否具有正确的信息。
登录到代理接口，并撤销证书。
用户电子邮件帐户应包含一条电子邮件消息读取证书已被撤销。检查消息以查看它是否具有正确的信息。

11.3. 自定义通知消息

电子邮件通知使用每种消息类型的模板进行构建。这样，信息可以易于可重复使用，并方便自定义。CA 使用模板作为其通知消息。存在独立的模板，适用于 HTML 和纯文本消息。

11.3.1. 自定义 CA 通知消息

每种 CA 通知消息都有一个 HTML 模板，并关联一个纯文本模板。消息构建自文本、令牌，以及 HTML 模板 HTML 标记。令牌是 变量，由消息中的美元符号($)标识，在消息被构造时替换为当前值。有关可用令牌列表，请参阅表 11.3 “通知变量”。

可以通过更改消息模板中的文本和令牌来修改消息类型的内容。可以通过修改 HTML 消息模板中的 HTML 命令来更改 HTML 消息的外观。

证书验证信息的默认文本版本如下：

Your certificate request has been processed successfully.
SubjectDN= $SubjectDN
IssuerDN= $IssuerDN
notAfter= $NotAfter
notBefore= $NotBefore
Serial Number= 0x$HexSerialNumber
To get your certificate, please follow this URL:
https://$HttpHost:$HttpPort/displayBySerial?op=displayBySerial&
 serialNumber=$SerialNumber
Please contact your admin if there is any problem.
And, of course, this is just a \$SAMPLE\$ email notification form.

通过重新排列、添加或删除令牌和文本，可以根据需要自定义此模板，如下所示：

THE EXAMPLE COMPANY CERTIFICATE ISSUANCE CENTER
Your certificate has been issued!
You can pick up your new certificate at the following website:
https://$HttpHost:$HttpPort/displayBySerial?op=displayBySerial&
 serialNumber=$SerialNumber
This certificate has been issued with the following information:
Serial Number= 0x$HexSerialNumber
Name of Certificate Holder = $SubjectDN
Name of Issuer = $IssuerDN
Certificate Expiration Date = $NotAfter
Certificate Validity Date = $NotBefore
Contact IT by calling X1234, or going to the IT website http://IT
 if you have any problems.

通知模板位于 /var/lib/pki/instance_name/ca/emails 目录中。

可以更改这些消息的名称和位置；在配置通知时进行适当的更改。所有模板名称都可以更改，除了证书被拒绝的模板外，这些名称必须保持相同。与证书关联的模板需要位于同一目录中，且证书拒绝的模板必须位于同一目录中，并且必须使用相同的扩展名。

表 11.1 “通知模板” 列出为创建通知消息提供的默认模板文件。表 11.2 “作业通知电子邮件模板” 列出为创建作业摘要信息而提供的默认模板文件。

表 11.1. 通知模板

文件名	描述
certIssued_CA	发布证书时，纯文本通知电子邮件模板到结束实体。
certIssued_CA.html	签发证书时，基于 HTML 的通知电子邮件模板以结束实体。
certRequestRejected.html	当证书请求被拒绝时，基于 HTML 的通知电子邮件模板到最终实体。
certRequestRevoked_CA	撤销证书时，用于纯文本通知电子邮件到结束实体的模板。
certRequestRevoked_CA.html	撤销证书时，基于 HTML 的通知电子邮件模板以结束实体。
reqInQueue_CA	当请求进入队列时，向代理发出纯文本通知电子邮件的模板。
reqInQueue_CA.html	当请求进入队列时，适用于基于 HTML 的通知电子邮件模板到代理。

表 11.2. 作业通知电子邮件模板

文件名	描述
rnJob1.txt	用于创建发送到最终用户的消息内容的模板，告知他们其证书即将过期，并在证书过期之前被续订或替换。
rnJob1Summary.txt	构建要发送到代理和管理员的摘要报告的模板。使用 `rnJob1Item.txt` 模板来格式化消息中的项目。
rnJob1Item.txt	用于格式化摘要报告中包含的项目的模板。
riq1Item.html	用于格式化摘要表中所含项目的模板，该模板使用 `riq1Summary.html` 模板进行构建。
riq1Summary.html	用于公式表示报告或表的模板，用于概述证书管理器的代理队列中的待处理请求数量。
publishCerts	报告或表的模板，用于汇总要发布到该目录的证书。使用 `publishCertsItem.html` 模板格式化表中的项目。
publishCertsItem.html	用于格式化摘要表中所含项目的模板。
ExpiredUnpublishJob	汇总从目录中过期的证书的报告或表的模板。使用 `ExpiredUnpublishJobItem` 模板来格式化表中的项目。
ExpiredUnpublishJobItem	用于格式化摘要表中所含项目的模板。

表 11.3 “通知变量” 列出并定义可在通知模板中使用的变量。

表 11.3. 通知变量

令牌	描述
$CertType	指定证书的类型，可以是以下任意一种： TLS 客户端（客户端） TLS 服务器（服务器） CA 签名证书(ca) 其他（其他）。
$ExecutionTime	给出作业运行的时间。
$HexSerialNumber	为以十六进制格式发布的证书指定序列号。
$HttpHost	授予证书管理器的完全限定主机名，以便最终实体应连接到其证书以检索其证书。
$HttpPort	给出证书管理器的结束日期（非 TLS）端口号。
$InstanceID	提供发送通知的子系统的 ID。
$IssuerDN	提供签发证书的 CA 的 DN。
$NotAfter	提供有效期日期。
$NotBefore	给出有效期限的开始日期。
$RecipientEmail	给出接收者的电子邮件地址。
$RequestId	给出请求 ID。
$RequestorEmail	给出请求者的电子邮件地址。
$RequestType	提出的请求类型。
$RevocationDate	给出证书被撤销的日期。
$SenderEmail	给出发件人的电子邮件地址；这与通知配置中的 Sender 的 E-mail Address 字段中指定的地址相同。
$SerialNumber	为发出的证书指定序列号 ; 序列号显示为生成的消息中的十六进制值。
$Status	请求状态。
$SubjectDN	提供证书主体的 DN。
$SummaryItemList	列出摘要通知中的项目。每个项目对应作业检测或从发布目录中删除的证书。
$SummaryTotalFailure	指定摘要报告失败的项目总数。
$SummaryTotalNum	指定在队列中待处理的证书请求总数或要从概述报告中的目录中更新或删除的证书总数。
$SummaryTotalSuccess	显示摘要报告中项目总数的数目。

11.4. 为证书证书系统配置邮件服务器; 系统通知

通知和作业功能使用在 CertificateCertificate Systemnbsp;System CA 实例中发送通知邮件中配置的邮件服务器。通过执行以下操作设置邮件服务器：

打开 CA 子系统管理控制台。例如：
```
pkiconsole https://server.example.com:8443/ca
```
在配置选项卡中，突出显示顶部的实例名称，然后选择 SMTP 选项卡。
提供邮件服务器的服务器名称和端口号。
服务器名称是安装邮件服务器的计算机的完全限定 DNS 主机名，如 mail.example.com。默认情况下，邮件服务器的主机名为 localhost，而不是实际主机名。
SMTP 邮件服务器侦听的默认端口号为 25。
点 Save。

11.5. 为 CA 创建自定义通知

通过为证书Certificate Systemnbsp 编辑现有的电子邮件通知插件，可以创建自定义通知功能来处理其他 PKI 操作，如令牌注册。在尝试创建和使用自定义通知插件之前，请联系红帽nbsp;Hat 支持服务。

第 12 章设置自动化任务

CertificateCertificate Systemnbsp;System 提供了一个自定义作业调度程序，它支持各种用于调度 cron 任务的机制。本章论述了如何配置 CertificateCertificate Systemnbsp;System 以使用特定作业插件模块来完成作业。

注意

自动化作业 不会与自动通知混淆。有关此主题的更多信息，请参阅第 11 章 使用自动通知。

12.1. 关于自动任务

证书管理器控制台包含一个 作业调度程序选项，可以在指定时间执行特定的作业。Job Scheduler 与传统的 Unix cron 守护进程类似；它使用注册的 cron 作业，并在预先配置的日期和时间执行它们。如果配置，调度程序会检查等待执行的作业的指定间隔 ; 如果指定的执行时间已到达，调度程序会自动启动该作业。

作业使用 Java™ 类实施，然后使用 CertificateCertificate Systemnbsp 进行了注册；System as plug-in 模块。可以使用 job 模块的一个实施来配置作业的多个实例。每个实例必须具有唯一的名称（无空格的字母数字字符串），并可包含不同的输入参数值以应用到不同的作业。

12.1.1. 设置自动化任务

自动化作业功能通过执行以下操作来设置：

启用和配置作业调度程序 ; 如需更多信息，请参阅第 12.2 节 “设置作业调度程序”。
为这些作业模块启用和配置作业模块并设置首选项 ; 如需更多信息，请参阅第 12.3 节 “设置特定作业”。
通过更改与通知类型关联的模板，自定义这些作业发送的电子邮件通知消息。消息内容由纯文本消息和 HTML 消息组成；通过更改 HTML 模板来修改外观。如需更多信息，请参阅第 11.3.1 节 “自定义 CA 通知消息”。

12.1.2. Automated 任务类型

自动作业类型是 RenewalNotificationJob、RequestInQueueJob、PublishCertsJob 和 UnpublishExpiredJob。在部署证书系统时，会创建每种作业类型的一个实例。

12.1.2.1. certRenewalNotifier (RenewalNotificationJob)

certRenewalNotifier 作业会检查即将在内部数据库中过期的证书。找到一个时，它会自动向证书的所有者发送电子邮件，并在配置的时间或直到证书被替换前继续发送电子邮件提醒。该作业将收集所有续订通知的汇总信息，并将摘要发送到配置的代理或管理员。

作业使用电子邮件解析器确定要发送通知的电子邮件地址。默认情况下，电子邮件地址在证书本身或证书相关的注册请求中找到。

12.1.2.2. requestInQueueNotifier (RequestInQueueJob)

requestInQueueNotifier 作业以预先配置的时间间隔检查请求队列的状态。如果队列中等待任何延迟的注册请求，作业会构建一封电子邮件消息，信息汇总其结果并将其发送到指定的代理。

12.1.2.3. publishCerts (PublishCertsJob)

发布证书作业会检查添加到已发布的发布目录中的所有新证书。当添加了这些新证书时，通过发布 Certs 作业会自动将它们发布到 LDAP 目录或文件中。

注意

大多数时候，发布者会立即发布任何与规则匹配的证书，并将其规则与相应的发布目录一起发布。

如果在创建证书时成功发布证书，则 publishCerts 作业将不会重新发布该证书。因此，新证书不会在作业摘要报告中列出，因为摘要只会列出 publishCerts 作业发布的证书。

12.1.2.4. unpublishExpiredCerts (UnpublishExpiredJob)

过期的证书不会自动从发布目录中删除。如果证书管理器被配置为将证书发布到 LDAP 目录，则目录会包含过期的证书。

unpublishExpiredCerts 作业检查是否已过期且仍然标记为已配置的时间间隔在内部数据库中 发布的 证书。作业连接到发布目录并删除这些证书，然后将这些证书标记为内部数据库中 未发布。作业收集其删除的过期证书的摘要，并将摘要发送到配置指定的代理或管理员。

注意

此作业自动从目录中删除过期的证书。过期的证书也可以手动删除。有关这个证书的更多信息，请参阅第 8.12 节 “更新目录中的证书和 CRL”。

12.2. 设置作业调度程序

只有在启用了作业调度程序时，证书管理器才能执行作业。作业设置（如启用作业调度、设置频率和启用作业模块）可以通过证书Certificate Systemnbsp;System CA Console 或编辑 CS.cfg 文件来完成。

打开 Job Scheduler：

打开证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

在 Configuration 选项卡导航树中，单击 Job Scheduler。
这将打开 General Settings 选项卡，其中显示作业调度程序当前是否已启用。
单击 Enable Jobs Schedule 复选框，以启用或禁用作业调度程序。
禁用作业调度程序会关闭所有作业。
设置调度程序在 Check Frequency 字段中检查作业的频率。
频率是作业调度程序守护进程线程的启动和调用符合 cron 规格的已配置作业的频率。默认情况下，它被设置为一分钟。
注意
输入此信息的窗口可能太小以查看输入信息。拖动证书管理器控制台的基石，以扩大整个窗口。
点 Save。

12.3. 设置特定作业

可以通过证书管理器控制台或编辑配置文件目录来配置自动化作业。建议通过证书管理器控制台进行这些更改。

12.3.1. 使用证书管理器控制台配置特定作业

使用证书管理器控制台启用和配置自动化作业：

打开证书管理器控制台。

pkiconsole https://server.example.com:8443/ca

确认作业调度程序已启用。如需更多信息，请参阅第 12.2 节 “设置作业调度程序”。
在 Configuration 选项卡中，从导航树中选择 Job Scheduler。然后选择 Jobs 以打开 Job Instance 选项卡。
从列表中选择作业实例，再单击 Edit/View。
Job Instance Editor 打开显示当前作业配置。
图 12.1. 作业配置
选择 enabled 以打开作业。
通过在对话框的字段中指定配置设置来设置配置设置。
- 有关 certRenewalNotifier，请参阅第 12.3.3 节 “certRenewalNotifier 的配置参数”。
- 对于 requestInQueueNotifier，请参阅第 12.3.4 节 “requestInQueueNotifier 的配置参数”。
- 有关 发布证书，请参阅第 12.3.5 节 “发布证书的配置参数”。
- 有关 unpublishExpiredCerts，请参阅第 12.3.6 节 “unpublishExpiredCerts 的配置参数”。
- 有关设置 cron 时间频率的详情，请参考第 12.3.7 节 “自动任务的频率设置”。
点击 OK。
点 Refresh 查看主窗口中的任何更改。
如果作业被配置为发送自动消息，请检查邮件服务器是否设置正确。请参阅第 11.4 节 “为证书证书系统配置邮件服务器; 系统通知”。
自定义电子邮件消息文本和外观。

12.3.2. 通过编辑配置文件配置作业

确保已启用并配置了 Jobs Scheduler；请参阅第 12.2 节 “设置作业调度程序”。

停止 CA 子系统实例。

systemctl stop pki-tomcatd@instance_name.service

在文本编辑器中打开该服务器实例的 CS.cfg 文件。
编辑正在配置的作业模块的所有配置参数。
- 要配置 certRenewalNotifier 作业，请编辑以 作业Scheduler.job.certRenewalNotifier 开头的所有参数；请参阅第 12.3.3 节 “certRenewalNotifier 的配置参数”。
- 要配置 requestInQueueNotifier 作业，请编辑以 作业Scheduler.job.requestInQueueNotifier 开始的所有参数；请参阅第 12.3.4 节 “requestInQueueNotifier 的配置参数”。
- 要配置发布证书作业，请编辑以 job Scheduler.job. publishCerts 开头的所有参数; 请参阅第 12.3.5 节 “发布证书的配置参数”。
- 要配置 未发布ExpiredCerts 作业，请编辑以 job Scheduler.job.unpublishExpiredCerts 开头的所有参数；请参阅第 12.3.6 节 “unpublishExpiredCerts 的配置参数”。
保存该文件。

重启服务器实例。

systemctl start pki-tomcatd@instance_name.service

如果作业将发送自动消息，请检查邮件服务器是否设置正确。请参阅第 11.4 节 “为证书证书系统配置邮件服务器; 系统通知”。
自定义自动作业消息。

12.3.3. certRenewalNotifier 的配置参数

表 12.1 “certRenewalNotifier 参数” 提供可为 certRenewalNotifier 作业配置的、可在 CS.cfg 文件中或证书管理器控制台中配置的每个参数的详细信息。

表 12.1. certRenewalNotifier 参数

参数	描述
enabled	指定作业是启用或禁用的。值 true 启用作业； false 可禁用它。
cron	设置应运行此作业时的时间表。这将设置作业调度程序守护进程线程检查发送续订通知的证书的时间。这些设置必须遵循第 12.3.7 节 “自动任务的频率设置” 中的约定。例如： 0 3 * * 1-5 示例中的作业会在周一到下午 3:00 运行。
notifyTriggerOffset	设定第一次发送通知的证书过期日期前的时长（以天为单位）。
notifyEndOffset	设定证书过期后（以天为单位）在证书没有替换的情况下，继续发送通知的时间。
senderEmail	设置通知消息的发送者，该发件人将收到任何发送问题的通知。
emailSubject	设置通知消息的主题行文本。
emailTemplate	将路径（包括文件名）设置为包含模板用来创建消息内容的目录。
summary.enabled	设定续订通知的摘要报告应编译和发送。值 true 启用发送概述; false 可禁用它。如果启用，请设置剩余的摘要参数；服务器需要它们来发送摘要报告。
summary.recipientEmail	指定概述信息的接收者。这些可以是需要知道用户证书或其他用户状态的代理。通过使用逗号分隔每个电子邮件地址来设定多个接收者。
summary.senderEmail	指定摘要消息的发件人电子邮件地址。
summary.emailSubject	提供摘要消息的主题行。
summary.itemTemplate	将路径（包括文件名）指定到包含模板的目录，用于创建概述报告中各个项目的内容和格式。
summary.emailTemplate	将路径（包括文件名）指定到包含用于创建摘要报告电子邮件通知的目录。

12.3.4. requestInQueueNotifier 的配置参数

表 12.2 “requestInQueueNotifier 参数” 提供可为 requestInQueueNotifier 作业配置的、可在 CS.cfg 文件或证书管理器控制台中配置的每个参数的详细信息。

表 12.2. requestInQueueNotifier 参数

参数	描述
enabled	设定作业是否已启用(true)还是禁用(

Language and Page Formatting Options

管理指南

更新了 Red Hat Certificate System 9.7

第 1 章 Red Hat Certificate Systemnbsp 概述;Hat Certificate Red Hat Certificate Systemnbsp;System Subsystems

1.1. 使用证书

1.2. CertificateCertificate Systemnbsp 的评论;系统 子系统

Enterprise 安全客户端

1.3. 查看管理证书(Non-TMS)

1.4. 查看令牌管理系统(TMS)

1.5. RedRed Hat Certificate Systemnbsp;Hat CertificateRed Hat Certificate Systemnbsp;System services

部分 I. Red Hat Certificate System User Interfaces

第 2 章 用户界面

2.1. 用户界面概述

2.2. 客户端 NSS 数据库初始化

2.3. 图形界面

2.3.1. pkiconsole complete

2.3.2. 将 pkiconsole 用于 CA、OCSP、KRA 和 TKS Subsystems

2.4. Web 界面

2.4.1. 浏览器初始化

导入 CA 证书

导入客户端证书

访问 Web 控制台

2.4.2. 管理接口

2.4.3. 代理接口

2.4.4. 最终用户页面

2.5. 命令行界面

2.5.1. "pki" CLI

2.5.1.1. pki CLI initialization

2.5.1.2. Using "pki" CLI

2.5.2. AtoB

2.5.3. AuditVerify

2.5.4. BtoA

2.5.5. CMCRequest

2.5.6. CMCRevoke

2.5.7. CMCSharedToken

2.5.8. CRMFPopClient

2.5.9. HttpClient

2.5.10. OCSPClient

2.5.11. PKCS10Client

2.5.12. PrettyPrintCert

2.5.13. PrettyPrintCrl

2.5.14. TokenInfo

2.5.15. tkstool

2.6. Enterprise 安全客户端

部分 II. 设置证书服务

第 3 章 制作发行证书规则（证书配置文件）

3.1. 关于证书配置集

3.1.1. 注册配置集

3.1.2. 证书扩展：默认和限制

3.1.3. 输入和输出

3.2. 设置证书配置集

3.2.1. 使用 PKI 命令行界面管理证书注册配置集

3.2.1.1. 启用和禁用证书配置集

3.2.1.2. 以 Raw 格式创建证书配置集

3.2.1.3. 使用 Raw 格式编辑证书配置文件

3.2.1.4. 删除证书配置集

3.2.2. 使用基于 Java 的管理控制台管理证书注册配置集

3.2.2.1. 通过 CA 控制台创建证书配置集

3.2.2.2. 在控制台中编辑证书配置集

3.2.3. 列出证书注册配置集

3.2.4. 显示证书注册配置集详情

3.3. 在配置集中定义密钥默认值

3.4. 配置配置集以启用续订

3.4.1. 使用 Same Key 续订

3.4.2. 使用新密钥续订

3.5. 为证书设置签名算法

3.5.1. 设置 CA 的默认签名算法

3.5.2. 在配置集中设置 Signing Algorithm Default

3.6. 管理 CA-Related 配置集

3.6.1. 在 CA 证书中设置限制

3.6.2. 在签发者证书上更改 CA 的限制

3.6.3. 使用 Random 证书串行号

3.6.3.1. 启用 Random 证书串行数

3.6.4. 允许 CA 证书续订 CA 有效期期

3.7. 管理主题名称和主题备用名称

3.7.1. 在 Subject Name 中使用 Requester CN 或 UID

3.7.2. 在 Subject Alt Name 中插入 LDAP 目录属性值和其他信息

3.7.3. 使用 SAN 扩展中的 CN 属性

3.7.4. 接受 CSR 的 SAN 扩展

3.7.4.1. 将配置文件配置为来自 CSR 的检索 SAN

1.2. CertificateCertificate Systemnbsp 的评论;系统子系统

第 2 章用户界面

2.3.1. `pkiconsole` complete

2.3.2. 将 `pkiconsole` 用于 CA、OCSP、KRA 和 TKS Subsystems

第 3 章制作发行证书规则（证书配置文件）

第 4 章设置密钥存档和恢复

第 5 章请求、注册和管理证书

5.2.1.1. 使用 `certutil`创建 CSR

5.2.1.1.1. 使用 `certutil` 创建带有 EC 密钥的 CSR

5.2.1.1.2. 使用 `certutil` 使用用户定义的扩展来创建 CSR

5.2.1.2. 使用 `PKCS10Client`创建 CSR

5.2.1.2.1. 使用 `PKCS10Client` 创建 CSR

5.2.1.2.2. 使用 `PKCS10Client` 为基于 SharedSecret 的 CMC 创建 CSR

5.2.1.3. 使用 `CRMFPopClient`创建 CSR

5.2.1.3.1. 使用 `CRMFPopClient` 创建带有密钥 Archival 的 CSR

5.2.1.3.2. 使用 `CRMFPopClient` 为基于 SharedSecret 的 CMC 创建 CSR

5.2.1.4. 在 `PKI` CLI 中使用 `client-cert-request` 创建 CSR