搜索
支持控制台（Console）开发人员开始试用联系人

管理指南

download PDF
Red Hat Certificate System 10

为 Red Hat Certificate System 10.4 更新

Florian Delehaye

Red Hat Customer Content Services

Marc Muehlfeld

Red Hat Customer Content Services

Petr Bokoč

Red Hat Customer Content Services

Filip Hanzelka

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Ella Deon Ballard

Red Hat Customer Content Services

摘要

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

第 1 章 Red Hat Certificate System 子系统概述

每个常见的 PKI 操作 - 发布、续订和撤销证书；归档和恢复密钥；发布 CRL 并验证证书状态 - 通过 Red Hat Certificate System 中的操作子系统实现。本章介绍了每个子系统的功能及其一起建立强大和本地 PKI 的方法。

1.1. 证书使用

证书的目的是建立信任。它们的使用情况因用于确保的信任类型而异。某些类型的证书用于验证显示者的身份；其他证书用于验证对象或项目未被篡改。
有关如何使用证书、证书类型或证书如何建立身份和关系的详情，请参考 Red Hat Certificate System Planning, Installation, and Deployment Guide 中的 Certificates and Authentication 部分。

1.2. 证书系统子系统的审阅

Red Hat Certificate System 提供五个不同的子系统，每个子系统侧重于 PKI 部署的不同方面。这些子系统协同工作来创建公钥基础架构(PKI)。根据安装的子系统，PKI 可以充当令牌管理系统(TMS)或非令牌管理系统。有关子系统和 TMS 和非 TMS 环境的描述，请参阅 Red Hat Certificate System Planning、安装和部署指南中的证书系统子系统 部分。
企业安全客户端
企业安全客户端不是子系统，因为它不使用证书、密钥或令牌执行任何操作。企业安全客户端是一个用户界面，允许人员轻松地在智能卡上管理证书。企业安全客户端将所有令牌操作（如证书请求）发送到令牌处理系统(TPS)，然后将其发送到证书颁发机构(CA)。如需更多信息，请参阅使用 企业安全客户端管理智能卡。

1.3. A Look at manage Certificates (Non-TMS)

传统 PKI 环境提供基本的框架来管理存储在软件数据库中的证书。这是一个 非 TMS 环境，因为它不管理智能卡上的证书。至少，非TMS 只需要一个 CA，但非TMS 环境也可以使用 OCSP 响应者 和 KRA 实例。
有关此主题的详情，请查看 Red Hat Certificate System Planning, Installation, installation, and Deployment Guide 中的以下部分：

1.4. 令牌管理系统(TMS)的 Look

证书系统创建、管理、续订和吊销证书，同时还存档和恢复密钥。对于使用智能卡的机构，证书系统具有令牌管理系统 - 带有已建立关系的子系统集合 - 生成密钥和请求并接收要用于智能卡的证书。
有关此主题的详情，请查看 Red Hat Certificate System Planning, Installation, installation, and Deployment Guide 中的以下部分：

1.5. Red Hat Certificate System 服务

根据用户类型，可以通过各种不同的接口来管理证书和子系统：管理员、代理、审核员和最终用户。有关通过每个接口执行的不同功能的概述，请参阅 用户界面部分。

部分 I. Red Hat Certificate System 用户界面

第 2 章 用户界面

根据用户的角色，可以通过不同的接口来管理证书和子系统：管理员、代理、审核员和最终用户。

2.1. 用户界面概述

管理员可以使用以下界面与已完成的证书系统安装安全地交互：
  • PKI 命令行界面和其他命令行工具
  • PKI 控制台图形界面
  • 证书系统 Web 界面。
这些接口需要在使用之前配置，以通过 TLS 与证书系统服务器安全通信。不允许使用这些客户端而无需正确配置。其中一些工具使用 TLS 客户端身份验证。在需要时，其所需的初始化过程包括配置此功能。使用哪个界面取决于管理员的首选项和功能。本章后面介绍了使用这些接口的常见操作。
默认情况下，PKI 命令行界面使用用户的 ~/.dogtag/nssdb/ 目录中的 NSS 数据库。第 2.5.1.1 节 “pki CLI 初始化” 提供使用管理员证书和密钥初始化 NSS 数据库的详细步骤。第 2.5.1.2 节 “使用 "pki" CLI” 中描述了使用 PKI 命令行工具的一些示例。在指南的其余部分中显示了其他示例。
可以使用各种命令行实用程序提交 CMC 请求、管理生成的证书等，与证书系统（作为其他用户角色中的管理员）交互。它们在 第 2.5 节 “命令行界面” 中进行了描述，如 第 2.5.2 节 “AtoB”。这些工具在以后的小节中会使用，如 第 5.2.1.2 节 “使用 PKCS10Client创建 CSR”。
证书系统 Web 界面允许通过 Firefox Web 浏览器进行管理访问。第 2.4.1 节 “浏览器初始化” 描述配置客户端身份验证的说明。第 2.4 节 “Web 界面” 中描述的其他部分使用证书系统的 Web 界面。
证书系统的 PKI 控制台是一个图形界面。请注意，它已被弃用。 第 2.3.1 节 “pkiconsole 初始化” 描述了如何初始化这个控制台界面。第 2.3.2 节 “将 pkiconsole 用于 CA、OCSP、KRA 和 TKS 子系统” 提供有关使用它的概述。后续部分，如 第 3.2.2 节 “使用基于 Java 的管理控制台管理证书注册配置文件” 为特定操作进行了更详细的信息。
注意
要终止 PKI 控制台会话，请单击 Exit 按钮。要终止 Web 浏览器会话，请关闭浏览器。命令行工具在执行操作并返回提示后立即终止自己，因此管理员部分不需要任何操作来终止会话。

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

在 Red Hat Certificate System 上，某些接口可能需要使用 TLS 客户端证书身份验证（双向身份验证）访问服务器。在执行服务器端管理任务前，您需要：
  1. 为客户端准备 NSS 数据库。这可以是新数据库或现有数据库。
  2. 导入 CA 证书链并信任它们。
  3. 具有证书和对应密钥。它们可以在 NSS 数据库中生成，或者从其它位置导入，例如从 PKCS the 文件中导入。
根据实用程序，您需要相应地初始化 NSS 数据库。请参阅：

2.3. 图形界面

重要
pkiconsole 已被弃用。
证书系统控制台pkiconsole 是一个图形界面，专为具有管理员角色权限的用户而设计，以管理子系统本身。这包括添加用户、配置日志、管理配置集和插件以及许多其他功能。此实用程序使用客户端身份验证通过 TLS 与证书系统服务器通信，并可用于远程管理服务器。

2.3.1. pkiconsole 初始化

要第一次使用 pkiconsole 接口，请指定新密码并使用以下命令： 
$ pki -c password -d ~/.redhat-idm-console client-init
此命令在 ~/.redhat-idm-console/ 目录中创建新客户端 NSS 数据库。
要将 CA 证书导入到 PKI 客户端 NSS 数据库中，请参阅 Red Hat Certificate System Planning , Installation, and Deployment Guide中的将证书导入到 NSS 数据库 部分。
要请求新客户端证书，请参阅 第 5 章 请求、注册和管理证书。
执行以下命令，从 .p12 文件中提取 admin 客户端证书： 
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
按照 Red Hat Certificate System Planning, Installation, and Deployment Guide 中的 Managing Certificate/Key Crypto Token 部分所述，验证并导入 admin 客户端证书： 
$ PKICertImport -d ~/.redhat-idm-console -n "nickname" -t ",," -a -i file.crt -u C
重要
在导入 CA admin 客户端证书前，请确保所有中间证书和 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 子系统

Java 控制台供四个子系统使用：CA、IADP、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 证书
  1. 点 Menu → Preferences → Privacy & Security → View certificate。
  2. 选择 "权限 "选项卡，然后单击 导入 按钮。
  3. 选择 ca.crt 文件并点击 Import。
导入客户端证书
  1. 点 Options → Preferences → Privacy & Security → View certificate。
  2. 选择 Your Certificates 选项卡。
  3. 单击 Import，再选择客户端 p12 文件，如 ca_admin_cert.p12。
  4. 在提示符处输入客户端证书的密码。
  5. 点确定。
  6. 验证您的证书下是否添加了 条目。
访问 Web 控制台
您可以通过在浏览器中打开 https://host_name:port 来访问 PKI 服务。

2.4.2. 管理接口

所有子系统都使用基于 HTML 的管理界面。可通过输入主机名和安全端口作为 URL 访问，使用管理员的证书进行身份验证，然后单击适当的 Administrators 链接。
注意
所有子系统都有一个 TLS 端口，用于管理员和代理服务。对这些服务的访问受基于证书的身份验证的限制。
HTML 管理界面比 Java 控制台更有限；主要管理功能是管理子系统用户。
TPS 仅允许操作管理 TPS 子系统的用户。但是，TPS 管理页面也可以列出令牌，并显示在 TPS 上执行的所有活动（包括通常隐藏的管理操作）。

图 2.2. TPS Admin Page

TPS Admin Page

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 证书都通过一个特定的在线提交表单进行处理，称为 profile。CA 有大约两个取消注册的证书配置文件，涵盖所有类型的证书 - 用户 TLS 证书、服务器 TLS 证书、日志和文件签名证书、电子邮件证书和每种类型的子系统证书。也可以有自定义配置集。

图 2.4. 证书管理器的端到端页面

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

2.5. 命令行界面

本节讨论命令行工具。

2.5.1. "pki" CLI

pki 命令行界面(CLI)使用 REST 界面提供对服务器上的各种服务的访问（请参阅 Red Hat Certificate System Planning, Installation, installation, installation, and Deployment Guide 中的 REST Interface 部分）。CLI 可以按如下方式调用： 
$ pki [CLI options] <command> [command parameters]
请注意，必须在命令前放置 CLI 选项，并在命令后面使用命令参数。
2.5.1.1. pki CLI 初始化
要第一次使用命令行界面，请指定新密码并使用以下命令： 
$ pki -c <password> client-init
这将在 ~/.dogtag/nssdb 目录中创建新客户端 NSS 数据库。在使用客户端 NSS 数据库的所有 CLI 操作中必须指定密码。或者，如果密码存储在文件中，您可以使用 -C 选项指定该文件。例如： 
$ pki -C password_file client-init
要将 CA 证书导入到客户端 NSS 数据库中，请参阅 Red Hat Certificate System Planning, Installation, and Deployment Guide 中的将 证书导入到 NSS 数据库 部分。
有些命令可能需要客户端证书身份验证。要将现有客户端证书及其密钥导入到客户端 NSS 数据库中，请指定 PKCS the 文件和密码，并执行以下命令：
执行以下命令，从 .p12 文件中提取 admin 客户端证书： 
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
按照 Red Hat Certificate System Planning, Installation, and Deployment Guide 中的 Managing Certificate/Key Crypto Token 部分所述，验证并导入 admin 客户端证书： 
$ PKICertImport -d ~/.dogtag/nssdb -n "nickname" -t ",," -a -i file.crt -u C
重要
在导入 CA admin 客户端证书前，请确保所有中间证书和 root CA 证书都已导入。
要将现有客户端证书及其密钥导入到客户端 NSS 数据库中，请指定 PKCS the 文件和密码，并执行以下命令： 
$ pki -c <password> pkcs12-import --pkcs12-file <file> --pkcs12-password <password>
使用以下命令验证客户端证书： 
certutil -V -u C -n "nickname" -d ~/.dogtag/nssdb
2.5.1.2. 使用 "pki" CLI
命令行界面支持以分级结构组织的多个命令。要列出顶级命令，请执行 pki 命令，无需任何其他命令或参数： 
$ pki
有些命令有子命令。要列出它们，请使用命令名称执行 pki，且不执行其他选项。例如： 
$ pki ca
$ pki ca-cert
要查看命令用法信息，请使用 --help 选项： 
$ pki --help
$ pki ca-cert-find --help
要查看手册页，请指定命令行 help 命令： 
$ pki help
$ pki help ca-cert-find
要执行不需要身份验证的命令，请指定命令及其参数（如果需要），例如： 
$ pki ca-cert-find
要执行需要客户端证书身份验证的命令，请指定证书别名、客户端 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 工具通过在日志条目上验证签名来验证审计日志的完整性。
Example: 
$ AuditVerify -d ~jsmith/auditVerifyDir -n Log Signing Certificate -a ~jsmith/auditVerifyDir/logListFile -P "" -v
示例使用 ~jsmith/auditVerifyDir NSS 数据库(-d)中的 Log Signing Certificate (-n)验证审计日志。要验证的日志列表(-a)位于 ~jsmith/auditVerifyDir/logListFile 文件中，用逗号分开和排序。前面带有证书和密钥数据库文件名的前缀(-P)为空。输出为详细(-v)。
详情请查看 AuditVerify(1) man page 或 第 16.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

Legacy。不要使用。

2.5.7. CMCSharedToken

CMCSharedToken 工具为共享 CMC 请求加密用户密码短语。例如： 
$ CMCSharedToken -d . -p myNSSPassword -s "shared_passphrase" -o cmcSharedTok2.b64 -n "subsystemCert cert-pki-tomcat"
共享密码短语(-s)使用名为 subsystemCert cert-pki-tomcat (-n) 的 NSS 数据库中的证书进行加密，并存储在 cmcSharedtok2.b64 文件(-o)中。默认安全令牌 internal （因为未指定 -h ），而 myNSSPassword 的令牌密码则用于访问令牌。
详情请查看 CMCSharedtoken(1) man page 和 第 7.2.1 节 “使用 CMCRequest吊销证书”。

2.5.8. CRMFPopClient

CRMFPopClient 工具是使用 NSS 数据库的证书请求消息格式(CRMF)客户端，并提供 Possession 的参与。
Example: 
$ 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
这个示例在当前目录(-d)中创建一个带有 cn=subject_name 主题 DN (-n) 的新 CSR，用于指定用于传输 kra.transport (-b)的证书，即 AES/CBC/PKCS5Padding key wrap 算法详细输出(-v) 生成的 CSR 被写入 /user_or_entity_database_directory/example.csr 文件(-o)。
有关详情、更多选项和其他示例，请参阅 CRMFPopClient --help 命令的输出以及 第 7.2.1 节 “使用 CMCRequest吊销证书”。

2.5.9. HttpClient

HttpClient 实用程序是用于提交 CMC 请求的 NSS 感知 HTTP 客户端。
Example: 
$ HttpClient request.cfg
注意
HttpClient 实用程序的所有参数都存储在 request.cfg 文件中。如需更多信息，请参阅 HttpClient --help 命令的输出。

2.5.10. OCSPClient

用于检查证书撤销状态的在线证书状态协议(OCSP)客户端。
Example: 
$ OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2
这个示例在端口 8080 (-p)上查询 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 密钥创建一个 PKCS10 格式的 CSR，可选在 HSM 上。
Example: 
$ PKCS10Client -d /etc/dirsrv/slapd-instance_name/ -p password -a rsa -l 2048 -o ~/ds.csr -n "CN=$HOSTNAME"
这个示例在 /etc/dirsrv/slapd-instance_name/ 目录中创建一个新的 RSA (-a)密钥，其 2048 位(-l )。 输出 CSR 存储在 ~/ds.cfg 文件(-o)中，证书 DN 为 CN=$HOSTNAME (-n)。
详情请查看 PKCS10Client(1) man page。

2.5.12. PrettyPrintCert

PrettyPrintCert 工具以人类可读格式显示证书的内容。
Example: 
$ PrettyPrintCert ascii_data.cert
此命令解析 ascii_data.cert 文件的输出，并以人类可读格式显示其内容。输出包括签名算法、exponent、modulus 和证书扩展等信息。
详情请查看 PrettyPrintCert(1) man page。

2.5.13. PrettyPrintCrl

PrettyPrintCrl 实用程序以人类可读格式显示 CRL 文件的内容。
Example: 
$ PrettyPrintCrl ascii_data.crl
此命令解析 ascii_data.crl 的输出，并以人类可读格式显示其内容。输出包括信息，如撤销签名算法、撤销的签发者以及撤销的证书列表及其原因。
详情请查看 PrettyPrintCrl(1) man page。

2.5.14. TokenInfo

TokenInfo 实用程序列出 NSS 数据库中的所有令牌。
Example: 
$ TokenInfo ./nssdb/
此命令列出在指定数据库目录中注册的所有令牌(HSM、软令牌等等)。
有关详情、更多选项和其他示例，请参阅 TokenInfo 命令的输出

2.5.15. tkstool

tkstool 工具与令牌密钥服务(TKS)子系统交互。
Example: 
$ tkstool -M -n new_master -d /var/lib/pki/pki-tomcat/alias -h token_name
此命令在 HSM 令牌_name上的 /var/lib/pki/pki-tomcat/alias NSS 数据库中创建一个名为 new_master (-n)的新主密钥(-M)
详情请查看 tkstool -H 命令的输出、更多选项和其他示例。

2.6. 企业安全客户端

企业安全 客户端是 Red Hat Certificate System 的一个工具，简化了管理智能卡。最终用户可以使用安全令牌(smart 卡)来存储用于应用的用户证书，如单点登录访问和客户端身份验证。最终用户签发令牌，其中包含签名、加密和其他加密功能所需的证书和密钥。
企业安全客户端是 证书系统的完整令牌管理系统的第三部分。两个子系统 - 令牌密钥服务(TKS)和令牌处理系统(TPS)- 用于处理与令牌相关的操作。企业安全客户端是 允许智能卡和用户访问令牌管理系统的接口。
注册令牌后，可将 Mozilla Firefox 和 Thunderbird 等应用程序配置为识别令牌并将其用于安全操作，如客户端身份验证和 S/MIME 邮件。企业安全客户端提供以下功能：
  • 支持 JavaCard 2.1 或更高版本卡和全局平台 2.01- 兼容智能卡，如 Safenet 的 330J 智能卡。
  • 支持 Gemalto TOP IM FIPS CY2 令牌，包括智能卡和 GemPCKey USB 格式工厂键。
  • 支持 SafeNet Smart Card 650 (SC650)。
  • 注册安全令牌，以便 TPS 识别它们。
  • 维护安全令牌，如使用 TPS 重新注册令牌。
  • 提供有关被管理令牌或令牌的当前状态的信息。
  • 支持服务器端密钥生成，以便在令牌丢失时在单独的令牌上存档并恢复密钥。
企业安全客户端是最终用户在智能卡或令牌上注册和管理密钥和证书的客户端。这是证书系统令牌管理系统中的最终组件，带有令牌处理系统(TPS)和令牌密钥服务(TKS)。
企业安全客户端提供令牌管理系统的用户界面。最终用户可以发布包含签名、加密和其他加密功能所需的证书和密钥的安全令牌。要使用令牌，TPS 必须能够识别并与它们通信。企业安全客户端是要注册的令牌的方法。
企业安全客户端通过 SSL/TLS HTTP 通道与 TPS 的后端通信。它基于用户界面的可扩展 Mozilla XULRunner 框架，同时为简单的基于 HTML 的 UI 保留传统的 Web 浏览器容器。
正确注册令牌后，可将 Web 浏览器配置为识别令牌并将其用于安全操作。企业安全客户端提供以下功能：
  • 允许用户注册安全令牌，以便被 TPS 识别。
  • 允许用户维护安全令牌。例如，企业安全客户端使得可以使用 TPS 重新注册令牌。
  • 通过默认和自定义令牌配置集提供对多种不同类型的令牌的支持。默认情况下，TPS 可以自动注册用户密钥、设备密钥和安全密钥；可以添加额外的配置文件，以便用于不同用途的令牌（通过令牌 CUID 等属性识别）可以根据适当的配置集自动注册。
  • 提供有关被管理令牌的当前状态的信息。

部分 II. 设置证书服务

第 3 章 为颁发证书（证书配置文件）进行规则

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

3.1. 关于证书配置文件

证书配置文件定义了与发布特定类型的证书相关的所有内容，包括身份验证方法、授权方法、默认证书内容、内容值的限制，以及证书配置文件的输入和输出内容。注册和续订请求被提交到证书配置文件，然后受到该证书配置文件中设置的默认值和约束。这些限制是否通过与证书配置文件关联的输入表单提交，还是通过其他方式提交。从证书配置文件请求发布的证书包含默认值所需的内容以及默认参数所需的信息。约束提供证书中允许的内容的规则。
有关使用和自定义证书配置文件的详情，请参考 第 3.2 节 “设置证书配置文件”。
证书系统包含一组默认配置文件。虽然创建默认配置集来满足大多数部署，但每个部署都可以添加自己的新证书配置文件或修改现有的配置文件。
  • 身份验证。每个认证配置文件中都可以指定身份验证方法。
  • 授权。每个认证配置文件中都可以指定一个授权方法。
  • 配置集输入。配置集输入是请求证书时提交到 CA 的参数和值。配置集输入包括证书请求的公钥，以及证书的最终实体所请求的证书主题名称。
  • 配置集输出。配置集输出是参数和值，用于指定向最终实体提供证书的格式。当请求成功时，配置集输出是 CMC 响应，其中包含 PKCS the7 证书链。
  • 证书内容。每个证书定义内容信息，如为其分配的实体名称（主题名称）、其签名算法及其有效期周期。证书中包含的内容在 X.509 标准中定义。使用 X509 标准的版本 3 时，证书也可以包含扩展。有关证书扩展的详情，请参考 ???。
    有关证书配置文件的所有信息都在配置文件配置文件中配置文件策略的 设置 条目中定义。当同时请求多个证书时，可以在配置文件策略中定义多个设置条目来满足每个证书的需求。每个策略集由多个策略规则组成，每个策略规则描述了证书内容中的一个字段。策略规则可包括以下部分：
    • 配置集默认值。这些是预定义的参数和允许的值，用于证书中包含的信息。配置集默认包括证书的有效性周期，以及每个发布的证书类型的证书扩展。
    • 配置集限制。用于发布证书的约束设置规则或策略。另一方面，配置集限制包括要求证书主题名称至少有一个 CN 组件的规则，将证书的有效性设置为最多 360 天，来定义续订允许的宽限期，或要求 主题altname 扩展始终设为 true。

3.1.1. Enrollment Profile

表 11.1 中更详细地列出了定义输入、输出和策略集的每个配置集的参数。Red Hat Certificate System Planning, Installation and Deployment Guide 中的 profile 配置文件参数。
配置集通常包含输入、策略集和输出，如 例 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
最后 - 最大配置块是为配置集设置的策略。Policy set 列出应用于最终证书的所有设置，如其有效期、其续订设置以及证书可用于的操作。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. 证书扩展：默认和约束

扩展配置附加信息，以包含在证书或规则中有关如何使用证书。这些扩展可以在证书请求中指定，或者从配置集默认定义中获取，然后根据约束强制执行。
如果请求中没有设置证书扩展，则通过添加 默认值，在配置集中添加或识别证书扩展。例如，基本限制扩展标识证书是否为 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
此外，扩展也可以为证书请求设置所需的值，名为 约束。如果请求的内容与集合约束不匹配，则拒绝请求。约束通常与扩展默认对应，但并不总是始终对应。例如： 
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 节 “用户 Supplied 扩展默认” 所述。

3.1.3. 输入和输出

输入设置必须提交才能接收证书的信息。这可以是请求者信息、特定格式的证书请求或组织信息。
配置集中配置的输出定义发布的证书的格式。
在证书系统中，通过 注册表单 访问配置文件，该表单可通过终端实体页面访问。（即使客户端（如 TPS ）通过这些表单提交注册请求。） 输入然后对应于注册表单中的字段。输出对应于证书检索页面中包含的信息。

3.2. 设置证书配置文件

在证书系统中，您可以添加、删除和修改注册配置文件：
  • 使用 PKI 命令行界面
  • 使用基于 Java 的管理控制台
本节提供有关每种方法的信息。

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

本节描述了如何使用 pki 工具管理证书配置文件。详情请查看 pki-ca-profile(1) man page。
注意
建议使用 raw 格式。有关配置文件的每个属性和字段的详情，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的在文件系统中直接创建和编辑证书配置文件一节。
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 管理员可以以原始格式编辑证书配置文件，而无需手动下载配置文件。
例如，编辑 caCMCECserverCert 配置集： 
# pki -c password -n caadmin ca-profile-edit caCMCECserverCert
此命令以 raw 格式自动下载配置文件配置，并在 VI 编辑器中打开它。当您关闭编辑器时，配置集配置会在服务器上更新。
编辑配置集后您不需要重启 CA。
重要
在编辑配置集前，请禁用配置集。详情请查看 第 3.2.1.1 节 “启用和禁用证书配置文件”。

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

例如，要编辑 caCMCserverCert 配置集以接受多个用户提供的扩展：
  1. 禁用配置集作为 CA 代理： 
    # pki -c password -n caagemt ca-profile-disable caCMCserverCert
  2. 以 CA 管理员身份编辑配置集：
    1. 在 VI 编辑器中下载并打开配置集： 
      # pki -c password -n caadmin ca-profile-edit caCMCserverCert
    2. 更新配置以接受扩展。详情请查看 ???。
  3. 启用配置集作为 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 的管理控制台管理证书注册配置文件

重要
pkiconsole 已被弃用。
3.2.2.1. 通过 CA 控制台创建证书配置文件
为安全起见，证书系统会强制分离现有证书配置文件，只要代理允许后管理员才能对其进行编辑。要添加新证书配置文件或修改现有证书配置文件，请以管理员身份执行以下步骤：
  1. 登录证书系统 CA 子系统控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，选择 Certificate Manager，然后选择 Certificate Profiles。
    Certificate Profile Instances Management 选项卡（列出配置的证书配置文件）将打开。
  3. 若要创建新证书配置文件，请单击 Add。
    在 Select Certificate Profile Plugin Implementation 窗口中，选择创建配置集的证书类型。
  4. 在 Certificate Profile Instance Editor 中填写配置文件信息。
    • 证书配置文件实例 ID.这是系统用来识别配置文件的 ID。
    • 证书配置文件名称.这是配置文件的用户友好的名称。
    • 证书配置文件描述.
    • 最终用户证书配置文件.这会设置请求是否必须通过配置文件的输入表单进行。这通常设为 true。把它设置为 false，允许通过证书管理器的证书配置文件框架处理签名的请求，而不是通过证书配置文件的输入页面进行处理。
    • 证书配置文件身份验证.这会设置身份验证方法。通过为身份验证实例提供实例 ID 来设置自动身份验证。如果此字段为空，则身份验证方法是代理批准的注册；请求将提交到代理服务接口的请求队列中。
      除非是 TMS 子系统，否则管理员必须选择以下身份验证插件之一：
      • CMCAuth ：当 CA 代理必须批准并提交注册请求时，使用此插件。
      • CMCUserSignedAuth ：使用此插件使非代理用户能够注册自己的证书。
  5. 点确定。插件编辑器关闭，新的配置集列在 profile 选项卡中。
  6. 为新配置集配置策略、输入和输出。从列表中选择新配置集，然后单击 Edit/View。
  7. 在证书配置文件 规则编辑器 窗口的 Policies 选项卡中设置策略。Policies 选项卡列出了已为配置集类型默认设置的策略。
    1. 要添加策略，请点击 Add。
    2. 从 Default 字段中选择默认值，在 Constraints 字段中选择与该策略关联的约束，然后单击 OK。
    3. 填写策略设置 ID。在发布双密钥对时，单独的策略集会定义与每个证书关联的策略。然后，填写证书配置文件策略 ID，证书配置文件策略的名称或标识符。
    4. 在 Defaults 和 Constraints 选项卡中配置任何参数。
      Default 定义填充证书请求的属性，后者决定证书的内容。这些可以是扩展、有效期或证书中包含的其他字段。约束 定义默认值的有效值。
      如需了解每个默认或约束的详情，请查看 第 B.1 节 “默认参考” 和 第 B.2 节 “约束参考”。
    要修改现有策略，请选择策略，然后单击 Edit。然后编辑该策略的默认和限制。
    要删除策略，请选择策略，然后单击 Delete。
  8. 在证书配置文件 编辑器 窗口的 Inputs 选项卡中设置输入。配置集可以有多个输入类型。
    注意
    除非为 TMS 子系统配置配置文件，否则请选择 cmcCertReqInput，并通过选择它们并单击 Delete 按钮来删除其他配置集。
    1. 要添加输入，请点击 Add。
    2. 从列表中选择输入，然后单击确定。如需了解默认输入的详情，请查看 第 A.1 节 “输入参考”。
    3. 此时会打开 New Certificate Profile Editor 窗口。设置输入 ID，然后单击 OK。
    可以添加和删除输入。可以选择为输入选择编辑，但因为输入没有参数或其他设置，因此无需配置。
    要删除输入，请选择输入，然后单击 Delete。
  9. 在证书配置文件 规则编辑器 窗口的 Outputs 选项卡中设置 输出。
    必须为使用自动验证方法的任何证书配置文件设置输出；不需要为使用代理验证的任何证书配置文件设置输出。默认情况下，所有配置集都会设置证书输出类型，并自动添加到自定义配置集中。
    除非为 TMS 子系统配置配置文件，否则仅选择证书 输出。
    可以添加和删除输出。可以为输出选择编辑，但因为输出没有参数或其他设置，因此无需配置。
    1. 要添加输出，请单击 Add。
    2. 从列表中选择输出，然后单击确定。
    3. 为输出指定名称或标识符，然后单击 OK。
      此输出将在输出标签页中列出。您可以编辑它，以便为此输出中的参数提供值。
    若要删除输出，可从列表中选择输出，然后单击 Delete。
  10. 重启 CA 以应用新配置集。 
    systemctl restart pki-tomcatd-nuxwdog@instance_name.service
  11. 将配置集作为管理员创建后，CA 代理必须批准代理服务页面中的配置集来启用配置集。
    1. 打开 CA 的服务页面。 
      https://server.example.com:8443/ca/services
    2. 单击 Manage Certificate Profiles 链接。本页列出了管理员（活跃和不活跃）设置的所有证书配置文件。
    3. 单击要批准的证书配置文件的名称。
    4. 在页面底部，单击 Enable 按钮。
注意
如果此配置文件与 TPS 一起使用，则必须配置 TPS 来识别配置文件类型。这是 11.1.4 中。红帽证书系统规划、安装和部署指南中的管理智能卡 CA 配置文件。
配置文件的授权方法只能使用命令行添加到配置集，如 Red Hat Certificate System Planning, Installation and Deployment Guide 中的直接创建和编辑证书配置文件一节中所述。
3.2.2.2. 在控制台中编辑证书配置文件
修改现有证书配置文件：
  1. 登录到代理服务页面并禁用配置集。
    代理启用证书配置文件后，该证书配置文件会在证书配置文件 实例管理 选项卡中被标记为启用，并且无法通过控制台以任何方式编辑证书配置文件。
  2. 登录证书系统 CA 子系统控制台。 
    pkiconsole https://server.example.com:8443/ca
  3. 在 Configuration 选项卡中，选择 Certificate Manager，然后选择 Certificate Profiles。
  4. 选择证书配置文件，然后单击 Edit/View。
  5. 此时会出现 Certificate Profile Rule Editor 窗口。对默认值、约束、输入或输出的任何更改。
    注意
    无法修改配置集实例 ID。
    如有必要，通过拔出窗口其中一个角来放大窗口。
  6. 重启 CA 以应用更改。
  7. 在代理服务页面中，重新启用配置集。
注意
删除未被代理批准的任何证书配置文件。证书配置文件实例管理选项卡 中出现的任何证书配置文件 也会出现在代理服务界面中。如果已经启用配置集，则必须禁用代理，然后才能从配置集列表中删除它。

3.2.3. 列出证书注册配置文件

安装证书系统 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。证书系统在创建或应用 Subject Key Identifier Default 之前处理 Key Default 中的密钥约束，因此如果密钥尚未处理，在主题名称中设置密钥会失败。
例如，object-signing 配置集可能会定义这两个默认值： 
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)前列出密钥默认(p11)。 
policyset.set1.list=p1,p2,p11,p3,p4,p5,p6,p7,p8,p9,p10

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

本节讨论如何为证书续订设置配置文件。有关如何续订证书的详情，请参考 第 5.4 节 “续订证书”。
允许续订的配置集通常由 renewal GracePeriodConstraint 条目组成。例如： 
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. 使用相同密钥续订

允许为续订提交同一密钥的配置集，在 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 支持的任何公钥算法发布的证书。例如，ECC 签名证书可以同时为 ECC 和 RSA 证书请求签名，只要 CA 支持 ECC 和 RSA 算法。RSA 签名证书可以使用 EC 密钥为 PKCS11410 请求签名，但如果 ECC 模块没有可用于 CA 验证 CRMF 概念验证(POP)，则可能无法使用 ECC 模块为 CRMF 证书签名。
ECC 和 RSA 是公钥加密和解密算法。公钥算法都支持不同的密码套件，用于加密和解密数据的算法。CA 签名证书的功能部分就是使用其其中一个支持的密码套件发布和签署证书。
每个配置集可以定义 CA 应该用来为通过该配置集处理的证书签名的密码套件。如果没有设置签名算法，则配置集会使用任何默认签名算法。

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

  1. 打开 CA 控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，展开 证书管理器 树。
  3. 在 General Settings 选项卡中，在 Algorithm 下拉菜单中选择要使用的算法。
注意
pkiconsole 已被弃用。

3.5.2. 在配置文件中设置签名算法默认值

每个配置集都定义了 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：
注意
在编辑配置集前，必须首先由代理禁用它。
  1. 打开 CA 控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，展开 证书管理器 树。
  3. 点 Certificate Profiles 项。
  4. 点 Policies 选项卡。
  5. 选择 Signing Alg 策略，然后单击 Edit 按钮。
  6. 要设置默认签名算法，请在 Defaults 选项卡中设置值。如果设置为 -，则配置文件将使用 CA 的默认值。
  7. 要设置可在证书请求中可接受的允许签名算法列表，请打开 Constraints 选项卡，并在 Value 字段中为 signingAlgsAllowed 设置算法列表。
    约束的可能值列在 第 B.2.10 节 “签名算法约束” 中。
注意
pkiconsole 已被弃用。

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

证书的主题名称是 可分辨名称(DN)，包含识别签发证书的实体的信息。此主题名称可以从标准 LDAP 目录组件构建，如通用名称和组织单元。这些组件在 X.500 中定义。除了 - 甚至替换主题名称外，证书还可以具有 主题替代名称，这是为包含 X.500 中未定义的附加信息的证书设置的扩展类型。
可以自定义主题名称和主题备用名称的命名组件。
重要
如果主题名称为空，则必须存在 Subject Alternative Name 扩展并标记为 critical。

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 为 cn=John Smith，则证书将通过主题 DN cn=John Smith,DC=example, DC=com 签发。如果请求位于 中，但 UID 为 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. 将 LDAP 目录属性值和其他信息插入到主题 Alt 名称

可以使用 Subject Alt Name Extension Default 配置中的匹配变量，将来自 LDAP 目录或请求者提交的信息插入到证书的主题备用名称中。此默认设置信息的类型（格式），然后设置用于检索信息的匹配模式(variable)。例如： 
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
这会插入请求者的电子邮件作为主题 alt 名称中的第一个 CN 组件。要使用其他组件，请按顺序递增 Type_、Pattern_ 和 Enable_ 值，如 Type_1。
配置主题 alt 名称也会在 第 B.1.23 节 “主题备用名称扩展默认值” 中详细介绍。
将 LDAP 组件插入到证书的主题 alt 名称中：
  1. 插入 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. 保存新的插件实例。
    注意
    pkiconsole 已被弃用。
    有关设置 CMC 共享令牌的详情，请参考 第 10.4.2 节 “设置 CMC 共享 Secret”。
  2. ldapStringAttributes 参数指示身份验证插件从用户的 LDAP 条目读取 mail 属性的值，并将该值放在证书请求中。当值位于请求中时，证书配置文件策略可以设置为插入扩展值的值。
    第 B.2.11 节 “主题名称约束” 和 第 B.1.27 节 “主题名称默认” 中涵盖了 dnpattern 参数的格式。
  3. 要让 CA 在证书扩展中插入 LDAP 属性值，请编辑配置文件的配置文件，并为扩展插入策略设置参数。例如，要在 caFullCMCSharedTokenCert 配置集中的 Subject Alternative Name 扩展中插入 mail 属性值，请更改以下代码： 
    policyset.setID.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$
    有关编辑配置集的详情，请参考 第 3.2.1.3 节 “以 Raw 格式编辑证书配置文件”。
  4. 重启 CA。 
    systemctl restart pki-tomcatd-nuxwdog@instance_name.service
在本例中，通过 caFullCMCSharedTokenCert 配置集注册表单提交的证书将添加 Subject Alternative Name 扩展，并带有请求者 的邮件 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 电子邮件(mail)属性值。
$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.requestor_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 的通用名称(CN)属性进行验证，这已在 RFC 2818 中被弃用。相反，这些应用程序和库在证书请求中使用 dNSName Subject Alternative Name (SAN)值。
只有 CN 根据 RFC 1034 第 3.5 节，并且具有多个组件时，才会复制 CN。此外，还会保留现有的 SAN 值。例如，基于 CN 的 dNSName 值附加到现有的 SAN 中。
要将证书系统配置为使用 SAN 扩展中的 CN 属性，请编辑用于发布证书的证书配置文件。例如：
  1. 禁用配置集： 
    # pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-disable profile_name
  2. 编辑配置集： 
    # pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-edit profile_name
    1. 使用配置集的唯一设置号添加以下配置。例如： 
      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 作为集合号。
    2. 将新策略集号附加到 policyset.userCertSet.list 参数。例如： 
      policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9,12
    3. 保存配置集。
  3. 启用配置集： 
    # pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-enable profile_name
注意
所有默认服务器配置文件都包含 commonNameToSANDefaultImpl 默认。

3.7.4. 接受 CSR 的 SAN 扩展

在某些环境中，管理员希望在证书签名请求(CSR)中指定主题备用名称(SAN)扩展。
3.7.4.1. 配置配置文件以从 CSR 中检索 SAN
要允许从 CSR 检索 SAN，请使用用户扩展默认值。详情请查看 第 B.1.32 节 “用户 Supplied 扩展默认”。
注意
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.5.2 节 “CMC 注册过程” 中描述的步骤完成 CMC 注册。

第 4 章 设置 Key Archival 和恢复

有关密钥归档和恢复的更多信息，请参阅 Red Hat Certificate System 规划 、安装和部署指南中的归档、恢复和轮转密钥 部分。
本章解释了如何设置密钥恢复授权(KRA)，之前称为 数据恢复管理器(DRM)，以归档私钥并恢复加密数据的归档密钥。
注意
本章仅讨论通过客户端生成密钥归档密钥。服务器端密钥生成和存档（无论是通过 TPS 启动还是通过 CA 的最终用户实体门户启动）。
有关智能卡密钥恢复的详情，请参考 第 6.11 节 “设置服务器端密钥生成”。
有关 CA 的 EE 门户提供的服务器端密钥生成的详情，请参考 第 5.2.2 节 “使用服务器端密钥生成 CSR”。
注意
Gemalto SafeNet LunaSA 仅支持 CKE 中的 PKI 私钥提取 - 密钥导出模型，且仅在非FIPS 模式中。FIPS 模式中的 LunaSA Cloning 模型和 CKE 模型不支持 PKI 私钥提取。
安装 KRA 后，它会加入安全域，并与 CA 配对。目前，它被配置为归档和恢复私钥。但是，如果 KRA 证书由外部 CA 发布，而不是安全域中的一个 CA，则必须手动设置密钥归档和恢复过程。
如需更多信息，请参阅 Red Hat Certificate System 规划、安装和部署指南中的 手动设置密钥存档 部分。
注意
在克隆的环境中，需要手动设置密钥归档和恢复。如需更多信息，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的 Updating CA-KRA Connector Information after Cloning 部分。

4.1. 在控制台中配置代理应用密钥恢复

注意
虽然可在控制台中配置密钥恢复代理 数量，但要使用的 组 只能在 CS.cfg 文件中设置。控制台默认使用 密钥恢复授权代理组。
  1. 打开 KRA 的控制台。例如： 
    pkiconsole https://server.example.com:8443/kra
  2. 单击左侧导航树中的 Key Recovery Authority 链接。
  3. 在 所需的 Agents 字段中输入用于批准密钥恢复的代理数量。
注意
有关如何在 CS.cfg 文件中配置代理批准密钥恢复的更多信息，请参阅 Red Hat Certificate System 规划、安装和部署指南中的 命令行配置 密钥恢复部分。

4.2. 测试密钥 Archival 和恢复设置

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

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

最终用户请求并使用证书。虽然证书注册和续订是不仅限于管理员的操作，但了解注册和续订流程可更轻松地管理和创建适当的证书配置文件，如 第 3.2 节 “设置证书配置文件” 所述，并为每个证书类型使用适合的身份验证方法( 第 10 章 注册证书的身份验证)。
本章讨论请求、接收和更新证书供外部证书系统使用。有关请求和更新证书系统子系统证书的详情，请参考 第 17 章 管理子系统证书。

5.1. 关于注册和续订证书

注册 是请求和接收证书的过程。注册过程的机制根据证书类型、生成密钥对的方法以及生成和批准证书本身的方法稍有不同。任何方法、证书注册在高级别上都有相同的基本步骤：
  1. 生成证书请求(CSR)。
  2. 证书请求提交到 CA。
  3. 通过验证请求它的实体并验证请求，并确认请求满足用于提交它的证书配置文件规则。
  4. 请求已批准。
  5. 请求方检索新证书。
当证书达到其有效期结束时，可以续订。

5.2. 创建证书签名请求

传统上，以下方法用于生成证书请求(CSR)：
  • 使用命令行工具生成 CSR
  • 在支持浏览器中生成 CSR
  • 在应用程序内生成 CSR，如服务器的安装程序
其中一些方法支持直接提交 CSR，而有些方法则不支持。
从 RHCS 9.7 开始，支持通过删除较新版本的浏览器中的密钥生成支持（如 Firefox v69 和 up）来克服出现的不协调。因此，在本节中，我们将不讨论对密钥生成的浏览器支持。虽然无法认为这些浏览器的旧版本不应象旧的 RHCS 文档那样继续正常工作。
从应用程序生成的 CSR 通常采用 PKCS11410 的形式。如果它们被正确生成，则 RHCS 应该支持它们。
在以下小节中，我们将采用 RHCS 支持的以下方法：
  • 命令行工具
  • 服务器端密钥生成

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

Red Hat Certificate System 支持使用以下工具来创建 CSR：
  • certutil ：支持创建 PKCS the10 请求。
  • PKCS10Client ：支持创建 PKCS the10 请求。
  • CRMFPopClient ：支持创建 CRMF 请求。
  • pki client-cert-request ：支持 PKCS the10 和 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：
  1. 切换到正在请求证书的用户或实体的证书数据库目录，例如： 
    $ cd /user_or_entity_database_directory/
  2. 创建二进制 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。
  3. 将创建的二进制格式 CSR 转换为 PEM 格式： 
    $ BtoA /user_or_entity_database_directory/request-bin.csr /user_or_entity_database_directory/request.csr
  4. （可选）验证 CSR 文件是否正确： 
    $ cat /user_or_entity_database_directory/request.csr

		MIICbTCCAVUCAQAwKDEQMA4GA1UEChMHRXhhbXBsZTEUMBIGA1UEAxMLZXhhbXBs
		...
    这是一个 PKCS the10 PEM 证书请求。
5.2.1.1.2. 使用 certutil 创建带有用户定义的扩展的 CSR
以下流程描述了如何使用 certutil 工具创建带有用户定义的扩展的 CSR。
请注意，注册请求受 CA 定义的注册配置集的限制。请参阅 ???。
  1. 切换到正在请求证书的用户或实体的证书数据库目录，例如： 
    $ cd /user_or_entity_database_directory/
  2. 使用用户定义的密钥用法扩展创建 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。
  3. （可选）验证 CSR 文件是否正确： 
    $ cat /user_or_entity_database_directory/request.csr
		Certificate request generated by Netscape certutil
		Phone: (not specified)

		Common Name: user 4-2-1-2
		Email: (not specified)
		Organization: (not specified)
		State: (not specified)
		Country: (not specified)
    这是一个 PKCS the10 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：
  1. 切换到正在请求证书的用户或实体的证书数据库目录，例如： 
    $ cd /user_or_entity_database_directory/
  2. 创建 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。
  3. （可选）验证 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 配置集处理。
  1. 切换到正在请求证书的用户或实体的证书数据库目录，例如： 
    $ cd /user_or_entity_database_directory/
  2. 创建 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。
  3. （可选）验证 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 密钥对和带有 key archive 选项的 CSR：
  1. 切换到正在请求证书的用户或实体的证书数据库目录，例如： 
    $ cd /user_or_entity_database_directory/
  2. 检索 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
  3. 导出 KRA 传输证书： 
    $ pki ca-cert-show 0x7 --output kra.transport
  4. 创建 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。
  5. （可选）验证 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 配置集处理。
  1. 切换到正在请求证书的用户或实体的证书数据库目录，例如： 
    $ cd /user_or_entity_database_directory/
  2. 检索 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
  3. 导出 KRA 传输证书： 
    $ pki ca-cert-show 0x7 --output kra.transport
  4. 创建 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 命令的输出。
  5. （可选）验证 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。可以同时生成 PKCS11410 或 CRMF 请求。
生成 PKCS the10 请求的示例： 
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 和 Chrome）都删除了生成 PKI 密钥的功能，并支持密钥归档的 CRMF。在 RHEL 上，如 CRMFPopClient （请参阅 CRMFPopClient --help）或 pki （请参阅 pki client-cert-request --help）等 CLI 可以用作临时解决方案。
由于引入令牌密钥管理系统(TMS)，服务器端密钥注册时间已延长，其中密钥可以在 KRA 上生成，而不是本地在智能卡上生成。Red Hat Certificate System 现在采用类似的机制来解决浏览器 keygen 出现问题。密钥在服务器上生成（特别是，在 KRA 上），然后安全地将密钥传输给 PKCS the 中的客户端。
注意
强烈建议您仅将服务器端密钥机制用于加密密钥。
5.2.2.1. 功能高
  • 证书请求密钥在 KRA 上生成（注意：必须安装 KRA 才能使用 CA）
  • 配置集默认插件 serverKeygenUserKeyDefaultImpl 提供了启用或禁用密钥归档（例如，enableArchival 参数）的选择。
  • 支持 RSA 和 EC 密钥
  • 支持手动（代理）批准和自动批准（例如，基于密码的目录）
5.2.2.2. 使用服务器端密钥注册证书
默认的 Sever-Side Keygen 注册配置集可在 EE 页面中找到，位于 List Certificate Profiles 选项卡下：
使用服务器端密钥生成手动用户双用途证书注册

图 5.1. 需要代理手动批准的服务器-Side Keygen Enrollment

需要代理手动批准的服务器-Side Keygen Enrollment
使用服务器端密钥生成目录验证的用户双用途证书注册

图 5.2. 成功 LDAP uid/pwd 身份验证时自动批准服务器-Side Keygen Enrollment

成功 LDAP uid/pwd 身份验证时自动批准服务器-Side Keygen Enrollment
无论请求是如何批准的，服务器端密钥注册机制都需要最终用户输入 PKCS the package 的密码，该软件包将包含发布的证书以及服务器生成的加密私钥。
重要
用户不应与任何人共享密码。甚至不是 CA 或 KRA 代理。
当注册请求被批准后，将生成 PKCS the 软件包，
  • 如果进行手动批准，PKKKKKM 文件将返回到批准请求的 CA 代理；然后代理应该将 PKCS the 文件转发到用户。
  • 如果进行自动批准，PKKKKKKT 将会返回到提交请求的用户

图 5.3. 代理手动批准的注册

代理手动批准的注册
收到 PKCS the 文件后，用户可以使用 CLI （如 pkcs12util ）将此文件导入到每个应用程序自己的用户内部证书/密钥数据库中。例如，用户的 Firefox nss 数据库。
5.2.2.3. 密钥恢复
如果在证书注册配置文件中将 enableArchival 参数设置为 true，则在 Server-Side Keygen 注册时会存档私钥。然后，授权的 KRA 代理可以恢复归档的私钥。
5.2.2.4. 其它信息
5.2.2.4.1. KRA 请求记录
注意
由于此机制的性质，如果配置集中的 enableArchival 参数设置为 true，则每个 Server-Side keygen 请求有两个 KRA 请求记录：
  • 一个请求类型 asymkeyGenRequest
    此请求类型不能使用 KRA 代理页面上的 List Requests 来过滤；您可以选择 Show All Requests 来查看列出它们。
  • 一个请求类型 恢复
5.2.2.4.2. 审计记录
如果启用了，可以观察一些审计记录：
CA
  • 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. 请求和接收证书

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

5.3.1. 通过最终用户页面请求和接收证书

在 CA End Entity Portal (i.e. https://host.domain:port114 /ca/ee/ca)中，最终实体可以使用 Enrollment/Renewal 选项卡下的 HTML 注册表单来提交其证书请求(CSR)，请参阅 第 5.2 节 “创建证书签名请求”。
本节假设您有 Base64 编码格式的 CSR，包括标记行 -----BEGIN NEW CERTIFICATE REQUEST----- 和 -----END NEW CERTIFICATE REQUEST-----。
许多默认注册配置集都提供了一个证书请求文本框，其中可粘贴到 Base64 编码 CSR 中，以及 Certificate Request Type 选择下拉列表。
在证书注册表单中，输入所需信息。
标准要求如下：
  • 证书请求类型。这是 PKCS the10 或 CRMF。通过子系统管理控制台创建的证书请求是 PKCS04710 ；那些通过 certutil 工具创建的证书请求通常是 PKCS the10。
  • 证书请求.粘贴 base-64 编码 blob，包括 -----BEGIN NEW CERTIFICATE REQUEST----- 和 -----END NEW CERTIFICATE REQUEST----- 标记行。
  • 请求者名称。这是请求证书的个人的常见名称。
  • 请求者电子邮件.这是请求者的电子邮件地址。在签发证书时，代理或 CA 系统将使用此地址联系请求者。例如： jdoe@someCompany.com。
  • 请求者电话.这是请求者的联系人电话号码。
提交的请求排队以进行代理批准。代理需要处理和批准证书请求。
注意
有些注册配置文件可能允许自动批准，如使用 Red Hat Certificate System 提供的 LDAP uid/pwd 身份验证方法。通过这些配置集注册在下一部分中不需要手动批准。有关支持的批准方法，请参阅 第 10 章 注册证书的身份验证。
如果是手动批准，则证书被批准并生成后，您可以检索证书。
  1. 打开 Certificate Manager 端到端页面，例如： 
    https://server.example.com:8443/ca/ee/ca
  2. 点 Retrieval 选项卡。
  3. 填写提交证书请求时创建的请求 ID 号，然后单击 Submit。
  4. 下一页显示证书请求的状态。如果状态 完成，则有指向证书的链接。点 Issued certificate 链接。
  5. 新证书信息以用户为print 格式显示，采用 base-64 编码格式，并且以 PKCS the7 格式显示。
    可以通过此页面执行以下操作：
    • 要在服务器或其他应用程序上安装此证书，请在 Server 部分向下滚动到安装此证书，其中包含 base-64 编码证书。
  6. 将 base-64 编码证书（包括 -----BEGIN CERTIFICATE----- 和 -----END CERTIFICATE----- 标记行）复制到文本文件。保存文本文件，并使用它来将证书的副本存储在私钥所在的实体的安全模块中。请参阅 第 15.3.2.1 节 “创建用户”。

5.4. 续订证书

本节讨论如何续订证书。有关如何设置证书续订的详情，请参考 第 3.4 节 “配置配置集以启用续订”。
续订证书包括使用与原始证书相同的目的重新生成证书。通常，有两种类型的续订：
  • 相同的密钥续订 取证书的原始密钥、配置集和请求，并使用相同密钥重新创建具有新有效期和过期日期的新证书。这可以通过以下任一方法完成：
    • 通过原始配置文件重新提交原始证书请求(CSR)，或者
    • 使用 certutil 等支持工具使用原始密钥重新生成 CSR
  • 重新加密证书需要使用相同的信息重新生成证书请求，以便生成新的密钥对。然后，CSR 通过原始配置集提交。

5.4.1. 相同的密钥续订

5.4.1.1. 重新使用 CSR
最终实体门户上有三种用于同一密钥续订的批准方法。
  • agent-approved 方法需要提交要续订的证书的序列号；此方法需要 CA 代理的批准。
  • 基于目录的续订需要提交要续订的证书的序列号，并且 CA 从其当前证书目录条目中提取信息。如果 ldap uid/pwd 成功验证，则会自动批准该证书。
  • 基于证书的续订使用浏览器数据库中的证书进行身份验证，并使用相同的证书重新发布。
5.4.1.1.1. agent-Approved 或基于目录的续订
有时，证书续订请求必须手动批准，可以是 CA 代理或为用户目录提供登录信息。
  1. 打开签发证书的 CA 的最终服务页面（或克隆）。 
    https://server.example.com:8443/ca/ee/ca
  2. 单击要使用的续订表单的名称。
  3. 输入要续订的证书的序列号。这可以采用十进制形式或十六进制形式。
  4. 点续订按钮。
  5. 请求已提交。对于基于目录的续订，会自动返回更新的证书。否则，续订请求将由代理批准。
5.4.1.1.2. 基于证书的续订
有些用户证书直接存储在您的浏览器中，因此某些续订表单将只检查浏览器证书数据库是否有要续订的证书。如果证书可以被续订，则 CA 会自动批准并重新发布证书。
重要
如果正在续订的证书已经过期，那么它可能无法用于基于证书的续订。浏览器客户端可能会禁止任何使用过期证书的 SSL 客户端身份验证。
在这种情况下，必须使用其它续订方法之一续订证书。
  1. 打开签发证书的 CA 的最终服务页面（或克隆）。 
    https://server.example.com:8443/ca/ee/ca
  2. 单击要使用的续订表单的名称。
  3. 没有输入字段，因此点 续订 按钮。
  4. 出现提示时，选择要更新的证书。
  5. 请求被提交，并自动返回更新的证书。
5.4.1.2. 使用同一密钥生成 CSR 续订
有时，原始 CSR 可能不可用。certutil 工具允许一个使用相同的密钥重新生成 CSR，只要密钥对位于 NSS 数据库中。这可以通过执行以下操作来实现：
  1. 在 NSS db 中查找对应的密钥 ID： 
    Certutil -d <nssdb dir> -K
  2. 使用特定密钥生成 CSR： 
    Certutil -d <nssdb dir> -R -k <key id> -s <subject DN> -o <CSR output file>
或者，如果密钥与 NSS db 中的证书关联，也可以使用 keyid ：
  • 使用现有 nickname 生成 CSR： 
    Certutil -d <nssdb dir> -R -k <nickname> -s <subject DN> -o <CSR output file>

5.4.2. 通过密钥证书续订

因为 重新密钥 续订基本上会生成一个与旧证书相同的信息的新 CSR，只需遵循 第 5.2 节 “创建证书签名请求” 中描述的任何一种方法。请注意，输入与旧证书相同的信息。

5.5. 使用 CMC 提交证书请求

本节描述了通过 CMS (CMC)使用证书管理注册证书的步骤。
有关使用 CMC 配置和注册证书的通用信息，请参考：
  • Red Hat Certificate System Planning, Installation and Deployment Guide 中的 Configuring CMC 部分。
  • Red Hat Certificate System Planning, Installation and Deployment Guide 中的 Enrolling with CMC 部分。
  • CMCRequest(1) man page
  • CMCResponse(1) man page
CMC 注册可以通过各种方式来满足不同场景的要求。第 5.5.2 节 “CMC 注册过程” 红帽证书系统规划、安装和部署指南中的使用 CMC 注册 部分，以及 更多详情。另外，第 5.5.3 节 “实际 CMC 注册场景” 部分可让管理员决定在哪些场景中应使用哪些机制。

5.5.1. 使用 CMC 注册

CMC 注册允许注册客户端使用 CMCAuth 插件进行身份验证，该插件使用代理证书预签名证书。当收到使用代理证书签名的有效请求时，证书管理器会自动发布证书。
注意
CMC 注册会被默认启用。除非更改了配置，否则应该不需要启用 CMC 注册身份验证插件或配置文件。
CMCAuth 身份验证插件还为客户端提供 CMC 吊销。CMC 吊销允许客户端具有代理证书签名的证书请求，然后将此类请求发送到证书管理器。当收到使用代理证书签名的有效请求时，证书管理器会自动撤销证书。CMC 吊销可以使用 CMCRevoke 命令行工具创建。有关 CMCRevoke 的更多信息，请参阅 第 7.2 节 “执行 CMC 吊销”。
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.5.1.1. 测试 CMCEnroll
  1. 使用 certutil 工具创建证书请求。
  2. 将 PKCS the10 ASCII 输出复制到文本文件。
  3. 运行 CMCEnroll 工具。
    例如，如果名为 request34.txt 的输入文件，代理证书存储在浏览器数据库中，代理证书的证书通用名称为 CertificateManagerAgentsCert，证书数据库的密码为 secret，如下所示： 
    CMCEnroll -d ~jsmith/.mozilla/firefox/1234.jsmith -n "CertificateManagerAgentsCert" -r /export/requests/request34.txt -p secret
    此命令的输出存储在一个文件中，其文件名相同，且 .out 附加到文件名中。
  4. 通过终端实体页面提交签名证书。
    1. 打开 end-entities 页面。 
      https://server.example.com:8443/ca/ee/ca
    2. 从证书配置文件列表中选择 CMC 注册表单。
    3. 将输出文件的内容粘贴到此表单的 证书请求 文本区域。
    4. 从粘贴内容中删除 -----BEGIN NEW CERTIFICATE REQUEST----- 和 ----END NEW CERTIFICATE REQUEST-----。
    5. 填写联系信息并提交表单。
  5. 证书会立即处理并返回。
  6. 使用 agent 页面搜索新证书。

5.5.2. CMC 注册过程

使用以下常规流程使用 CMC 请求和发布证书：
  1. 使用以下格式之一创建证书签名请求(CSR)：
    • PKCS the10 格式
    • 证书请求消息格式(CRMF)格式
    有关以这些格式创建 CSR 的详情，请参考 第 5.2 节 “创建证书签名请求”。
  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
    • 根据 Red Hat Certificate System Planning, Installation, installation, and Deployment Guide 中的 Managing Certificate/Key Crypto Token 部分的指导来验证并导入 admin 客户端证书： 
      $ 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
  3. 为 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。
  4. 创建 CMC 请求： 
    $ CMCRequest /home/user_name/cmc-request.cfg
    如果命令成功，CMCRequest 工具会将 CMC 请求存储在请求配置文件中的 output 参数中指定的文件中。
  5. 为 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 参数中指定的证书 nickname 必须与之前用于 CMC 请求的证书匹配。
  6. 根据您请求的证书类型，将以下参数添加到上一步中创建的配置文件中： 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
    例如，对于 CA 签名证书： 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
    重要
    当代理在下一步中提交 CMC 请求时，此参数中指定的配置集必须使用 CMCAuth 身份验证插件。在用户发起的注册中，配置集必须使用 CMCUserSignedAuth 插件。详情请查看 第 10.3 节 “CMC 身份验证插件”。
  7. 向 CA 提交 CMC 请求： 
    $ HttpClient /home/user_name/cmc-submit.cfg
  8. 要将 CMC 响应转换为 PKCS the7 证书链，请将 CMC 响应文件传递给 CMCResponse 工具的 -i 参数。例如： 
    $ CMCResponse -i /home/user_name/cmc-response.bin -o /home/user_name/cert_chain.crt

5.5.3. 实际 CMC 注册场景

本节论述了频繁的实际使用场景及其工作流，以便 CA 管理员能够决定在哪些情况下使用哪些 CMC 方法。
有关使用 CMC 注册证书的通用过程，请参阅 第 5.5.2 节 “CMC 注册过程”。
5.5.3.1. 获取系统和服务器证书
如果服务（如 LDAP 或 Web 服务器）需要 TLS 服务器证书，则此服务器的管理员会根据服务的文档创建一个 CSR，并将其发送到 CA 的代理以进行批准。这个过程使用 第 5.5.2 节 “CMC 注册过程” 中描述的步骤。另外，请考虑以下要求：
注册配置集
代理必须使用 第 10.3 节 “CMC 身份验证插件” 中列出的现有 CMC 配置集之一，或者创建一个使用 CMCAuth 验证机制的自定义配置集。
CMC 签名证书
对于系统证书，CA 代理必须生成并签署 CMC 请求。为此，将 CMCRequest 配置文件中的 nickname 参数设置为 CA 代理的别名。
注意
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 时，会被视为已建立 Identification，因为代理会检查 CSR 进行验证。不需要额外的 CMC 特定标识验证。
  • PKCS the10 文件已经提供 Possession 信息，且不需要额外的 Possession (POP)。
  • 在代理预批准的请求中，必须禁用 PopLinkWittnessV2 功能，因为代理会检查识别。
5.5.3.2. 获取用户的第一个签名证书
可以通过两种方式批准用户的第一个签名证书：
5.5.3.2.1. 使用代理证书签名 CMC 请求
使用代理证书签名 CMC 请求的过程与 第 5.5.3.1 节 “获取系统和服务器证书” 中描述的系统和服务器证书相同。唯一的区别是用户创建 CSR 并将其发送到 CA 代理以进行批准。
5.5.3.2.2. 使用共享 Secret 验证证书注册
当用户想要获取第一个签名证书且代理无法批准请求时，如 第 5.5.3.2.1 节 “使用代理证书签名 CMC 请求” 所述，您可以使用 Shared Token。使用这个令牌，用户可以获取第一个签名的证书。然后，这个证书可用于为用户的其他证书签名。
在这种情况下，使用 Shared Secret 机制来获取用户的第一个签名证书。将以下信息与 第 5.5.2 节 “CMC 注册过程” 搭配使用：
  1. 以用户或 CA 管理员身份创建共享令牌。详情请参阅 Red Hat Certificate System 规划、安装和部署指南中的 共享 Secret 工作流 部分。
    请注意：
    • 如果用户创建了令牌，用户必须向 CA 管理员发送令牌。
    • 如果 CA 管理员创建了令牌，管理员必须与用户共享用于生成令牌的密码。使用安全的方式传输密码。
  2. 作为 CA 管理员，将共享令牌添加到 LDAP 中的用户条目中。详情请参阅 Red Hat Certificate System Planning, Installation, installation, installation, and deployment Guide 中的 第 10.4.2.1 节 “将 CMC 共享 Secret 添加到用于证书注册的用户条目中” 和 Enabling the CMC Shared Secret Feature 部分。
  3. 在传递给 CMCRequest 工具的配置文件中使用以下参数：
    • identification.enable
    • witness.sharedSecret
    • identityProofV2.enable
    • identityProofV2.hashAlg
    • identityProofV2.macAlg
    • request.useSharedSecret
    • request.privKeyId
  4. 如果 CA 需要，还要使用传递给 CMCRequest 工具的配置文件中的以下参数：
    • popLinkWitnessV2.enable
    • popLinkWitnessV2.keyGenAlg
    • popLinkWitnessV2.macAlg
5.5.3.3. 获取用户只加密的证书
本节论述了获取使用现有用户签名证书签名的只加密证书的工作流：
注意
如果用户拥有多个用于不同用途的证书，其中有一个被签名，用户必须首先获取签名证书。用户拥有签名证书后，就可以将其用于参与 Of Origin，而无需设置并依赖 CMC 共享 Secret 机制。
有关获取用户第一个签名证书的详情，请参考 第 5.5.3.2 节 “获取用户的第一个签名证书”。
以用户身份：
  1. 使用存储在网络安全服务(NSS)数据库或包含用户签名证书和密钥的智能卡中的加密令牌。
  2. 以 PKCS the10 或 CRMF 格式生成 CSR。
    注意
    如果需要密钥归档，请使用 CRMF 格式。
  3. 生成 CMC 请求。
    由于这是仅加密的证书，私钥无法签名。因此，不包含参与 Of Possession (POP)。因此，注册需要两个步骤：如果初始请求成功，则会导致带有 EncryptedPOP 控制的 CMC 状态。然后，用户使用响应并生成包含 DecryptedPOP 控制的 CMC 请求，并在第二个步骤中提交它。
    1. 对于第一步，除了默认参数外，用户还必须在传递给 CMCRequest 工具的配置文件中设置以下参数：
      • identification.enable
      • witness.sharedSecret
      • identityProofV2.enable
      • identityProofV2.hashAlg
      • identityProofV2.macAlg
      • CA 需要 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.5.3.3.1. 使用 Key Archival 仅包含只加密证书的示例
要使用密钥存档执行注册，请生成一个 CMC 请求，在 CRMF 请求中包含用户的加密私钥。以下流程假设该用户已经拥有签名证书。此签名证书的别名在配置文件中的配置文件中设置。
注意
以下流程描述了与只加密密钥一起使用的双端颁发，这些密钥无法用于签名。如果您使用可签署证书的密钥，请将 -q POP_SUCCESS 选项而不是 -q POP_NONE 传递给 single-trip aresuance 的 CRMFPopClient 工具。
有关在 POP_SUCCESS 中使用 CRMFPoPClient 的说明，请参考 第 5.2.1.3.1 节 “使用 CRMFPopClient 创建带有密钥 Archival 的 CSR” 和 第 5.2.1.3.2 节 “使用 CRMFPopClient 为基于 SharedSecret 的 CMC 创建 CSR”。
  1. 搜索 KRA 传输证书。例如： 
    $ pki cert-find --name KRA_transport_certificate_subject_CN
  2. 使用您在上一步中检索到的 KRA 传输证书的序列号，将证书存储在文件中。例如，要将带有 12345 序列号的证书存储在 /home/user_name/kra.cert 文件中： 
    $ pki cert-show 12345 --output /home/user_name/kra.cert
  3. 使用 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。后续步骤中需要 ID，作为第二个往返的配置文件中的 request.privKeyId 参数的值。
  4. 为 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 cert9.db, key4.db and pkcs11.txt
dbdir=/home/user_name/.dogtag/nssdb/

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

#format: request format, either pkcs10 or crmf
format=crmf
  5. 创建 CMC 请求： 
    $ CMCRequest /home/user_name/cmc.cfg
    如果命令成功，CMCRequest 工具会将 CMC 请求存储在请求配置文件中的 output 参数中指定的文件中。
  6. 为 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 cert9.db, key4.db and pkcs11.txt
#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 cert9.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
  7. 向 CA 提交 CMC 请求： 
    $ HttpClient /home/user_name/cmc-submit.cfg
    如果命令成功，HTTPClient 实用程序会将 CMC 响应存储在配置文件中 output 参数指定的文件中。
  8. 通过将响应文件传递给 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
  9. 对于第二个往返，请为 DecryptedPOP 创建配置文件，如 /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 cert9.db, key4.db and pkcs11.txt
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert9.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
  10. 创建 DecryptPOP CMC 请求： 
    $ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg
    如果命令成功，CMCRequest 工具会将 CMC 请求存储在请求配置文件中的 decryptPopRequestFile 参数指定的文件中。
  11. 为 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 cert9.db, key4.db and pkcs11.txt
#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 cert9.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
  12. 向 CA 提交 DecryptedPOP CMC 请求： 
    $ HttpClient /home/user_name/decrypted_POP_cmc-submit.cfg
    如果命令成功，HTTPClient 实用程序会将 CMC 响应存储在配置文件中 output 参数指定的文件中。
  13. 要将 CMC 响应转换为 PKCS the7 证书链，请将 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.6. 执行 Bulksuance

当管理员需要同时提交和生成大量证书时，可能存在实例。证书系统提供的工具组合可用于向 CA 发送包含证书请求的文件。这个示例流程使用 PKCS10Client 命令生成请求，以及 sslget 命令将请求发送到 CA。
  1. 由于此过程被脚本化，因此需要设置多个变量来标识 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. 停止证书系统实例。 
      pki-server stop instance_name
    5. 使用 pk12util 导入证书。 
      # pk12util -i /tmp/agent.p12 -d ${d} -W p12filepassword
      如果过程成功，该命令会打印以下输出： 
      pk12util: PKCS12 IMPORT SUCCESSFUL
    6. 启动证书系统实例。 
      pki-server start instance_name
  2. 必须设置两个额外变量。用于标识用于处理请求的 CA 配置集的变量，以及用于发送 post 语句的变量，以提供配置文件表单的信息。 
    export post="cert_request_type=pkcs10&xmlOutput=true&profileId=caAgentServerCert&cert_request="
export url="/ca/ee/ca/profileSubmitSSLClient"
    注意
    本例向 caAgentServerCert 配置集提交证书请求（在 post 语句的 profileId 项中标识）。可以使用任何证书配置文件，包括自定义配置集。
  3. 测试变量配置。 
    echo ${d} ${p} ${f} ${nick} ${cahost} ${caport} ${post} ${url}
  4. 使用（例如，）PCS 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}
  5. 使用 sslget 将步骤 4 中创建的批量证书请求文件提交到 CA 配置集接口。例如： 
    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.7. 在 Cisco 路由器上注册证书

简单的证书注册协议(SCEP)由 Cisco 设计，是路由器用来为路由器注册证书的证书颁发机构（如 CA）的一种方式。
通常，路由器安装程序在路由器中输入 CA 的 URL 和质询密码（也称为一次性 PIN），并发出命令来启动注册。然后，路由器通过 SCEP 与 CA 通信来生成、请求和检索证书。路由器也可以使用 SCEP 检查待处理请求的状态。

5.7.1. 启用 SCEP 注册

出于安全考虑，在 CA 中默认禁用 SCEP 注册。要允许注册路由器，必须手动为 CA 启用 SCEP 注册。
  1. 停止 CA 服务器，以便您可以编辑配置文件。 
    pki-server stop instance_name
  2. 打开 CA 的 CS.cfg 文件。 
    vim /var/lib/pki/instance_name/ca/conf/CS.cfg
  3. 将 ca.scep.enable 设置为 true。如果没有该参数，则使用 参数添加一行。 
    ca.scep.enable=true
  4. 重启 CA 服务器。 
    pki-server start instance_name

5.7.2. 为 SCEP 配置安全设置

通过几个不同的参数，管理员可以设置 SCEP 连接的特定安全要求，如不使用同一证书进行注册身份验证和常规证书注册，或者设置允许的加密算法以防止降级连接强度。这些参数列在 表 5.1 “SCEP 安全性的配置参数” 中。
表 5.1. SCEP 安全性的配置参数
参数 描述
ca.scep.encryptionAlgorithm 设置默认或首选加密算法。
ca.scep.allowedEncryptionAlgorithms 设置以逗号分隔的加密算法列表。
ca.scep.hashAlgorithm 设置默认或首选哈希算法。
ca.scep.allowedHashAlgorithms 设置以逗号分隔的哈希算法列表。
ca.scep.nickname 提供用于 SCEP 通信的证书 nickname。除非设置了此参数，否则默认使用 CA 的密钥对和证书。
ca.scep.nonceSizeLimit 设置 SCEP 请求允许的最大非ce 大小（以字节为单位）。默认值为 16 字节。
为 SCEP 注册设置连接的安全设置：
  1. 停止 CA 服务器，以便您可以编辑配置文件。 
    pki-server stop instance_name
  2. 打开 CA 的 CS.cfg 文件。 
    vim /var/lib/pki/instance_name/ca/conf/CS.cfg
  3. 设置所需的安全参数，如 表 5.1 “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
  4. 重启 CA 服务器。 
    pki-server start instance_name

5.7.3. 为 SCEP 注册配置路由器

注意
不是所有版本的路由器 IOS 都有相关的加密功能。确保固件镜像具有认证机构互操作性功能。证书系统 SCEP 支持已在运行 IOS C2600 软件(C2600-JK9S-M)、版本 12.2 (40), RELEASE SOFTWARE (fc1)的 Cisco 2611 路由器上测试。
在路由器中注册 SCEP 证书前，请确保正确配置了路由器：
  • 路由器必须使用 IP 地址、DNS 服务器和路由信息进行配置。
  • 路由器的日期/时间必须正确。
  • 必须配置路由器的主机名和 dnsname。
有关配置路由器硬件的说明，请参阅路由器文档。

5.7.4. 为路由器生成 SCEP 证书

以下流程详细介绍了如何为路由器生成 SCEP 证书。
  1. 选择一个随机 PIN。
  2. 将 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 地址。
    第 10.2.4 节 “配置平面文件身份验证” 中描述了使用平面文件身份验证。
  3. 登录路由器的控制台。在本例中，路由器的名称为 scep ： 
    scep>
  4. 启用特权命令。 
    scep> enable
  5. 进入配置模式。 
    scep# conf t
  6. 从 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
  7. 设置 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
  8. 获取 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
  9. 生成 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]
  10. 最后，在路由器上生成证书。 
    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
  11. 关闭配置模式。 
     scep(config)# exit
  12. 为确保路由器已正确注册，请列出路由器中存储的所有证书。 
    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.7.5. 使用子 CA

在路由器可以向 CA 进行身份验证前，从 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 证书没有设置 CRL 发行点扩展，请通过将其设置为 可选 来关闭 CRL 要求： 
scep(ca-root)# crl optional
之后，设置 CA 身份，如 第 5.7.4 节 “为路由器生成 SCEP 证书” 所述。

5.7.6. 重新注册路由器

在使用新证书重新注册路由器之前，必须删除现有的配置。
  1. 删除（零化）现有密钥。 
    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
  2. 删除 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.7.7. 启用调试

路由器通过启用 debug 语句在 SCEP 操作过程中提供额外的调试。 
 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.7.8. 使用 SCEP 发布 ECC 证书

默认情况下，ECC CA 不支持 SCEP out。但是，可以使用指定的 RSA 证书来处理以下两个区域的每个区域来解决这个问题：
  • 加密/解密证书 - 指定具有加密/解密功能的 RSA 证书；（以下示例中的scepRSAcert）
  • 签名证书 - 获取在客户端中使用的 RSA 证书以签名目的，而不是自签名；（以下示例中的signingCert 证书）
例如，如果 scepRSAcert 证书是加密/解密证书，并且 signedCert 是签名证书： 
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'

5.8. 使用证书转换

证书系统提供证书转换(CT) V1 支持(rfc 6962)的基本版本。它能够从任何可信日志发布带有嵌入式证书时间戳(SCT)的证书，每个部署站点选择包含其 root CA 证书。您还可以将系统配置为支持多个 CT 日志。这个功能至少需要一个可信的 CT 日志。
重要
部署站点负责建立与可信 CT 日志服务器的信任关系。
有关如何配置证书转换的更多信息，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的 Configuring CertificateTransparency 部分。

5.8.1. 测试证书转换

有关如何测试 CT 设置的示例，以下步骤描述了 Google CT 测试日志的实际测试。更为全面的测试过程涉及设置 TLS 服务器，并测试从指定的 CT 日志中包含其证书。但是，以下可作为在签发证书后检查包含 SCT 扩展的快速测试。
测试过程包括生成和提交证书签名请求(CSR)，以便使用 openssl 验证其 SCT 扩展。CS.cfg 文件中的测试配置如下： 
ca.certTransparency.mode=enabled
ca.certTransparency.log.1.enable=true
ca.certTransparency.log.1.pubKey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEw8i8S7qiGEs9NXv0ZJFh6uuOm<snip>
ca.certTransparency.log.1.url=http://ct.googleapis.com:80/testtube/
ca.certTransparency.log.1.version=1
ca.certTransparency.log.2.enable=true
ca.certTransparency.log.2.pubKey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEKATl2B3SAbxyzGOfNRB+AytNTG<snip>
ca.certTransparency.log.2.url=http://ct.googleapis.com:80/logs/crucible/
ca.certTransparency.log.2.version=1
ca.certTransparency.log.3.enable=false
ca.certTransparency.log.3.pubKey=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEiKfWtuoWCPMEzSKySjMjXpo38W<snip>
ca.certTransparency.log.3.url=http://ct.googleapis.com:80/logs/solera2020/
ca.certTransparency.log.3.version=1
ca.certTransparency.log.num=3
  1. 首先，生成一个 CSR，例如： 
    # PKCS10Client -d . -p passwd -l 2048 -n "cn=user.test.domain.com,OU=user-TEST,O=TestDomain" -o pkcs10-TLS.req
  2. 接下来，根据 CS.cfg 中的 ca.certTransparency.mode 参数定义的 CT 模式将 CSR 提交到注册配置集：
    • 如果参数设为 enabled，则使用任何注册配置集
    • 如果该参数设为 perProfile，请使用其中一个 CT 配置集：例如 caServerCertWithSCT
  3. 将发布的 b64 证书复制到一个文件中，如 .ct1.pem。
  4. 将 pem 转换为二进制： 
    #  AtoB ct1.pem ct1.bin
  5. 显示 DER 证书内容： 
    #  openssl x509 -noout -text -inform der -in ct1.bin
  6. 观察 SCT 扩展存在，例如： 
    								CT Precertificate SCTs:
								 Signed Certificate Timestamp:
										 Version   : v1 (0x0)
										 Log ID    : B0:CC:83:E5:A5:F9:7D:6B:AF:7C:09:CC:28:49:04:87:
																 2A:C7:E8:8B:13:2C:63:50:B7:C6:FD:26:E1:6C:6C:77
										 Timestamp : Jun 11 23:07:14.146 2020 GMT
										 Extensions: none
										 Signature : ecdsa-with-SHA256
																 30:44:02:20:6E:E7:DC:D6:6B:A6:43:E3:BB:8E:1D:28:
																 63:C6:6B:03:43:4E:7A:90:0F:D6:2B:E8:ED:55:1D:5F:
																 86:0C:5A:CE:02:20:53:EB:75:FA:75:54:9C:9F:D3:7A:
																 D4:E7:C6:6C:9B:33:2A:75:D8:AB:DE:7D:B9:FA:2B:19:
																 56:22:BB:EF:19:AD
								 Signed Certificate Timestamp:
										 Version   : v1 (0x0)
										 Log ID    : C3:BF:03:A7:E1:CA:88:41:C6:07:BA:E3:FF:42:70:FC:
																 A5:EC:45:B1:86:EB:BE:4E:2C:F3:FC:77:86:30:F5:F6
										 Timestamp : Jun 11 23:07:14.516 2020 GMT
										 Extensions: none
										 Signature : ecdsa-with-SHA256
																 30:44:02:20:4A:C9:4D:EF:64:02:A7:69:FF:34:4E:41:
																 F4:87:E1:6D:67:B9:07:14:E6:01:47:C2:0A:72:88:7A:
																 A9:C3:9C:90:02:20:31:26:15:75:60:1E:E2:C0:A3:C2:
																 ED:CF:22:A0:3B:A4:10:86:D1:C1:A3:7F:68:CC:1A:DD:
																 6A:5E:10:B2:F1:8F
    或者，通过运行 asn1 转储来验证 SCT： 
    #  openssl asn1parse -i -inform der -in ct1.bin
    观察十六进制转储，例如： 
      740:d=4  hl=4 l= 258 cons:     SEQUENCE
		744:d=5  hl=2 l=  10 prim:      OBJECT            :CT Precertificate SCTs
		756:d=5  hl=3 l= 243 prim:      OCTET STRING      [HEX DUMP]:0481F000EE007500B0CC83E5A5F97D6B<snip>

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

本章提供了使用硬件安全模块（也称为 HSM 或 令牌 ）的步骤来生成和存储证书系统实例证书和密钥。
本章仅包含管理流程。有关令牌管理系统后面的概念的常规信息，请参阅 红帽认证系统规划、安装和部署指南。

6.1. TPS 配置集

注意
有关一般信息，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的 TPS Profiles 部分。
与 CA 注册配置文件（定义并存储在 LDAP 中）不同，TPS 配置文件（也称为令牌类型）在 TPS 配置文件 CS.cfg 中定义。
TPS 配置集（令牌类型）配置参数采用以下格式设置： 
op.<explicit op>.<profile id>.<implicit op>.<key type>.*
在上例中，&lt <explicit op> ;implicit op& gt; 是下面 TPS Operations 部分中讨论的显式和隐式操作之一，& lt;key type > 是为每个证书类型提供的名称。
配置参数示例可能类似以下示例： 
op.enroll.userKey.keyGen.encryption.*

6.2. TPS 操作

显式操作

显式操作 是用户调用的操作。显式操作包括 Register (op.enrollö)、format (op.formatö)和 pinReset (op.pinReset)。

隐式操作

隐式操作是 一个操作，它会在处理显式操作时发生令牌的策略或状态。隐式操作包括 keyGen (op.enroll.userKey.keyGenü), renewal (op.enroll.userKey.renewal047), update.applet (op.enroll.userKey.update.applet), 和 key update (op.enroll.userKey.update.symmetricKeys945)。

某些隐式操作根据键类型控制。这包括 恢复、serverKeygen 和 撤销。
以下 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. 吊销原因和代码
原因 代码
未指定 0
keyCompromise 1
CACompromise 2
affiliationChanged 3
被取代 4
cessationOfOperation 5
certificateHold 6
removeFromCRL 8
privilegeWithdrawn 9
AACompromise 10

6.3. 令牌策略

本节提供了令牌策略列表，它们可使用 TPS UI 按令牌应用。Ech 部分将显示每个策略如何反映在配置中。
注意
有关一般信息，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的 Token Policies 部分。
策略是策略集合，各自用分号(";"")分隔。每个策略都可以使用关键字 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
这种类型的续订配置使用特定于续订的一些添加的设置，对基本 userKey 标准注册配置集进行了镜像(mirror)。这个奇偶校验是必需的，因为我们开始在续订前，准确续订了最初注册到令牌的证书的数量和类型。
FORCE_FORMAT=NO
如果启用，此策略会导致每个注册操作提示格式操作。这是一个最后一步选项，允许在无需将其返回到管理员的情况下重置令牌。如果设置为 YES，用户发起的每个注册操作将导致格式发生，因此机密将令牌重置为格式化的状态。
不需要额外的配置。发生一个简单的格式时，将执行标准格式操作的同一 TPS 配置文件。
PIN_RESET=NO
此策略决定已经注册的令牌是否可以使用 ESC 执行显式"固定重置"更改。这个值必须设置为 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 或 & lt;POLICYNAME> =NO 才能被 TPS 识别。

6.4. 令牌操作和策略处理

本节讨论涉及令牌的主要操作（显式和隐式）。以下列表将讨论每个功能及其配置。
注意
有关一般信息，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的 Token Policies部分。
格�
格式操作(user-initiated)采用一个完全空白状态的令牌，如制造商提供的，并在其上载入 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
注册
基本注册操作采用格式化的令牌，并将证书和密钥放在令牌中，以便定制令牌。以下配置示例将解释了如何控制它。
示例显示了不处理续订和内部恢复的基本注册。此处未讨论的设置在 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 依赖于一个策略来确定是否被法律执行。
续订
第 6.3 节 “令牌策略” 中讨论了续订的配置，因为续订依赖于一个策略来确定它是否是要执行还是在已经注册的令牌时执行。
恢复
当 TPS 用户界面的用户将一个之前活跃的令牌标记为不可屏蔽的状态，如 "lost" 或 "destroyed" 时，恢复会被隐式设置为 motion。发生这种情况后，同一用户新令牌的下一次注册将遵循以下配置，将用户的旧令牌从用户的旧令牌恢复到此新令牌。
此操作的最终结果是用户会有一个新的物理令牌，该令牌可能包含从旧令牌中恢复的加密密钥，以便用户可以根据需要继续加密和解密数据。新的签名证书通常也会放置在这个令牌上，如下例所示。
以下是可手动将令牌放置到 TPS 用户界面中的支持状态列表，如配置中所示：
  • tokendb._069=114 - DAMAGED (1): Corresponds 在恢复配置中 销毁。当令牌被物理损坏时使用。
  • tokendb._070=114 - PERM_LOST (2): 在恢复配置中将 Corresponds 变为 keyCompromise。当令牌永久丢失时，使用。
  • tokendb._071=114 - SUSPENDED (3): Corresponds to onHold in the recovery configuration.当令牌被临时错误替换时，会使用它，但用户需要再次找到它。
  • tokendb._072=114 - TERMINATED (6): Corresponds to terminated in the recovery configuration.用于因为内部原因使令牌不足。
恢复配置示例： 
#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)：恢复要放置到令牌的最新加密证书。
  • generate New Key and Recover Last (GenerateNewKeyAndRecoverLast): 与 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 applet 更新操作。此操作可以在格式、注册和 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 重置操作期间发生，允许用户从制造商提供的默认平台密钥集版本升级其 Global Platform 密钥集版本。
TPS
以下选项将指示 TPS 在代表给定令牌请求下一格式操作期间，将 keyset 从 1 升级到 2。完成后，TKS 必须生成将写入令牌的三个新密钥，之后，令牌必须与相同的 TPS 和 TKS 安装一起使用，否则它将会被锁定。 
op.format.userKey.update.symmetricKeys.enable=true
op.format.userKey.update.symmetricKeys.requiredVersion=2
您还可以指定一个低于 current 的版本来降级 keyset。
TKS
如上所述，必须将 TKS 配置为生成要写入令牌的新密钥。首先，新的主密钥标识符 02 必须映射到 TKS CS.cfg 中的 PKCS the 对象别名，如下例所示： 
tks.mk_mappings.#02#01=internal:new_master
tks.defKeySet.mk_mappings.#02#01=internal:new_master
以上会将密钥集号映射到 TKS NSS 数据库中存在的实际主密钥。
主密钥由 ID （如 01 ）标识。TKS 将这些 ID 映射到映射的 masterKeyId 部分中指定的 PKCS the 对象别名。因此，第一个数字被更新，因为主密钥版本已更新，第二个数字保持不变。
当尝试从版本 1 升级到 2 时，映射决定了如何找到主密钥别名，该别名将用于派生新密钥集的 3 部分。
上例中的 internal 设置引用主密钥所在的令牌的名称。它还可能是具有名称（如 nethsm ）的外部 HSM 模块。强大的 new_master 是主密钥 nickname 本身的示例。

6.5. 内部注册

注意
有关一般信息，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的 TPS Profiles 部分。
如果是 内部注册，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 假设问题中的证书已存在于令牌中，并且应保留它。此概念称为 Key Retention。
以下示例显示了用户 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 配置文件确定）：
  • 身份验证证书/密钥： CN 包含委托的名称和唯一 ID。主题备用名称(SAN)扩展包含领导名称(UPN)。
  • 加密密钥 ：执行加密证书的精确副本。
  • 签名证书： CN 包含委托的名称和唯一 ID。SAN 包含参与的 RFC822Name。
使用以下参数启用委派支持： 
externalReg.delegation.enable=true
重要
要临时解决这个问题，请手动将 /var/lib/pki/instance_name/tps/conf/CS.cfg 文件中的 op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId 参数设置为 caTokenUserDelegateAuthKeyEnrollment ： 
op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId=caTokenUserDelegateAuthKeyEnrollment

6.6.6. SAN 和 DN 模式

身份验证实例配置中的 auths.instance.<authID > .ldapStringAttributes 指定在身份验证过程中将检索哪些属性。例如： 
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)或可辨识名称(DN)，格式为 $auth. <attribute name&gt; $。例如： 
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 是用户主体名称(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& gt; 以 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 配置集 delegateIEtoken 包含：
  • SAN 特征 ： 
    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 包含： 
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. 映射解决程序配置

令牌处理系统默认提供一个映射解析器。解析器称为 FilterMappingResolver。本节将涵盖其配置。
注意
有关 映射解决 的一般信息，请参阅 Red Hat Certificate System Planning, Installation and Deployment Guide 中的 Mapping Resolver 部分。

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 及其目标 jForte。
请注意，映射 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
为上例中的 enrollProfileMappingResolver 定义三个映射。映射名为 0、1 和 2。mappingResolver.enrollProfileMappingResolver.mapping.order=1,0,2 行定义映射将处理的顺序。如果令牌与映射匹配，则不会评估顺序中的进一步映射；如果没有与映射不匹配，则顺序的下一个映射将会被尝试。
如果使用带有以下参数的令牌： 
CUID=a0000000000000000011
appletMajorVersion=1
appletMinorVersion=0
extension: tokenType=soKey
具有此配置的令牌将匹配映射 1 的过滤器，因为 applet 版本匹配，CUID 在指定的 start 和 end 范围内会失败，扩展 tokenType 匹配。因此，此令牌将被分配该映射的目标 - soKey。
在另一个情况下，如果令牌有以下参数： 
CUID=b0000000000000000010
appletMajorVersion=1
appletMinorVersion=1
在这种情况下，令牌将失败映射 1，因为 CUID 不在指定的范围之外。然后，它还会失败映射 0， 因为缺少 tokenType 扩展。然后，此令牌将匹配映射 2，因为它没有指定的过滤器以匹配所有与之前过滤器不匹配的令牌。

6.8. 身份验证配置

令牌处理系统默认支持使用用户 ID 和密码(UidPwdDirAuthentication)基于目录的身份验证。使用以下模式在 CS.cfg 文件中定义身份验证实例： 
auths.instance.<auths ID>.*
& lt;auths ID > 是 TPS 配置集要引用的身份验证首选项的验证器名称。例如： 
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 用户 ID 和 auths.instance.ldap1.ui.id.PASSWORD.name.en=LDAP 密码 参数控制；此配置告知客户端将 UID/密码对显示为"LDAP 用户 ID"和"LDAP 密码"。这两个参数均可自定义。
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
另外，您必须将 CA 签名证书添加到 TPS nssdb 并设置信任： 
#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 the 令牌、参数 kra.keygen.temporaryPairs、kra.keygen.sensitivePairs 和 kra.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 模式中。FIPS 模式中的 LunaSA Cloning 模型和 CKE 模型不支持 PKI 私钥提取。
注意
当 LunaSA CKE - 密钥导出模型处于 FIPS 模式时，无法提取 pki 私钥。

6.12. 设置新密钥集

本节论述了设置令牌处理系统(TPS)和令牌密钥服务(TKS)中设置的默认密钥的替代选择。
TKS 配置
默认密钥集使用 /var/lib/pki/instance_name/tks/conf/CS.cfg 文件中的以下选项在 TKS 中配置： 
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 键离散方法的设置控制此方法是否使用标准 Visa 方法。具体来说，tks.defKeySet.nistSP800-108KdfOnKeyVersion 选项的值决定将使用 NIST 版本。nistSP800-108KdfUseCuidAsKdd 选项允许您在处理过程中使用 CUID 的传统密钥 ID 值。较新的 KDD 值最常被使用，因此默认禁用这个选项（默认为 ）。这可让您配置一个新的密钥集来启用对新密钥类别的支持。

例 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 静态会话键的不同。
证书系统支持 Giesecke & Devrient (G&D) Smart Cafe 6 智能卡的安全通道协议 03 (SCP03)。要在 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 添加到 TPS 的 CS.cfg 配置文件中。
  • 某些客户端可能会被配置为显式传递所需的 keySet 值。但是，企业级安全客户端目前没有此功能。
  • 当 TPS 根据所需方法计算正确的 keySet 时，对 TKS 的所有请求都通过 keySet 值创建安全频道。然后，TKS 可以使用自己的 keySet 配置（上面描述）来确定如何继续。

6.13. 设置新主密钥

本节介绍了在令牌密钥服务(TKS)中设置新主密钥所需的步骤和配置。有关背景信息，请参阅 Red Hat Certificate System Planning、安装和部署指南。

过程 6.1. 创建新主密钥

  1. 获取内部访问 TKS 安全数据库所需的 PIN： 
    # cat /var/lib/pki/pki-tomcat/tks/conf/password.conf
internal=649713464822
internaldb=secret12
replicationdb=-752230707
  2. 打开 TKS 实例 的别名/ 目录： 
    # cd /var/lib/pki/pki-tomcat/alias
  3. 使用 tkstool 工具生成新的主密钥。例如： 
    # 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
  4. 验证密钥是否已正确添加到数据库中： 
    # 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. 生成和传输 Wrapped Master 密钥(Key Ceremony)

如果要在外部令牌或多个位置使用主密钥，则必须 嵌套 它，以便安全地将其传送到硬件令牌。tkstool 工具可用于生成传输密钥，然后用于将主密钥发送到生成令牌的工具。传输嵌套主密钥的过程通常称为 Key Ceremony。
注意
传输密钥只能与它们生成的主密钥一起使用。

过程 6.2. 生成和传输 Wrapped 主密钥

  1. 获取访问 Token Key Service 安全数据库所需的内部 PIN： 
    # cat /var/lib/pki/pki-tomcat/tks/conf/password.conf

internal=649713464822
internaldb=secret12
replicationdb=-752230707
  2. 打开 TKS 实例 别名/ 目录： 
    # cd /var/lib/pki/pki-tomcat/alias
  3. 创建名为 transport 的 传输 密钥： 
    # tkstool -T -d . -n transport
    注意
    tkstool 工具打印每个生成的三个会话键的密钥共享和 KCV 值。将它们保存到文件中，因为有必要在此流程以后在新数据库中重新生成传输密钥，并在丢失时重新生成密钥。
  4. 出现提示时，填写数据库密码。然后，按照屏幕说明生成随机 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
  5. 下一提示将生成一系列会话密钥。按照屏幕说明进行操作，直到最终信息： 
    Successfully generated, stored, and named the transport key!
  6. 使用传输密钥生成并嵌套主密钥，并将其存储在名为 file 的文件中： 
    # 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)
  7. 将嵌套的主密钥复制到适当的位置或工具中。
  8. 如有必要，在 HSM 或工具中生成新的安全数据库： 
    # tkstool -N -d <directory>
    或者，添加 -I 选项来生成与最初在新数据库中生成的密钥相同的密钥。以这种方式重新生成传输密钥要求您为此流程前面生成的每个会话密钥输入会话密钥共享和 KCV。 
    # tkstool -I -d <directory> -n verify_transport
  9. 使用传输密钥解压缩存储在文件中的主密钥。提示时提供安全数据库 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!
  10. 验证密钥是否已正确添加到数据库中： 
    # 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 共享 Symmetric 密钥

共享对称密钥必须存在于 TPS 和 TKS 子系统的 NSS 数据库中。此密钥在创建 TPS 子系统时自动生成。如果 TPS 和 TKS 都在同一个 Tomcat 实例中安装，则不需要额外的设置，因为 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. 手动共享 Secret 密钥方法 - TKS 侧

  1. 在第一个系统上安装 Token Key Service。有关安装说明，请参阅 Red Hat Certificate System Planning、安装和部署指南。
  2. 停止 TKS 服务： 
    #pki-server stop pki-tomcat
  3. 进入 /var/lib/pki/pki-tomcat/alias 目录，并使用 tkstool 在 TKS 上创建共享 secret 密钥。在重启新的 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!
  4. 在 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
  5. 启动 TKS： 
    #pki-server start pki-tomcat

过程 6.4. 手动共享 Secret 密钥方法 - TPS 侧

  1. 在第二个系统上安装令牌处理系统。有关安装说明，请参阅 Red Hat Certificate System 10 规划、安装和部署指南。
  2. 停止 TPS 服务： 
    #pki-server stop pki-tomcat
  3. 进入 /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
    此时，脚本会提示您输入在上述流程生成和嵌套共享密钥时显示的会话密钥共享共享密钥。
  4. 在 TPS 中配置共享 secret： 
    conn.tks1.tksSharedSymKeyName=TPS-<tps host name>-8443 sharedSecret
  5. 启动 TPS 服务： 
    #pki-server start pki-tomcat

6.15. 对不同的 SCP 版本使用不同的 Applets

在证书系统中，/var/lib/instance_name/tps/conf/CS.cfg 文件中的以下参数指定为每个令牌操作为所有安全频道协议(SCP)版本载入哪个小程序： 
op.operation.token_type.update.applet.requiredVersion=version
但是，您还可以通过添加以下参数来为特定的 SCP 版本设置单独的小程序： 
op.operation.token_type.update.applet.requiredVersion.prot.protocol_version=version
证书系统支持为以下操作设置单独的协议版本：
  • 格式
  • 注册
  • pinReset

例 6.3. 为注册操作设置协议版本

在为 userKey 令牌执行注册操作时，为 SCP03 配置特定的小程序，并为所有其他协议配置不同的小程序：
  1. 编辑 /var/lib/instance_name/tps/conf/CS.cfg 文件：
    1. 设置 op.enroll.userKey.update.applet.requiredVersion 参数，以指定默认使用的 applet。例如： 
      op.enroll.userKey.update.applet.requiredVersion=1.4.58768072
    2. 设置 op.enroll.userKey.update.applet.requiredVersion.prot.3 参数，以配置 applet 证书系统用于 SCP03 协议。例如： 
      op.enroll.userKey.update.applet.requiredVersion.prot.3=1.5.558cdcff
  2. 重启证书系统： 
    pki-server restart instance_name
有关为 Giesecke & Devrient (G&D) Smart Cafe 6 智能卡启用 SCP03 的详情，请参考 第 6.12 节 “设置新密钥集”。

第 7 章 吊销证书并颁发 CRL

证书系统提供了撤销证书以及生成吊销证书列表的方法，称为证书撤销列表(CRL)。本章描述了撤销证书的方法，描述了 CMC 吊销，并提供 CRL 和设置 CRL 的详细信息。

7.1. 关于撤销证书

证书可由最终用户（证书的原始所有者）或证书管理器代理撤销。最终用户可以使用终端实体页面中提供的撤销表单来撤销证书。代理可以使用代理服务接口中的适当的表单来撤销最终用户证书。这两种情况下都需要基于证书的(SSL/TLS 客户端身份验证)。
最终用户只能撤销包含与为身份验证提供的证书相同的主题名称的证书。身份验证成功后，服务器会列出属于最终用户的证书。然后，最终用户可以选择要撤销的证书，也可以撤销列表中的所有证书。最终用户也可以指定附加详情，如每个证书撤销和吊销原因的日期，或整个证书的列表。
代理可以根据一系列序列号或主题名称组件吊销证书。提交撤销请求时，代理会收到它们可从中获取的证书列表。有关代理如何撤销最终用户证书的说明，请参阅 Red Hat Certificate System Planning、安装和部署指南。
批准撤销请求时，证书管理器在其内部数据库中将对应的证书记录标记为撤销，如果配置为这样做，请从发布目录中删除撤销的证书。这些更改反映在 CA 问题的下一个 CRL 中。
使用公钥证书的服务器和客户端应用需要访问证书的有效性的信息。由于决定证书的有效性的一个因素是其撤销状态，这些应用程序需要知道是否已撤销的证书。CA 负责执行以下操作：
  • 如果 CA 收到撤销请求并批准，则撤销证书。
  • 使撤销的证书状态可供需要验证其有效状态的第三方或应用程序使用。
每当撤销证书时，证书管理器会自动更新其内部数据库中证书的状态，它会将内部数据库中的证书副本标记为撤销，如果证书管理器被配置为从数据库中删除证书。
传递证书撤销状态的标准方法是发布吊销的证书列表，即一个证书撤销列表(CRL)。CRL 是一个公开可用的证书列表，它已被撤销。
证书管理器可以配置为生成 CRL。通过在 CRL 配置中启用特定于扩展的模块，即可创建这些 CRL 以符合 X.509 标准。服务器通过其 CRL 发布点框架支持标准 CRL 扩展；有关设置 CRL 扩展以进行发布点的更多信息，请参阅 第 7.3.3 节 “设置 CRL 扩展”。证书管理器可在每次撤销证书时生成 CRL，并以定期间隔生成 CRL。如果设置了发布，则 CRL 可以发布到文件、LDAP 目录或 OCSP 响应器。
CRL 由发布 CRL 中列出的证书的 CA 或 CA 已授权的实体发布并数字签名。CA 可以使用单个密钥对为证书签名，以及它发布或两个单独的密钥对，一个用于签名证书，另一个用于签名 CRL。
默认情况下，证书管理器使用单个密钥对来签署它发布的证书及其生成的 CRL。要为证书管理器创建另一个密钥对，并将其专门用于签名 CRL，请参阅 第 7.3.4 节 “将 CA 设置为使用不同的证书来签名 CRL”。
在定义和配置点时，生成 CRL，并在启用 CRL 生成时生成。
启用 CRL 后，服务器会在证书被撤销时收集撤销信息。服务器会尝试将撤销的证书与设置的所有发布点匹配。给定证书可以匹配任何问题点、一个发布点、几个发布点或所有发布点。当已撤销的证书与发布点匹配时，服务器会将有关证书的信息存储在那个发布点的缓存中。
缓存按照复制缓存的时间间隔复制到内部目录中。当达到创建 CRL 的时间间隔时，会从缓存创建一个 CRL。如果为此问题设置了 delta CRL，则在此时也会创建一个 delta CRL。自证书管理器开始收集此信息以来，完整的 CRL 包含所有撤销的证书信息。自上次更新完整 CRL 后，delta CRL 包含所有撤销的证书信息。
完整的 CRL 按顺序编号，如 delta CRLs。完整的 CRL 和 delta CRL 的数字相同；在这种情况下，delta CRL 的数字与 下一个 完整 CRL 相同。例如，如果完整的 CRL 是第一个 CRL，它是 CRL 1。delta CRL 是 Delta CRL 2。CRL 1 和 Delta CRL 2 的数据与下一个完整 CRL 2 合并，后者为 CRL 2。
注意
当对发布点的扩展进行修改时，不会为该问题点使用下一个完整 CRL 创建 delta CRL。创建 delta CRL，其中 第二个 full CRL 会被创建，然后所有后续完整 CRL。
内部数据库仅存储最新的 CRL 和 delta CRL。当每个新的 CRL 都被创建时，旧的 CRL 都会被覆盖。
发布 CRL 后，每次更新到 CRL 和 delta CRL 都会发布到发布设置中指定的位置。发布方法决定了存储多少个 CRL。对于文件发布，使用 CRL 的数字发布到文件的每个 CRL，因此不会覆盖任何文件。对于 LDAP 发布，发布的每个 CRL 都取代了目录条目中包含 CRL 的属性中的旧 CRL。
默认情况下，CRL 不包含有关撤销过期证书的信息。服务器可以通过为发布点启用该选项来包括撤销的过期证书。如果包含过期的证书，当证书过期时，有关撤销的证书的信息不会从 CRL 中删除。如果没有包含过期的证书，当证书过期时，有关撤销的证书的信息会从 CRL 中删除。

7.1.1. User-Initiated Revocation

当最终用户提交证书撤销请求时，撤销过程的第一步是证书管理器来识别和验证最终用户，以验证用户是否试图撤销自己的证书，而不是属于其他人的证书。
在 SSL/TSL 客户端身份验证中，服务器要求最终用户提供一个与要撤销的主题名称相同的证书，并使用该证书进行身份验证。服务器通过将为客户端身份验证的证书中的主题名称映射到其内部数据库中的证书中的主题名称来验证撤销请求的真实性。只有证书映射到其内部数据库中的一个或多个有效或过期证书时，服务器才会撤销证书。
身份验证成功后，服务器会列出与为客户端身份验证提供的证书的主题名称匹配的有效或过期证书。然后，用户可以选择要撤销或撤销列表中所有证书的证书。

7.1.2. 吊销证书的原因

证书管理器可以撤销它发布的任何证书。通常接受拒绝 CRL 中通常会包括的证书的原因代码，如下所示：
  • 0.未指定；不给出特定原因。
  • 1.与证书关联的私钥被破坏。
  • 2.与签发证书的 CA 关联的私钥被破坏。
  • 3.证书的所有者不再与证书的签发者关联，并且不再具有与证书获取的访问权限或不再需要证书的权限。
  • 4.另一个证书替换这个证书。
  • 5.发布证书的 CA 已设计为操作。
  • 6.证书正在保留待处理的进一步操作。它被视为撤销，但将来可能会退出，以便证书处于活动状态并再次有效。
  • 8.证书将从 CRL 中删除，因为它已从 hold 中删除。这只在 delta CRL 中发生。
  • 9.证书被撤销，因为证书的所有者已撤回。
证书可由管理员、代理和结束实体撤销。具有代理权限的代理和管理员可以使用代理服务页面中的表单撤销证书。最终用户可以使用最终用户界面的撤销选项卡中的表单来撤销证书。最终用户只能撤销自己的证书，而代理和管理员可以撤销服务器发布的任何证书。还需要最终用户向服务器进行身份验证才能撤销证书。
每当撤销证书时，证书管理器都会更新其内部数据库中证书的状态。服务器使用内部数据库中的条目跟踪所有撤销的证书，并在配置时，它通过将其发布到中央存储库来通知其他用户中的证书不再有效。

7.1.3. CRL 颁发点

由于 CRL 可能会增长非常大，因此有几个方法可以最大程度减少检索和交付大型 CRL 的开销。其中一种方法对整个证书空间进行分区，并将一个单独的 CRL 与每个分区相关联。此分区被称为 CRL 发布点，即维护所有撤销的证书子集的位置。分区可以基于吊销的证书是 CA 证书，无论是因为特定原因吊销，还是使用特定配置文件发布。每个问题点都由其名称标识。
默认情况下，证书管理器会生成并发布一个 CRL，即 master CRL。发布点可以为所有证书、只针对 CA 签名证书或包括过期证书的所有证书生成 CRL。
定义了问题点后，可以将它们包含在证书中，以便需要检查证书的撤销状态的应用程序可以访问证书中指定的 CRL 发布点，而不是主 CRL 或主 CRL。由于发布点上维护的 CRL 比 master CRL 小，因此检查撤销状态会更快。
CRL 发行版点可以通过设置 CRLDistributionPoint 扩展来与证书关联。

7.1.4. delta CRLs

可以为任何定义的发布点发布 delta CRL。delta CRL 包含自上次更新到完整 CRL 后撤销的任何证书的信息。问题点的 delta CRL 通过启用 DeltaCRLIndicator 扩展来创建。

7.1.5. 发布 CRL

证书管理器可以将 CRL 发布到文件、兼容 LDAP 的目录或 OCSP 响应者。证书管理器中会发布 CRL 的频率，如 第 9 章 发布证书和 CRL 所述。
由于 CRL 可能非常大，发布 CRL 可能需要很长时间，且进程可能会中断。可将特殊发布者配置为通过 HTTP1.1 将 CRL 发布到文件，如果进程中断，CA 子系统的 Web 服务器可能会在其中断时恢复发布，而不必再次开始。这在 第 9.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 吊销

与 CMS (CMC)注册上的证书管理类似，CMC 吊销允许用户设置撤销客户端，并使用代理证书或使用匹配的 subjectDN 属性签署撤销请求。然后，用户可以向证书管理器发送已签名请求。
或者，也可以使用 Shared Secret Token 机制进行身份验证 CMC 撤销。详情请参阅 启用 CMC 共享 Secret 功能。
无论用户或代理是否签署请求还是是否使用 Shared Secret Token，证书管理器会在收到有效撤销请求时自动撤销证书。
证书系统为 CMC 撤销请求提供以下工具：
重要
红帽建议使用 CMCRequest 工具来生成 CMC 撤销请求，因为它提供了比 CMCRevoke 更多选项。

7.2.1. 使用 CMCRequest吊销证书

使用 CMCRequest 吊销证书：
  1. 为 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 cert9.db, key4.db and pkcs11.txt
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert9.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
  2. 创建 CMC 请求： 
    # CMCRequest /home/user_name/cmc-request.cfg
    如果命令成功，CMCRequest 工具会将 CMC 请求存储在请求配置文件中的 output 参数中指定的文件中。
  3. 创建配置文件，如 /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.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 cert9.db, key4.db and pkcs11.txt
#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 cert9.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 参数。
  4. 根据谁签署了请求，必须相应地设置 HttpClient 配置文件中的 servlet 参数：
    • 如果代理签署了请求，请设置： 
      servlet=/ca/ee/ca/profileSubmitCMCFull
    • 如果用户签署了请求，请设置： 
      servlet=/ca/ee/ca/profileSubmitSelfSignedCMCFull
  5. 提交 CMC 请求： 
    # HttpClient /home/user_name/cmc-submit.cfg
有关使用 CMCRequest 吊销证书的详情，请查看 CMCRequest(1) man page。

7.2.2. 使用 CMCRevoke吊销证书

CMC 吊销工具 CMCRevoke 用于通过代理的证书为撤销请求签名。此工具只需传递所需的信息 - 证书序列号、签发者名称和吊销原因 - 用于识别要撤销的证书，然后要求信息来标识执行撤销的 CA 代理（证书别名和数据库）。
证书被撤销的原因可以是以下任意一种（数字是传递给 CMCRevoke 工具的值）：
  • 0 - 未指定
  • 1 - 密钥已被破坏
  • 2 - CA 密钥已被破坏
  • 3 - 员工的关联变化
  • 4 - 证书已被取代
  • 5 - 停止操作
  • 6 - 证书处于冻结状态
命令行工具指南中详细介绍了可用的工具 参数。
7.2.2.1. 测试 CMCRevoke
  1. 为现有证书创建 CMC 撤销请求。 
    CMCRevoke -d/path/to/agent-cert-db -nnickname -iissuerName -sserialName -mreason -ccomment
    例如，如果包含代理证书的目录为 ~jsmith/.mozilla/firefox/，则证书的 nickname 为 AgentCert，证书的序列号为 22，如下所示： 
    CMCRevoke -d"~jsmith/.mozilla/firefox/" -n"ManagerAgentCert" -i"cn=agentAuthMgr" -s22 -m0 -c"test comment"
    注意
    在引号中包含空格的值。
    重要
    在参数及其值之间没有空格。例如，提供序列号 26 是 -s26，而不是 -s 26。
  2. 打开 end-entities 页面。 
    https://server.example.com:8443/ca/ee/ca
  3. 选择 Revocation 选项卡。
  4. 选择菜单中的 CMC Revoke 链接。
  5. 将 CMCRevoke 的输出粘贴到文本区域中。
  6. 从粘贴内容中删除 -----BEGIN NEW CERTIFICATE REQUEST----- 和 ----END NEW CERTIFICATE REQUEST-----。
  7. 点 Submit。
  8. 返回后的页面应确认已撤销正确的证书。

7.3. 发布 CRL

  1. 证书管理器使用其 CA 签名证书密钥来签署 CRL。要将单独的签名密钥对用于 CRL，请设置 CRL 签名密钥并更改证书管理器配置以使用此密钥为 CRL 签名。请参阅 第 7.3.4 节 “将 CA 设置为使用不同的证书来签名 CRL” 了解更多信息。
  2. 设置 CRL 发布点。为 master CRL 设置并启用问题点。

    图 7.1. 默认 CRL 颁发点

    默认 CRL 颁发点
    可以创建 CRL 的额外发布点。详情请查看 第 7.3.1 节 “配置颁发点”。
    发布点可以创建五类 CRL，具体取决于配置发布点时设置的选项来定义 CRL 将列出的内容：
    • Master CRL 包含从整个 CA 中撤销的证书列表。
    • ARL 是一个仅包含撤销的 CA 证书的授权撤销列表。
    • 带有过期证书的 CRL 包括 CRL 中已过期的证书。
    • 来自证书配置文件的 CRL 决定基于最初创建证书的配置集来包括撤销的证书。
    • 按原因代码的 CRLs 根据吊销原因代码决定撤销的证书。
  3. 为每个发布点配置 CRL。详情请查看 第 7.3.2 节 “为每个颁发点配置 CRL”。
  4. 设置为发布点配置的 CRL 扩展。详情请查看 第 7.3.3 节 “设置 CRL 扩展”。
  5. 通过为该发布点启用扩展，为发布点、Broata CRLIndicator 或 CRL Number 启用扩展来为发布点设置 delta CRL。
  6. 设置 CRLDistributionPoint 扩展，使其包含有关发布点的信息。
  7. 将 CRL 设置为文件、LDAP 目录或 OCSP 响应器。有关设置发布的详情，请查看 第 9 章 发布证书和 CRL。

7.3.1. 配置颁发点

发布点定义在新 CRL 中包含哪些证书。默认情况下，为 master CRL 创建一个 master CRL 发布点，其中包含证书管理器的所有撤销证书列表。
要创建新发布点，请执行以下操作：
  1. 打开证书系统控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，从左侧导航菜单中展开 Certificate Manager。然后选择 CRL Issuing Points。
  3. 若要编辑问题点，请选择发布点，然后单击 Edit。唯一可编辑的参数是发布点的名称，以及发布点是启用或禁用的。
    要添加发布点，请单击 Add。CRL Issuing Point Editor 窗口将打开。

    图 7.2. CRL 颁发点编辑器

    CRL 颁发点编辑器
    注意
    如果某些字段不足以读取内容，请通过拖动其中一个角来扩展窗口。
    填写以下字段：
    • 启用。如果选中，启用问题点；取消选择以禁用。
    • CRL 颁发点名称。为发布点指定名称；不允许空格。
    • 描述.描述问题点。
  4. 点确定。
要查看并配置新的发布点，请关闭 CA 控制台，然后再次打开控制台。新的问题点列在导航树中 CRL Issuing Points 条目下方。
为新的发布点配置 CRL，并设置与 CRL 搭配使用的任何 CRL 扩展。有关配置发布点的详情，请查看 第 7.3.2 节 “为每个颁发点配置 CRL”。有关设置 CRL 扩展的详情，请参阅 第 7.3.3 节 “设置 CRL 扩展”。创建的所有 CRL 都会出现在代理服务页面的 Update Revocation List 页面中。
注意
pkiconsole 已被弃用。

7.3.2. 为每个颁发点配置 CRL

为发布点配置信息，如生成间隔、CRL 版本、CRL 扩展和签名算法。必须为每个发布点配置 CRL。
  1. 打开 CA 控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在导航树中，选择 Certificate Manager，然后选择 CRL Issuing Points。
  3. 选择 Issuing Points 条目下的发布点名称。
  4. 通过在 Update 选项卡中提供发布点的信息来配置 CRL 如何和频率更新。此选项卡有两个部分： Update Schema 和 Update Frequency。
    • Update Schema 部分有以下选项：
      • 启用 CRL 生成。此复选框设定是否为该发布点生成 CRL。
      • 生成一个完整的 CRL 增量。此字段设置与更改数量相关的创建 CRL 的频率。
      • 在 完整 CRL 中延长下一次更新时间。这提供了一个选项，用于在生成的 CRL 中设置 nextUpdate 字段。nextUpdate 参数显示发布下一个 CRL 时的日期，无论它是完整还是 delta CRL。当使用 full 和 delta CRL 的组合时，在完整 CRL 中启用 扩展下一次更新时间将在完整 CRL 中进行 下一个Update 参数，当下一次完整 CRL 将被发布时，将生成完整的 CRL 参数。否则，完整的 CRL 中的 nextUpdate 参数将在发布下一个 delta CRL 时显示，因为 delta 将是要发布的下一个 CRL。
    • Update Frequency 部分在生成 CRL 并发布到目录时设置不同的间隔。
      • 每次从暂停中撤销或发布证书时。这会将证书管理器设置为在每次撤销证书时生成 CRL。证书管理器会在生成时尝试向配置的目录发出 CRL。如果 CRL 较大，生成 CRL 可能会消耗时间。将证书管理器配置为在每次撤销证书时生成 CRL，可能会持续与服务器联系；在此期间，服务器将无法使用它收到的任何更改来更新目录。
        不建议在标准安装中使用这个设置。应选择此选项以立即测试撤销，例如测试服务器是否向平面文件发出 CRL。
      • 更新位于 的 CRL。此字段会在应更新 CRL 时设置每日时间。要指定多次，请输入逗号分隔列表，如 01:50,04:55,06:55。要输入多个天数的调度，请输入以逗号分隔的列表来在同一天内设置时间，然后是一个分号分隔的列表，以标识不同天数的时间。例如，这会对周期的第 1 天（第 1 天）、50am、4:55am 和 6:55am，第 2 天（第 2 天、5am 和 5pm）进行撤销： 
        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 都需要您填写两个 宽限期 设置。因此，要选择这个选项，您需要首先选择 Update CRL per 选项，并为 Next update grace period 一 分钟 输入数字。
  5. Cache 选项卡设置缓存是否已启用以及缓存频率。

    图 7.3. CRL Cache Tab

    CRL Cache Tab
    • 启用 CRL 缓存。此复选框启用缓存，用于创建 delta CRL。如果禁用了缓存，则不会创建 delta CRLs。有关缓存的详情请参考 第 7.1 节 “关于撤销证书”。
    • 按更新缓存。此字段设置缓存写入内部数据库的频率。设置为 0， 以便在每次撤销证书时都会将缓存写入数据库。
    • 启用缓存恢复。此复选框允许恢复缓存。
    • 启用 CRL 缓存测试。此复选框为特定 CRL 发布点启用 CRL 性能测试。使用此选项生成的 CRL 不应在部署的 CA 中使用，因为为测试而发布的 CRL 包含只针对性能测试而生成的数据。
  6. Format 选项卡设置创建的 CRL 的格式和内容。CRL 格式和 CRL 内容有两个部分。

    图 7.4. CRL Format Tab

    CRL Format Tab
    • CRL Format 部分有两个选项：
      • 吊销列表签名算法 是允许密码加密 CRL 的下拉列表。
      • 允许 CRL v2 的扩展 是一个复选框，它为发布点启用 CRL v2 扩展。如果启用此功能，请设置 第 7.3.3 节 “设置 CRL 扩展” 中描述的所需的 CRL 扩展。
      注意
      必须打开扩展来创建 delta CRL。
    • CRL 内容 部分有三个复选框，用于设置 CRL 中包含的证书类型：
      • 包括过期的证书。这包括已撤销的证书。如果启用，证书过期后，有关撤销的证书的信息保留在 CRL 中。如果没有启用此功能，则在证书过期时会删除撤销的证书的信息。
      • 仅限 CA 证书。这仅包含 CRL 中的 CA 证书。选择这个选项会创建一个授权撤销列表(ARL)，它只列出撤销的 CA 证书。
      • 根据配置文件发布的证书。这只包含根据列出的配置集发布的证书 ; 要指定多个配置集，请输入以逗号分隔的列表。
  7. 点击 Save。
  8. 此发布点允许扩展，并可配置。详情请查看 第 7.3.3 节 “设置 CRL 扩展”。
注意
pkiconsole 已被弃用。

7.3.3. 设置 CRL 扩展

注意
只有为有问题的点选择了 Allow extensions for CRLs v2 复选框，则仅需要为发布点配置扩展。
创建问题点时，会自动启用三个扩展： CRLReason、InvalidityDate 和 CRLNumber。其他扩展可用，但默认禁用。这些可以被启用和修改。有关可用的 CRL 扩展的更多信息，请参阅 ???。
要配置 CRL 扩展，请执行以下操作：
  1. 打开 CA 控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在导航树中，选择 Certificate Manager，然后选择 CRL Issuing Points。
  3. 选择 Issuing Points 条目下的发布点名称，然后选择发布点下的 CRL 扩展 条目。
    右侧窗格显示 CRL Extensions Management 选项卡，它列出了配置的扩展。

    图 7.5. CRL 扩展

    CRL 扩展
  4. 若要修改规则，请选择它，然后单击 Edit/View。
  5. 大多数扩展有两个选项，启用它们并设置它们是否至关重要。有些需要更多信息。提供所有必需的值。有关每个扩展以及这些扩展的参数的完整信息，请参阅 ???。
  6. 点确定。
  7. 点 Refresh 查看所有规则的更新状态。
注意
pkiconsole 已被弃用。

7.3.4. 将 CA 设置为使用不同的证书来签名 CRL

有关如何通过编辑 CS.cfg 文件配置此功能的说明，请参阅 Red Hat Certificate System 规划、安装和部署指南中的设置 CA 来使用不同的证书签名 CRL 部分。

7.3.5. 从缓存生成 CRL

默认情况下，CRL 从 CA 的内部数据库生成。但是，可以收集撤销信息，因为证书被撤销并保留在内存中。然后，可以使用此撤销信息从内存中更新 CRL。绕过从内部数据库生成 CRL 所需的数据库搜索可显著提高性能。
注意
由于性能增强从缓存生成 CRL，请在大多数环境中启用 enableCRLCache 参数。但是，在生产环境中 不应 启用 Enable CRL cache 测试 参数。
7.3.5.1. 在控制台中从缓存配置 CRL 生成
注意
pkiconsole 已被弃用。
  1. 打开控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，展开 Certificate Manager 文件夹和 CRL 颁发点 子文件夹。
  3. 选择 MasterCRL 节点。
  4. 选择 Enable CRL cache。
  5. 保存更改。
7.3.5.2. 在 CS.cfg 中配置来自 Cache 的 CRL 生成
有关如何通过编辑 CS.cfg 文件配置此功能的说明，请参阅 Red Hat Certificate System 规划、安装和部署指南中的 从 CS.cfg 中的配置 CRL 生成 部分。

7.4. 设置 Full 和 Delta CRL 计划

CRL 定期生成。在 第 7.3.2 节 “为每个颁发点配置 CRL” 中的配置中设定该周期。
CRL 根据基于时间的调度进行。当证书被撤销、一天的特定时间或每这个分钟一次进行一次时，可以发布 CRL。
基于时间的 CRL 生成调度适用于生成的每个 CRL。CRL 有两种类型，即完全 CRL 和 delta CRL。完整的 CRL 具有每个撤销的证书的记录，而 delta CRL 则仅包含生成自最后一个 CRL （增量或完整）后撤销的证书。
默认情况下，在调度中的每个指定间隔都会生成完整的 CRL。通过生成内部 delta CRLs，有可能造成生成完整 CRL 之间的时间。生成间隔在 CRL 模式中配置，它会设置生成 delta 和 full 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 已被弃用。
  1. 打开控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，展开 Certificate Manager 文件夹和 CRL 颁发点 子文件夹。
  3. 选择 MasterCRL 节点。
  4. 在 Generate full CRL (s) 字段中输入所需的间隔。
  5. 通过指定证书撤销的 occasion、cyclical 间隔或设置更新的时间来设置更新频率：
    • 选择 Update CRL，每次撤销或从暂停复选框中释放 证书时。每次从 hold 选项撤销或发布证书时，Update CRL 都需要填写两个 Grace period 设置。这是一个已知问题，程序错误在 Red Hat Bugzilla 中被跟踪。
    • 选择 Update CRL，每次撤销或从暂停复选框中释放 证书时。
    • 选择 Update CRL at 复选框，并输入用逗号分开的特定时间，如 01:50,04:55,06:55。
    • 选择 Update CRL every 复选框并输入所需的间隔，如 240。
  6. 保存更改。
重要
每次从 hold 选项撤销或发布证书时，Update CRL 都需要填写两个 宽限期 设置。这是一个已知问题，程序错误在 Red Hat Bugzilla 中被跟踪。
注意
根据间隔更新 CRL 时，可能会发生调度偏移。通常，因为手动更新和 CA 重启，会进行偏移。
要防止调度偏移，请选中 Update CRL at 复选框并输入值。间隔更新将每 24 小时的值 重新同步 Update CRL。
根据间隔 更新 CRL 时，只能接受一个 Update CRL。

7.4.2. 在 CS.cfg 中为 CRL 配置 Update Intervals

有关如何通过编辑 CS.cfg 文件配置此功能的说明，请参阅 Red Hat Certificate System 规划、安装和部署指南中的 为 CRL 配置 Update Intervals 部分。

7.4.3. 多次配置 CRL 生成计划

默认情况下，CRL 生成计划覆盖 24 小时。另外，当默认启用 full 和 delta CRLs 时，会以特定间隔或所有 delta CRLs 代替每个第三个更新。
要在多个天数内设置 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 调度中更新。在 3 天开始周期。
注意
分号表示一天。以分号开始列表会导致生成 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 更新，其完整和 delta CRL 更新于 23:00。在第二天，delta CRL 在 02:00、05:00 和 21:00 中更新，其完整和 delta CRL 更新为 23:30。在第 3 天，周期会再次开始。
注意
分号和星号语法可在控制台中和手动编辑 CS.cfg 文件时工作。

7.5. 启用撤销检查

吊销 检查 意味着证书系统子系统验证证书是否有效且在代理或管理员尝试访问实例的安全接口时没有被撤销。这利用本地 OCSP 服务( CA 的内部 OCSP 服务或单独的 OCSP 响应器)检查证书的撤销状态。
第 7.6 节 “使用在线证书状态协议(OCSP)恢复器” 中涵盖了 OCSP 配置。
请参阅 红帽证书系统规划、安装和部署 指南中的在 CA 上启用自动撤销检查。
请参阅 红帽证书系统规划、安装和部署指南中的 为子系统启用证书撤销检查。

7.6. 使用在线证书状态协议(OCSP)恢复器

7.6.1. 设置 OCSP Responder

如果在配置了在线证书状态管理器时选择了安全域中的 CA，则不需要额外的步骤来配置 OCSP 服务。CA 的 CRL 发布会自动设置，其签名证书会在在线证书状态管理器的证书数据库中自动添加并信任。但是，如果选择了非安全域 CA，则必须在配置在线证书状态管理器后手动配置 OCSP 服务。
注意
在配置 OCSP Manager 所属的安全域中的每个 CA，而不是它的每个 CA 都会被 OCSP Manager 自动信任。CA 面板中配置的 CA 证书链中的每个 CA 都由 OCSP Manager 自动信任。安全域中的其他 CA，但不能手动信任证书链。
为安全域以外的证书管理器设置在线证书状态管理器：
  1. 为每个将发布到 OCSP 响应器的 CA 配置 CRL。
  2. 启用发布、设置发布程序，并在 OCSP 服务处理的每个 CA 中设置发布规则(第 9 章 发布证书和 CRL)。如果证书管理器发布到 LDAP 目录，并且将在线证书状态管理器设置为从该目录读取，则不需要此项。
  3. 证书配置文件必须配置为包含授权信息访问扩展，指向证书管理器侦听 OCSP 服务请求的位置(第 7.6.4 节 “启用证书管理器的内部 OCSP 服务”)。
  4. 配置 OCSP Responder。
  5. 配置这两个子系统后重新启动这两个子系统。
  6. 验证 CA 是否已正确连接到 OCSP 响应程序(第 7.6.2.1 节 “验证证书管理器和在线证书状态管理器连接”)。

7.6.2. 识别 CA 到 OCSP Responder

在将 CA 配置为向在线证书状态管理器发布 CRL 之前，必须在在线证书状态管理器的内部数据库中将 CA 识别为在线证书状态管理器。证书管理器使用与此证书关联的密钥对签名 CRL；在线证书状态管理器针对存储的证书验证签名。
注意
如果在配置了在线证书状态管理器时选择了安全域中的 CA，则不需要额外步骤来配置在线证书状态管理器来识别 CA；CA 签名证书会在在线证书状态管理器的证书数据库中自动添加和信任。但是，如果选择了非安全域 CA，则必须在配置了在线证书状态管理器后手动将 CA 签名证书添加到证书数据库中。
不需要为 CA 导入证书链，后者将其 CRL 发布到在线证书状态管理器。OCSP 服务需要证书链的唯一时间是在发布 CRL 时通过 SSL/TLS 身份验证连接到在线证书状态管理器。否则，在线证书状态管理器不需要完整的证书链。
但是，在线证书状态管理器必须具有为其证书数据库中的 CA 签名证书或单独的 CRL 签名证书的证书。OCSP 服务通过将 CRL 签名的证书与数据库中的证书进行比较来验证 CRL，而不是针对证书链。如果 root CA 及其子 CA 都向在线证书状态管理器发布 CRL，则在线证书状态管理器需要两个 CA 的 CA 签名证书。
要导入用于为 CA 发布的证书签名的 CA 或 CRL 签名证书，请执行以下操作：
  1. 从 CA 的端到端页面获取证书管理器的 base-64 CA 签名证书。
  2. 打开 Online Certificate Status Manager agent 页面。URL 格式为 https://hostname:SSLport/ocsp/agent/ocsp。
  3. 在左侧帧中，单击 Add Certificate Authority。
  4. 在表单中，将编码的 CA 签名证书粘贴到标记为 Base 64 编码证书（包括标头和页脚） 的文本区域中。
  5. 要验证证书是否已成功添加，请在左侧范围内单击 List Certificate Authority。
生成的表单应该显示有关新 CA 的信息。此 Update、Next Update 和 Requests Served Since Startup 字段应该会显示 0 值(0)。
7.6.2.1. 验证证书管理器和在线证书状态管理器连接
当证书管理器重启时，它会尝试连接到在线证书状态管理器的 SSL/TLS 端口。要验证证书管理器是否已与在线证书状态管理器通信，请检查 此 更新和 下一步更新 字段，该字段应该使用与在线证书状态管理器的最后一个通信的适当时间戳进行更新。Requests Served Since Startup 字段应该仍然显示零(0)，因为没有客户端试图查询 OCSP 服务以获取证书撤销状态。
7.6.2.2. 配置撤销信息存储：内部数据库
在线证书状态管理器将每个证书管理器的 CRL 存储在其内部数据库中，并将它用作 CRL 存储以验证证书的撤销状态。要更改在线证书状态管理器用来在其内部数据库中存储 CRL 的配置：
  1. 打开 Online Certificate Status Manager 控制台。 
    pkiconsole https://server.example.com:8443/ocsp
  2. 在 Configuration 选项卡中，选择 Online Certificate Status Manager，然后选择 Revocation Info Stores。
    右侧窗格中显示在线证书状态管理器可以使用的两个存储库；默认情况下，它会在其内部数据库中使用 CRL。
  3. 选择 defStore，然后单击 Edit/View。
  4. 编辑 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 更新时间的时间戳。
注意
pkiconsole 已被弃用。
7.6.2.3. 配置撤销信息存储：LDAP 目录
虽然 OCSP 管理器默认将 CA CRL 存储在其内部数据库中，但可以将其配置为改为使用发布到 LDAP 目录的 CRL。
重要
如果启用了 ldapStore 方法，则 OCSP 用户界面不会检查证书状态。
将在线证书状态管理器配置为使用 LDAP 目录：
  1. 打开 Online Certificate Status Manager 控制台。 
    pkiconsole https://server.example.com:8443/ocsp
  2. 在 Configuration 选项卡中，选择 Online Certificate Status Manager，然后选择 Revocation Info Stores。
    右侧窗格中显示在线证书状态管理器可以使用的两个存储库；默认情况下，它会在其内部数据库中使用 CRL。
  3. 要在 LDAP 目录中使用 CRL，请点击 Set Default 来启用 ldapStore 选项。
  4. 选择 ldapStore，然后单击 Edit/View。
  5. 设置 ldapStore 参数。
    • numConns.OCSP 服务应检查的 LDAP 目录的总数。默认情况下，它被设置为 0。设置此值会显示对应的主机、端口、baseDN 和 refreshInSec 字段的数量。
    • host.LDAP 目录的完全限定 DNS 主机名。
    • 端口。LDAP 目录的非 SSL/TLS 端口。
    • baseDN.开始搜索 CRL 的 DN。例如，O=example.com。
    • refreshInSec。连接刷新的频率。默认值为 86400 秒（每天）。
    • 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.在线证书状态管理器可以包含下一次 CRL 更新时间的时间戳。
注意
pkiconsole 已被弃用。
7.6.2.4. 测试 OCSP 服务设置
通过执行以下操作来测试证书管理器是否可以正确服务 OCSP 请求：
  1. 在浏览器或客户端中打开撤销检查。
  2. 从为 OCSP 服务启用的 CA 请求证书。
  3. 批准请求。
  4. 将证书下载到浏览器或客户端。
  5. 确保 CA 由浏览器或客户端信任。
  6. 检查证书管理器内部 OCSP 服务的状态。
    打开 CA 代理服务页面，然后选择 OCSP Services 链接。
  7. 测试独立的在线证书状态管理器子系统。
    打开 Online Certificate Status Manager 代理服务页面，然后单击 List Certificate Authority 链接。
    该页面应当显示有关配置为向在线证书状态管理器发布 CRL 的证书管理器的信息。该页面还总结了在线证书状态管理器自上次开始以来的活动。
  8. 吊销证书。
  9. 在浏览器或客户端中验证证书。服务器应返回证书已被撤销。
  10. 再次检查证书管理器的 OCSP-service 状态，以验证是否发生以下问题：
    • 浏览器向证书管理器发送 OCSP 查询。
    • 证书管理器向浏览器发送 OCSP 响应。
    • 使用该响应来验证证书并返回其状态的浏览器无法验证证书。
  11. 再次检查独立的 OCSP 服务子系统以验证是否发生以下问题：
    • 证书管理器将 CRL 发布到在线证书状态管理器。
    • 浏览器向在线证书状态管理器发送 OCSP 响应。
    • 在线证书状态管理器向浏览器发送 OCSP 响应。
    • 使用该响应来验证证书并返回其状态的浏览器无法验证证书。

7.6.3. 为 Bad Serial Numbers 设置响应

OCSP 响应器在确定证书是否有效前检查证书的撤销状态和过期日期，默认情况下，IADP 不会验证证书的其他信息。
notFoundAsGood 参数设置 OCSP 如何使用无效序列号处理证书。此参数默认为启用，这意味着如果证书存在错误序列号但证书有效，则 OCSP 会返回证书的状态。
要获得基于错误的序列号以及撤销状态的 OCSP 检查和拒绝证书，请更改 notFoundAsGood 设置。在这种情况下，OCSP 返回 UNKNOWN 状态，并带有带有错误的序列号的证书。客户端将解释为错误，并相应地响应。
  1. 打开 Online Certificate Status Manager 控制台。 
    pkiconsole https://server.example.com:8443/ocsp
  2. 在 Configuration 选项卡中，选择 Online Certificate Status Manager，然后选择 Revocation Info Stores。
  3. 选择 defStore，然后单击 Edit/View。
  4. 编辑 notFoundAsGood 值。选择复选框意味着 OCSP 会返回 GOOD 值，即使证书的序列号不正确。取消选择复选框意味着 OCSP 发送一个 UNKNOWN 值，客户端可能会认为是错误。
  5. 重启 OCSP Manager。 
    ]# pki-server restart instance-name
注意
pkiconsole 已被弃用。

7.6.4. 启用证书管理器的内部 OCSP 服务

证书管理器具有内置的 OCSP 服务，可供 OCSP 兼容客户端用来直接查询证书管理器有关证书的撤销状态。安装证书管理器后，会发布 OCSP 签名证书，并默认启用 OCSP 服务。这个 OCSP 签名证书用于签署对 OCSP 服务请求的所有响应。由于内部 OCSP 服务检查证书管理器内部数据库中存储的证书状态，因此发布不必配置为使用此服务。
客户端可以通过证书管理器的非 SSL/TLS 最终用户端口查询 OCSP 服务。当查询证书的撤销状态时，证书管理器会搜索其内部数据库的证书，检查其状态并响应客户端。由于证书管理器具有它发布的所有证书的实时状态，因此这种撤销检查的方法是最准确的。
每个 CA 的内置 OCSP 服务都会在安装时打开。但是，要使用此服务，CA 需要使用授权信息访问扩展发布证书。
  1. 进入 CA 的端到端页面。例如： 
    https://server.example.com:8443/ca/ee/ca
  2. 查找 CA 签名证书。
  3. 在证书中查找授权信息访问扩展，并记录 Location URIName 值，如 https://server.example.com:8443/ca/ocsp。
  4. 更新注册配置文件，以启用授权信息访问扩展，并将 Location 参数设置为证书管理器的 URI。有关编辑证书配置文件的详情，请参考 第 3.2 节 “设置证书配置文件”。
  5. 重启 CA 实例。 
    ]# pki-server restart instance-name
注意
要禁用证书管理器的内部 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 数据库 安全数据库位置（默认：当前目录）
-h hostname OCSP 服务器主机名（默认为 example.com）
-p port OCSP 服务器端口号（默认： 8080）
-t path OCSP 服务路径（默认：/ocsp/ee/ocsp）
-c nickname CA 证书 nickname (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 请求

可以使用 GET 方法向在线证书状态管理器提交小于 255 字节的 OCSP 请求，如 RFC 6960 所述。通过 GET 提交 OCSP 请求：
  1. 为证书生成一个 OCSP 请求，该请求正在查询。例如： 
    ]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64

MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
  2. 将 URL 粘贴到 Web 浏览器的地址栏中，以返回状态信息。浏览器必须能够处理 OCSP 请求。 
    https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
  3. OCSP Manager 使用浏览器可以解释的证书状态进行响应。可能的状态有 GOOD、REVOKED 和 UNKNOWN。
或者，使用 curl 等工具从命令行运行 OCSP，以发送请求和 openssl 来解析响应。例如：
  1. 为证书生成一个 OCSP 请求，该请求正在查询。例如： 
    ]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64

MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
  2. 使用 curl 连接到 OCSP Manager 来发送 OCSP 请求。 
    curl https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE= > ocspresp.der
  3. 使用 openssl 解析响应： 
    openssl ocsp -respin ocspresp.der -resp_text
对于由带有授权信息访问扩展的 7.1 CA 发布的证书使用 GET 方法发送到 OCSP，需要创建一个重定向来将请求转发到适当的 URL，如 第 7.6.7 节 “为证书系统 7.1 和 Earlier 中发布的证书设置重定向” 所述。

7.6.7. 为证书系统 7.1 和 Earlier 中发布的证书设置重定向

OCSP 用户页面的位置在 URL 中指定，文件为 /ocsp/ee/ocsp/，在证书系统 10 或证书系统 8.1 中与证书系统 7.1 中的位置不同，这只是 /ocsp/。为了使 7.1 或更早的 CA 发布的证书以及授权信息访问扩展发送到 OCSP，请创建一个重定向以将请求转发到适当的 URL。
注意
只需要设置重定向，才能管理由带有授权信息访问扩展的 7.1 或更早的 CA 发布的证书。如果证书由更新的版本证书管理器或不包含授权信息访问扩展发布，则不需要此配置。
  1. 停止 OCSP Responder。 
    ]# pki-server stop instance-name
  2. 进入 OCSP 的最终用户 Web 应用程序目录。例如： 
    ]# cd /var/lib/pki-ocsp/webapps/ocsp
  3. 更改为 OCSP Web 应用目录的 ROOT 文件夹中的 ROOT/WEB-INF/ 目录。例如： 
    ]# cd /var/lib/pki-ocsp/webapps/ocsp/ROOT/WEB-INF/
  4. 在 OCSP Web 应用目录的 ROOT 文件夹中创建并打开 lib/ 目录。 
    ]# mkdir lib
]# cd lib/
  5. 创建链接到 /usr/share/java/pki/cms.jar JAR 文件的符号链接。例如： 
    ]# ln -s /usr/share/java/pki/cms.jar cms.jar
  6. 移到主 Web 应用目录。例如： 
    ]# cd /var/lib/pki-ocsp/webapps/ocsp/
  7. 重命名当前实例(ocsp)目录。例如： 
    ]# mv /var/lib/pki-ocsp/webapps/ocsp/ocsp /var/lib/pki-ocsp/webapps/ocsp/ocsp2
  8. 更改到原始 ocsp/ 目录中的 WEB-INF/ 目录。例如： 
    ]# cd  /var/lib/pki-ocsp/webapps/ocsp/ocsp/WEB-INF
  9. 在原始 ocsp/WEB-INF/ 目录中，编辑 web.xml 文件并添加 eeocspAddCRL 和 csadmin-wizard servlets 之间的行映射。 
       <servlet-mapping>
      <servlet-name>  ocspOCSP  </servlet-name>
      <url-pattern>   /ee/ocsp/*  </url-pattern>
   </servlet-mapping>
  10. 在 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>
  11. 编辑 /var/lib/pki-ocsp/conf/context.xml 文件，更改以下行： 
    <Context>
 to 
<Context crossContext="true" >
  12. 编辑 /var/lib/pki-ocsp/webapps/ocsp/ocsp2/services.template 文件并更改以下行： 
    result.recordSet[i].uri);
 to 
result.recordSet[i].uri + "/");
  13. 启动 OCSP 实例。 
    ]# pki-server start instance-name

第 8 章 管理 PKI ACME Responder

本章论述了如何管理 PKI ACME Responder。
有关如何设置 PKI ACME Responder 的详情，请参考 Red Hat Certificate System Planning、安装和部署指南中的 设置 PKI ACME Responder 章节。

8.1. 启用/禁用 ACME 服务

属于 Administrators 组的用户可以在 ACME 响应器中启用或禁用服务。用户可以通过基本身份验证或客户端证书身份验证进行身份验证。
  • 要使用基本身份验证启用或禁用 ACME 服务，请指定用户名和密码： 
    $ pki -u <username> -p <password> acme-<enable/disable>
  • 要使用客户端证书身份验证启用或禁用 ACME 服务，请指定证书 nickname 和 NSS 数据库密码： 
    $ pki -n <nickname> -c <password> acme-<enable/disable>

8.2. 检查 PKI ACME Responder 的状态

  • 要检查 ACME 响应器的状态，请运行以下命令： 
    $ pki acme-info
Status: Available
Terms of Service: https://www.example.com/acme/tos.pdf
Website: https://www.example.com
CAA Identities: example.com
External Account Required:false
    如果服务被禁用，命令会显示以下结果： 
    $ pki acme-info
Status: Unavailable
注意
实际输出取决于 metadata.conf 配置文件中配置的内容。

部分 III. 管理 CA 服务的其他配置

第 9 章 发布证书和 CRL

Red Hat Certificate System 为证书颁发机构包括可自定义的发布框架，使证书颁发机构能够发布证书、证书撤销列表(CRL)和其他与证书相关的对象到任何受支持的软件仓库： LDAP 兼容目录、平面文件和在线验证机构。本章解释了如何配置证书管理器，将证书和 CRL 发布到文件、到目录以及在线证书状态管理器。
配置发布的一般过程如下：
  1. 配置发布到文件、LDAP 目录或 OCSP 响应器。
    根据要使用的位置数量，可以有一个发布者或多个发布者。位置可以通过证书和 CRL 或更严格的定义（如证书类型）分割。规则决定要发布的类型以及与发布者关联的位置。
  2. 设置规则以确定将哪些证书发布到该位置。激活证书或 CRL 匹配的任何规则，因此同一证书可以发布到文件和 LDAP 目录，方法是匹配基于文件的规则并与基于目录的规则匹配。
    可以为每个对象类型设置规则：CA 证书、CRL、用户证书和跨对证书。禁用所有不使用的规则。
  3. 配置 CRL。在发布 CRL 之前，必须配置 CRL。请参阅 第 7 章 吊销证书并颁发 CRL。
  4. 在设置发布程序、映射程序和规则后启用发布。发布后，服务器会立即开始发布。如果没有完全配置发布程序、映射程序和规则，发布程序可能无法正常工作，或根本都无法正常工作。

9.1. 关于发布

证书系统能够向文件或 LDAP 目录发布证书，并将 CRL 发布到文件、LDAP 目录或 OCSP 响应器。
为获得更大的灵活性，可以发布特定类型的证书或 CRL，以单一格式或全部三种格式发布。例如，CA 证书只能发布到某个目录，不能发布到文件，用户可以将用户证书发布到文件和目录。
注意
OCSP 响应程序只提供有关 CRL 的信息；证书不会发布到 OCSP 响应程序。
可以为证书文件和 CRL 文件设置不同的发布位置，以及不同类型的证书文件或不同类型的 CRL 文件的不同发布位置。
同样，不同类型的证书和不同类型的 CRL 可以发布到目录中的不同位置。例如，来自公司 West Coast 划分的用户的证书可以在目录的一个分支中发布，而 East Coast 划分中的用户的证书可以发布到目录中的另一个分支。
启用发布后，每次发布、更新或撤销证书或 CRL 时，都会调用发布系统。证书或 CRL 由规则评估，以查看是否与规则中设置的 type 和 predicate 匹配。type 指定对象是否为 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 发布，需要确定用户条目的位置。映射程序用于决定要发布的条目。映射程序可以包含条目的确切 DN，一些变量可以关联证书获取的信息，以创建 DN，或者足够信息搜索条目中唯一属性或一组属性，以确定条目的正确 DN。
吊销证书时，服务器使用发布规则从 LDAP 目录或从文件系统中查找和移除对应的证书。
当证书过期时，服务器可以从配置的目录中删除该证书。服务器不会自动执行此操作，必须将服务器配置为运行适当的作业。详情请查看 第 13 章 设置自动化作业。
设置发布涉及配置发布程序、映射程序和规则。

9.1.1. publishers

publishers 指定发布证书和 CRL 的位置。在发布到文件时，发布者指定文件系统发布目录。在发布到 LDAP 目录时，发布者指定存储证书或 CRL 的目录的属性；映射程序用于确定条目的 DN。对于每个 DN，会为生成 DN 设置不同的公式。启用 LDAP 发布时，指定 LDAP 目录的位置。将 CRL 发布到 OCSP 响应器时，发布者指定在线证书状态管理器的主机名和 URI。

9.1.2. Mappers

映射程序 仅在 LDAP 发布中使用。映射程序根据证书或证书请求的信息为条目构建 DN。服务器包含证书的主题名称和证书请求的信息，并且需要知道如何使用此信息为该条目创建 DN。映射程序提供了一个公式，用于将可用信息转换为 DN 或目录中可以搜索的一些唯一信息，以获取条目的 DN。

9.1.3. 规则

文件、LDAP 和 OCSP 发布 的规则 告诉服务器是否发布证书或 CRL。首先，规则通过为规则设置 type 和 predicate 来定义要发布的内容、证书或 CRL 匹配特定特征。然后，规则通过与发布者关联，并使用映射器指定发布方法和位置。
规则可以像 PKI 部署的要求一样简单或复杂，并足够灵活以适应不同的场景。

9.1.4. 发布到文件

服务器可以将证书和 CRL 发布到平面文件，然后可以导入到任何存储库，如关系数据库。当服务器配置为发布证书和 CRL 到文件时，发布的文件为 DER 编码的二进制 Blob、base-64 编码的文本 Blob 或两者。
  • 对于服务器问题的每个证书，它创建一个文件，其中包含 DER 编码或 base-64 编码格式的证书。每个文件都命名为 cert-serial_number.der 或 cert-serial_number.b64。serial_number 是文件中包含的证书的序列号。例如，带有序列号 1234 的 DER 编码证书的文件名是 cert-1234.der。
  • 每次服务器生成 CRL 时，它都会创建一个文件，其中包含以 DER 编码的或 base-64 编码格式的新 CRL。根据格式，每个文件都命名为 issue_point_name- this_update.der 或 issue_point_name- this_update.b64。issue_point_name 标识发布 CRL 的 CRL 发布点，并且 this_update 指定从文件中包含的 CRL 的相关更新值生成的值。例如，DER 编码的 CRL 的文件名，其值为 this Update:phone 28 15:36:00 PST 2020，是 MasterCRL-20200128-153600.der。

9.1.5. OCSP 发布

证书系统 OCSP 服务有两种形式，即证书管理器和在线证书状态管理器的内部服务。内部服务检查证书管理器的内部数据库，以报告证书的状态。内部服务没有设置为发布，它使用存储在其内部数据库中的证书来确定证书的状态。在线证书状态管理器检查证书管理器发送给的 CRL。为发送 CRL 的每个位置设置发布者，并为每种版本的 CRL 发送一个规则。
有关 OCSP 服务的详情，请参考 第 7.6 节 “使用在线证书状态协议(OCSP)恢复器”。

9.1.6. LDAP 发布

在 LDAP 发布 中，服务器使用 LDAP 或 LDAPS 将证书、CRL 和其他与证书相关的对象发布到目录。它发布的目录的分支称为 发布目录。
  • 对于服务器问题的每个证书，它会在用户条目的指定属性中以 DER 编码格式包含证书的 Blob。证书作为 DER 编码的二进制 blob 发布。
  • 每次服务器生成 CRL 时，它都会在 CA 条目的指定属性中创建一个包含新 CRL 的 Blob。
服务器可以使用 LDAP 协议或 LDAP 通过 SSL (LDAPS)协议将证书和 CRL 发布到 LDAP 兼容目录，应用程序可以通过 HTTP 检索证书和 CRL。支持通过 HTTP 检索证书和 CRL 可让一些浏览器自动从服务器接收常规更新的目录导入最新的 CRL。浏览器可以使用 CRL 自动检查所有证书，以确保它们没有被撤销。
要使 LDAP 发布正常工作，用户条目必须存在于 LDAP 目录中。
如果因为某种原因，服务器和发布目录不同步，特权用户（管理员和代理）也可以手动启动发布过程。具体说明请查看 第 9.12.2 节 “在目录中手动更新 CRL”。

9.2. 配置发布到文件

配置发布的一般流程涉及设置发布者，以将证书或 CRL 发布到特定位置。根据要使用的位置数量，可以有一个发布者或多个发布者。位置可以通过证书和 CRL 或更精细的定义（如证书类型）分割。规则决定要发布的类型以及与发布者关联的位置。
发布到文件，只需将 CRL 或证书发布到给定主机上的文本文件。
必须为每个发布位置创建和配置发布者；发布者不会自动创建发布者。要将所有文件发布到单个位置，请创建一个发布者。要发布到不同的位置，请为每个位置创建一个发布程序。位置可以包含对象类型，如用户证书或对象类型的子集，如 West Coast 用户证书。
创建用于发布到文件的发布者：
  1. 登录证书管理器控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择 Publishing，然后选择 Publishs。
    Tailoring s Management 选项卡（列出配置的 publisher 实例）在右侧打开。
  3. 单击 Add 以打开 Select \":\" Plug-in Implementation 窗口，该窗口列出了注册的发布者模块。
  4. 选择 FileBasedPublisher 模块，然后打开编辑器窗口。
    这是可让证书管理器向文件发布证书和 CRL 的模块。
  5. 配置发布证书的信息：
    • 发布者 ID，它是一个没有空格的字母字符串，如 PublishCertsToFile
    • 证书管理器应发布文件的目录的路径。该路径可以是绝对路径，也可以相对于证书系统实例目录。例如： /export/CS/certificates。
    • 要发布的文件类型，选中 DER 编码文件的复选框、base-64 编码文件或两者。
    • 对于 CRL，时间戳的格式。发布的证书在其文件名中包含序列号，而 CRL 使用时间戳。
    • 对于 CRL，是否在文件中生成链接以进入最新的 CRL。如果启用，该链接假定要与扩展一起使用的 CRL 问题点的名称将在 crlLinkExt 字段中提供。
    • 对于 CRL，是否压缩(zip) CRL 和要使用的压缩级别。
配置发布程序后，为发布的证书和 CRL 配置规则，如 第 9.5 节 “创建规则” 所述。
注意
pkiconsole 已被弃用。

9.3. 配置发布到 OCSP

配置发布的一般流程涉及设置发布者，以将证书或 CRL 发布到特定位置。根据要使用的位置数量，可以有一个发布者或多个发布者。位置可以通过证书和 CRL 或更精细的定义（如证书类型）分割。规则决定要发布的类型以及与发布者关联的位置。
发布到 OCSP 管理器是一种将 CRL 发布到特定位置以进行客户端验证的方法。
必须为每个发布位置创建和配置发布程序；发布到 OCSP 响应者不会自动创建发布者。创建一个发布者，将所有内容发布到单个位置，或为每个要发布 CRL 的位置创建一个发布者。每个位置都可以包含不同类型的 CRL。

9.3.1. 启用使用客户端身份验证发布到 OCSP

  1. 登录证书管理器控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择 Publishing，然后选择 Publishs。
  3. 单击 Add 以打开 Select \":\" Plug-in Implementation 窗口，该窗口列出了注册的发布者模块。
  4. 选择 OCSPPublisher 模块，然后打开编辑器窗口。这是发布者模块，使证书管理器能够向在线证书状态管理器发布 CRL。
    • 发布者 ID 必须是没有空格的字母字符串，如 PublishCertsToOCSP。
    • 主机 可以是完全限定域名，如 ocspResponder.example.com，也可以是 IPv4 或 IPv6 地址。
    • 默认路径是将 CRL 发送到的目录，如 /ocsp/agent/ocsp/addCRL。
    • 如果使用客户端身份验证（选中enableClientAuth ），则 nickname 字段提供了用于身份验证的证书的 nickname 字段。此证书必须已存在于 OCSP 安全数据库中；这通常是 CA 子系统证书。
  5. 在 OCSP Manager 中为 CA 创建用户条目。用户用于在发送新的 CRL 时向 OCSP 进行身份验证。需要两方面：
    • 在 CA 服务器后命名 OCSP 用户条目，如 CA-hostname-EEport。
    • 使用 publisher 配置中指定的任何证书作为 OCSP 用户帐户中的用户证书。这通常是 CA 的子系统证书。
    第 15.3.2.1 节 “创建用户” 中涵盖了设置子系统用户。
配置发布程序后，为发布的证书和 CRL 配置规则，如 第 9.5 节 “创建规则” 所述。
注意
pkiconsole 已被弃用。

9.4. 配置发布到 LDAP 目录

配置发布的一般流程涉及设置发布者，以将证书或 CRL 发布到特定位置。根据要使用的位置数量，可以有一个发布者或多个发布者。位置可以通过证书和 CRL 或更精细的定义（如证书类型）分割。规则决定要发布的类型以及与发布者关联的位置。
配置 LDAP 发布与其他发布过程类似，以及配置目录的额外步骤：
  1. 配置要发布证书的目录服务器。某些属性必须添加到条目中，而且必须配置绑定身份和身份验证方法。
  2. 为公布的每种对象配置发布者：CA 证书、跨对证书、CRL 和用户证书。publisher 声明用于存储对象的属性。默认设置的属性是 X.500 标准属性，用于存储每种对象类型。此属性可以在发布程序中更改，但通常不需要更改 LDAP 发布者。
  3. 设置映射程序，以启用条目的 DN 从证书的主题名称中派生。这通常不需要为 CA 证书、CRL 和用户证书设置。对于一种证书，可以有多个映射程序。例如，这可用于发布来自位于目录树不同部分公司不同部分的两组用户的证书。为每个组创建一个映射程序，以指定树的不同分支。
    有关设置映射程序的详情，请参考 第 9.4.3 节 “创建映射程序”。
  4. 创建规则以将发布程序连接到映射程序，如 第 9.5 节 “创建规则” 所述。
  5. 启用发布，如 第 9.6 节 “启用发布” 所述。

9.4.1. 配置 LDAP 目录

在发布证书和 CRL 之前，必须将目录服务器配置为使用发布系统。这意味着用户条目必须具有允许它们接收证书信息的属性，必须创建条目来代表 CRL。
  1. 为 CA 设置条目。要使证书管理器发布其 CA 证书和 CRL，该目录必须包含 CA 的条目。
    TIP
    配置 LDAP 发布后，证书管理器会在目录中自动创建或转换 CA 的条目。这个选项在 CA 和 CRL mapper 实例中设置，并默认启用。如果目录限制了证书管理器在目录中创建条目，请在这些映射器实例中关闭此选项，并在目录中手动为 CA 添加条目。
    将 CA 条目添加到目录中时，根据 CA 的 DN 选择条目类型：
    • 如果 CA 的 DN 从 cn 组件开始，请为 CA 创建新的 person 条目。选择其他类型的条目可能无法指定 cn 组件。
    • 如果 CA 的 DN 从 ou 组件开始，请为 CA 创建新的 organizationalunit 条目。
    条目不必位于 pkiCA 或 Certification Authority 对象类中。证书管理器将通过发布其 CA 的签名证书，将此条目转换为 pkiCA 或 Certification Authority 对象类。
    注意
    pkiCA 对象类在 RFC 4523 中定义，而 certified Authority 对象类在(obsolete) RFC 2256 中定义。根据 Directory 服务器使用的模式定义，任何对象类都可以接受。在某些情况下，两个对象类都可用于相同的 CA 条目。
    有关创建目录条目的更多信息，请参阅 Red Hat Directory Server 文档。
  2. 将正确的架构元素添加到 CA 和用户条目条目中。
    要使证书管理器向目录发布证书和 CRL，必须使用特定属性和对象类进行配置。
    对象类型 模式 原因
    端到端证书 userCertificate;binary (attribute)
    这是证书管理器向其发布证书的属性。
    这是一个多值属性，每个值都是一个 DER 编码的二进制 X.509 证书。名为 inetOrgPerson 的 LDAP 对象类允许此属性。strongAuthenticationUser 对象类允许此属性，并可与其他对象类结合使用，以允许将证书发布到其他对象类的目录条目中。证书管理器不会自动将此对象类添加到对应的目录服务器的 schema 表中。
    如果它找到的目录对象不允许 userCertificate;binary 属性，添加或删除证书会失败。
    CA 证书 caCertificate;binary (attribute)
    这是证书管理器向其发布证书的属性。
    证书管理器在服务器启动时将自己的 CA 证书发布到自己的 LDAP 目录条目。条目对应于证书的签发者名称。
    这是 pkiCA 或 Certification Authority 对象类的 必要属性。如果证书管理器可以找到 CA 的目录条目，则证书管理器会将此对象类添加到 CA 的目录条目中。
    CRL certificateRevocationList;binary (attribute)
    这是证书管理器向发布 CRL 的属性。
    证书管理器将 CRL 发布到自己的 LDAP 目录条目。条目对应于证书的签发者名称。
    这是 pkiCA 或 Certification Authority 对象类的属性。属性的值是 DER 编码的二进制 X.509 CRL。CA 的条目必须已包含 CRL 的 pkiCA 或 Certification Authority 对象类，才能发布到该条目。
    delta CRL deltaRevocationList;binary (attribute)
    这是证书管理器向发布 delta CRL 的属性。证书管理器将 delta CRL 发布到自己的 LDAP 目录条目，与完整 CRL 分开。delta CRL 条目对应于证书管理器的签发者名称。
    此属性属于 deltaCRL 或 certified Authority-V2 对象类。属性的值是 DER 编码的二进制 X.509 delta CRL。
  3. 为证书管理器设置绑定 DN，用于访问目录服务器。
    证书管理器用户必须具有目录的读写权限，才能向目录发布证书和 CRL，以便证书管理器可以使用与证书相关的信息以及带有 CA 证书和 CRL 相关信息的 CA 条目修改用户条目。
    绑定 DN 条目可以是以下之一：
    • 具有写入访问权限的现有 DN，如目录管理器。
    • 授予写入访问权限的新用户。条目可以被证书管理器的 DN 标识，如 cn=testCA, ou=Research Dept, o=Example 公司, st=California, c=US。
      注意
      仔细考虑为此用户授予哪些特权。此用户可以通过为帐户创建 ACL 限制到目录的内容。有关授予对证书管理器条目的写入权限的说明，请参阅目录服务器文档。
  4. 设置目录身份验证方法，以向目录服务器进行身份验证。有三个选项：基本身份验证（简单用户名和密码）、没有客户端身份验证的 SSL （简单用户名和密码）；以及 SSL （基于证书）的 SSL。
    有关设置这些与服务器通信方法的说明，请参阅 Red Hat Directory Server 文档。

9.4.2. 配置 LDAP 站

证书管理器创建、配置和启用与 LDAP 发布关联的一组发布者。默认发布者（用于 CA 证书、用户证书、CRL 和跨修复证书）已符合存储证书和 CRL 的 X.500 标准属性，不需要更改。
表 9.1. LDAP 过程
publisher 描述
LdapCaCertPublisher 将 CA 证书发布到 LDAP 目录。
LdapCrlPublisher 将 CRL 发布到 LDAP 目录。
LdapDeltaCrlPublisher 将 delta CRLs 发布到 LDAP 目录。
LdapUserCertPublisher 将所有类型的最终用户证书发布到 LDAP 目录。
LdapCrossCertPairPublisher 将自签名证书发布到 LDAP 目录。

9.4.3. 创建映射程序

映射程序仅与 LDAP 发布一起使用。映射程序定义了证书的主题名称和发布证书的目录条目的 DN 之间的关系。证书管理器需要从证书或证书请求派生条目的 DN，以便它能够决定要使用哪个条目。mapper 定义用户条目的 DN 和证书的主题名称或其他输入信息之间的关系，以便可以在目录中确定和找到条目的确切 DN。
配置后，证书管理器会自动创建一组定义最常见的关系的映射程序。默认映射程序列在 表 9.2 “默认映射程序” 中。
表 9.2. 默认映射程序
mapper 描述
LdapUserCertMap 在 目录中找到用户条目的正确属性，以发布用户证书。
LdapCrlMap 在 目录中找到 CA 条目的正确属性，以发布 CRL。
LdapCaCertMap 在 目录中找到 CA 条目的正确属性，以发布 CA 证书。
要使用默认映射程序，请通过指定 DN 模式并在目录中创建 CA 条目来配置每个宏。要使用其他映射程序，请创建并配置映射器实例。如需更多信息，请参阅 第 C.2 节 “映射程序插件模块 ”。
  1. 登录证书管理器控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择 Publishing，然后选择 Mappers。
    Mappers Management 标签页（列出配置的映射程序）在右侧打开。
  3. 若要创建新映射程序实例，请单击 Add。此时会打开 Select Mapper Plugin Implementation 窗口，它列出了注册的映射程序模块。选择一个模块并编辑它。有关这些模块的完整信息，请参考 第 C.2 节 “映射程序插件模块 ”。
  4. 编辑 mapper 实例，然后单击 OK。
    有关每个映射程序的详情，请查看 第 C.2 节 “映射程序插件模块 ”。
注意
pkiconsole 已被弃用。

9.4.4. 完成配置：规则并启用

为 LDAP 发布程序配置映射程序后，为发布的证书和 CRL 配置规则，如 第 9.5 节 “创建规则” 所述。
配置完成后，启用发布，如 第 9.6 节 “启用发布” 所述。

9.5. 创建规则

规则决定了在哪些位置发布哪些证书对象。规则独立工作，而不是在 tandem 中工作。要发布的证书或 CRL 会根据每个规则进行匹配。激活它匹配的规则。这样，可以将同一证书或 CRL 发布到文件、在线证书状态管理器，并通过匹配基于文件的规则、OCSP 规则和匹配基于目录的规则来发送到 LDAP 目录。
可以为每个对象类型设置规则：CA 证书、CRL、用户证书和跨对证书。对于不同类型的证书或不同类型的 CRL，规则可以更加详细。
规则首先根据与对象的规则中设置的 type 和 predicate 匹配。发布匹配的对象由与规则关联的发布者和映射程序决定。
为证书管理器发布的每种证书创建规则。
通过执行以下操作来修改发布规则：
  1. 登录证书管理器控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择 Publishing，然后选择 Rules。
    Rules Management 选项卡（列出配置的规则）在右侧打开。
  3. 若要编辑现有规则，请从列表中选择该规则，然后单击 Edit。这将打开 Rule Editor 窗口。
  4. 要创建规则，请单击 Add。这将打开 Select Rule Plug-in Implementation 窗口。
    选择 Rule 模块。这是唯一的默认模块。如果注册了任何自定义模块，它们也可用。
  5. 编辑规则。
    • type.这是规则适用的证书类型。对于 CA 签名证书，值为 cacert。对于跨林信任，值为 xcert。对于所有其他证书类型，值为 certs。对于 CRL，指定 crl。
    • predicate。这会为规则适用的证书或 CRL 发布点设置 predicate 值。CRL 发布点、delta CRL 和证书的 predicate 值列在 表 9.3 “predicate 表达式” 中。
    • 启用。
    • 映射器.发布到文件时不需要映射程序；仅 LDAP 发布需要它们。如果此规则与发布到 LDAP 目录的发布程序关联，请在此处选择适当的映射程序。对于所有其他形式的发布，请留空。
    • 发布者.设置要与规则关联的发布程序。
表 9.3 “predicate 表达式” 列出可用于识别 CRL 发布点和 delta CRLs 和证书配置文件的 predicates。
表 9.3. predicate 表达式
predicate Type predicate
CRL 颁发点
issuingPointId==Issuing_Point_Instance_ID && isDeltaCRL==[true|false]
要仅发布 master CRL，请设置 isDeltaCRL==false。要仅发布 delta CRL，请设置 isDeltaCRL==true。要发布这两者，请为 master CRL 设置一条规则，并为 delta CRL 设置另一个规则。
证书配置文件
profileId==profile_name
要根据用于发布它们的配置集发布证书，请将 profileId== 设置为配置集名称，如 caServerCert。
注意
pkiconsole 已被弃用。

9.6. 启用发布

发布只能为文件、只有 LDAP 或两者都启用。在设置发布程序、规则和映射程序后，应启用发布程序。启用后，服务器会尝试开始发布。如果在启用前没有正确配置发布，发布可能会带来不必要的行为，或者可能会失败。
注意
配置 CRL。在发布 CRL 之前，必须配置 CRL。请参阅 第 7 章 吊销证书并颁发 CRL。
  1. 登录证书管理器控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择 Publishing。
    右侧窗格显示发布到符合 LDAP 的目录的详细信息。
  3. 若要仅启用发布到文件，请选择 Enable Publishing。
  4. 要启用 LDAP 发布，请选择 Enable Publishing 和 Enable Default LDAP Connection。
    在 Destination 部分中，设置 Directory 服务器实例的信息。
    • 主机名.如果为 SSL 客户端经过身份验证的通信配置了目录服务器，该名称必须与 Directory 服务器 SSL 服务器证书的主题 DN 中的 cn 组件匹配。
      主机名可以是完全限定域名或 IPv4 或 IPv6 地址。
    • 端口号.
    • 目录管理器 DN。这是具有目录管理器权限的目录条目的可分辨名称(DN)。证书管理器使用此 DN 访问目录树并发布到目录。为此 DN 设置的访问控制决定了证书管理器是否可以执行发布。仅针对发布系统实际需要写入的属性，可以创建另一个具有有限读写权限的 DN。
    • 密码。这是 CA 用于绑定到发布证书或 CRL 的 LDAP 目录的密码。证书管理器将此密码保存到其 password.conf 文件中。例如： 
      CA LDAP Publishing:password
      注意
      标识发布密码(CA LDAP Publishing)的参数名称在 ca.publish.ldappublish.ldap.ldapauth.bindPWPrompt 参数中的证书管理器 CS.cfg 文件中设置，可以对其进行编辑。
    • 客户端证书.这会将证书管理器用于 SSL 客户端身份验证的证书设置为发布目录。默认情况下，证书管理器使用其 SSL 服务器证书。
    • LDAP 版本.选择 LDAP 版本 3。
    • 身份验证.证书管理器向目录服务器进行身份验证的方式。选择是 基本身份验证 和 SSL 客户端身份验证。
      如果将目录服务器配置为基本身份验证或在没有客户端身份验证的情况下 SSL 通信，请选择 基本身份验证 并为 Directory Manager DN 和密码指定值。
      如果为与客户端身份验证的 SSL 通信配置了目录服务器，请选择 SSL 客户端身份验证 和 Use SSL 通信 选项，并且识别证书管理器必须用于 SSL 客户端对目录进行身份验证的证书。
服务器尝试连接到目录服务器。如果信息不正确，服务器会显示错误消息。
注意
pkiconsole 已被弃用。

9.7. 启用发布队列

注册过程的一部分包括将发布的证书发布到任何目录或文件。这基本上，关闭初始证书请求。但是，向外部网络发布证书可能会显著减慢问题，这会使请求保持打开。
为避免这种情况，管理员可以启用 发布队列。发布队列将发布操作（可能涉及外部 LDAP 目录）与请求和注册操作分开，后者使用单独的请求队列。请求队列会立即更新，以显示注册过程已完成，发布队列则以网络流量的速度发送信息。
发布队列设置定义的、有限的线程数量，它们发布生成的证书，而不是为每个批准的证书打开新的线程。
发布队列默认为禁用。它可以在 CA 控制台中启用，以及启用发布。
注意
pkiconsole 已被弃用。
注意
虽然发布队列默认为禁用，但如果 控制台中 启用了 LDAP 发布，则队列会自动启用。否则，可以手动启用队列。

图 9.1. 启用 Publishing Queue

启用 Publishing Queue
TIP
通过编辑 CS.cfg 文件启用发布队列，管理员可以设置用于发布操作的其他选项，如用于发布操作和队列页面大小的线程数量。
有关如何编辑 CS.cfg 文件配置此功能的说明，请参阅 Red Hat Certificate System 规划、安装和部署指南中的 启用和配置 发布 队列 部分。

9.8. 设置可恢复的 CRL 下载

证书系统提供中断 CRL 下载的选项，以便平稳恢复。这可以通过通过 HTTP 将 CRL 作为纯文本发布。此下载 CRL 的方法在检索 CRL 时具有灵活性，并降低整个网络拥塞。

9.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
表 9.4 “用于检索 CRL 的 wget 选项” 中总结了 wget 的相关参数。
表 9.4. 用于检索 CRL 的 wget 选项
参数 描述
无参数 检索完整的 CRL。
-N 检索比本地副本更新的 CRL (delta CRL)。
-c 检索部分下载的文件。
--no-check-certificate 跳过连接的 SSL，因此不需要在主机和客户端之间配置 SSL。
-d 打印调试信息。

9.9. 发布跨证书

跨对证书可以作为 LDAP 目录或文件的 crossCertificatePair 条目发布；这默认是启用的。如果禁用了此功能，可以通过证书管理器控制台重新启用它：
  1. 打开 CA 控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，选择左侧窗格中的 Certificate Manager 链接，然后选择 Publishing 链接。
  3. 单击 Publishing 下的 Rules 链接。这会在右侧打开 Rules Management 窗格。
  4. 如果规则存在并已禁用，请选中 启用 复选框。如果删除了该规则，请单击 Add 并创建新规则。
    1. 从 类型 下拉菜单中选择 xcerts。
    2. 确保选择了 enable 复选框。
    3. 从 mapper 下拉菜单中选择 LdapCaCertMap。
    4. 从 publisher 下拉菜单中选择 LdapCrossCertPairPublisher。
发布规则中指定的 映射程序 和 发布程序 都列在 CA 控制台左侧导航窗口中的 Publishing 链接下。在默认情况下，映射程序 LdapCaCertMap 指定了 crossCertificatePair 存储在 LdapCaSimpleMap LDAP 条目。默认情况下，发布者 LDAPCrossPairPublisher 将属性设置为 CA 条目中的跨密钥对证书到 crossCertificatePair;binary。
有关使用跨对证书的详情，请参考 第 17.5 节 “使用跨证书”。
有关创建跨对证书配置文件的更多信息，请参阅 Red Hat Certificate System 规划、安装和部署指南中的 配置跨Pair 配置集 部分。
注意
pkiconsole 已被弃用。

9.10. 测试发布到文件

验证证书管理器是否在发布证书，并且 CRL 正确发布到文件：
  1. 打开 CA 的端到端页面，并请求证书。
  2. 如果需要，通过代理服务页面批准请求。
  3. 从终端实体页面检索证书，并将证书下载到浏览器中。
  4. 检查服务器是否生成了包含证书的 DER 编码文件。
    打开应发布证书的二进制 blob 的目录。证书文件应命名为 cert-serial_number.der。
  5. 使用 Binary 到 ASCII 工具，将 DER 编码的证书转换为其基本 64 编码格式。有关此工具的详情，请参考 BtoA (1) 手册页。 
    BtoA input_file output_file
    INPUT_ FILE 设置包含 DER 编码证书的文件的路径，output_file 设置要编写 base-64 编码证书的文件的路径。
  6. 打开 ASCII 文件；base-64 编码证书与显示的证书类似： 
    -----BEGIN CERTIFICATE-----
MMIIBtgYJYIZIAYb4QgIFoIIBpzCCAZ8wggGbMIIBRaADAgEAAgEBMA0GCSqGSIb3DQEBBAUAMFcxC
AJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aWhfyyuougjgjjgmkgjkgmjg
fjfgjjjgfyjfyj9ucyBDb3Jwb3JhdGlvbjpMEaMBgGA1UECxMRSXNzdWluZyhgdfhbfdpffjphotoo
gdhkBBdXRob3JpdHkwHhcNOTYxMTA4MDkwNzM0WhcNOTgxMTA4MDkwNzMM0WjBXMQswCQYDVQQGEwJ
VUzEsMCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yY2F0aW9ucyBDb3Jwb3Jhd
GlvbjpMEaMBgGA1UECxMRSXNzdWluZyBBdXRob3JpdHkwHh
-----END CERTIFICATE-----
  7. 使用 Pretty Print Certificate 工具将基本 64 编码的证书转换为可读形式。有关此工具的更多信息，请参阅 PrettyPrintCert (1) 手册页。 
    PrettyPrintCert input_file [output_file]
    INPUT_ FILE 设置包含 base-64 编码证书的 ASCII 文件的路径，以及 output_file （可选）设置要写入证书的文件的路径。如果没有设置输出文件，证书信息将写入标准输出。
  8. 将输出与发布的证书进行比较；检查证书中的序列号与文件名中使用的序列号。
    如果所有内容都匹配，则证书管理器配置正确，以将证书发布到文件。
  9. 吊销证书。
  10. 检查服务器是否生成了包含 CRL 的 DER 编码文件。
    打开服务器要发布 CRL 作为二进制 blob 的目录。CRL 文件应具有名称，格式为 crl-this_update.der。this_update 指定来自 CRL 的时间 依赖此更新 变量的值。
  11. 使用 Binary 到 ASCII 工具，将 DER 编码的 CRL 转换为其基本 64 编码格式。 
    BtoA input_file output_file
  12. 使用 Pretty Print CRL 工具将基本 64 编码的 CRL 转换为可读形式。 
    PrettyPrintCrl input_file [output_file]
  13. 比较输出。

9.11. 查看证书和 CRL 发布到文件

证书和 CRL 可以发布到两种类型的文件：base-64 编码或 DER 编码的。可以使用 dumpasn1 工具或 PrettyPrintCert 或 PrettyPrintCrl 工具将文件转换为用户友善格式来查看这些文件的内容。
查看 base-64 编码文件中的内容：
  1. 将 base-64 文件转换为 二进制文件。例如： 
    AtoB /tmp/example.b64 /tmp/example.bin
  2. 使用 PrettyPrintCert 或 PrettyPrintCrl 工具将二进制文件转换为用户友善格式。例如： 
    PrettyPrintCert example.bin example.cert
要查看 DER 编码文件的内容，只需使用 DER 编码的文件运行 dumpasn1、 PrettyPrintCert 或 PrettyPrintCrl 工具。例如： 
PrettyPrintCrl example.der example.crl

9.12. 更新目录中的证书和 CRL

如果在 Directory 服务器停机时发布或撤销证书，则证书管理器和发布目录可能会变为不同步。当目录服务器备份时，需要手动发布或取消发布已发布或取消发布的证书。
要查找与目录不同步的证书 - 不在目录中的有效证书，且仍然在目录中撤销或过期的证书 - 证书管理器会在其内部数据库中保留证书记录是否已发布到目录中。如果证书管理器和发布目录不同步，请使用证书管理器代理服务页面中的 Update Directory 选项将发布目录与内部数据库同步。
以下选择可用于将目录与内部数据库同步：
  • 在内部数据库中搜索没有同步的证书，并发布或取消发布。
  • 发布目录服务器停机时发布的证书。同样，未发布已撤销或在目录服务器停机时过期的证书。
  • 根据序列号发布或取消发布一系列证书，从序列号 xx 到序列号 yy。
证书管理器的发布目录只能由证书管理器代理手动更新。

9.12.1. 手动更新目录中的证书

证书管理器代理服务页面中的 Update Directory Server 表单可用于使用与证书相关的信息手动更新目录。这个表单启动以下操作的组合：
  • 使用证书更新目录。
  • 从目录中删除过期的证书。
    通过调度自动化作业，可以从发布目录中删除过期的证书。详情请查看 第 13 章 设置自动化作业。
  • 从目录中删除撤销的证书。
通过执行以下操作来手动更新目录：
  1. 打开 证书管理器代理服务页面。
  2. 选择 Update Directory Server 链接。
  3. 选择适当的选项，然后单击 Update Directory。
    证书管理器开始使用其内部数据库中的证书信息更新目录。如果更改非常大，则更新目录可能需要大量时间。在此期间，任何通过证书管理器所做的更改（包括签发或撤销的任何证书）都可能不包括在更新中。如果在更新目录时发布或撤销任何证书，请再次更新目录以反映这些更改。
目录更新完成后，证书管理器会显示状态报告。如果进程中断，服务器会记录错误消息。
如果证书管理器作为 root CA 安装，则在使用代理接口更新具有有效证书的目录时，可以使用为用户证书设置的发布规则来发布 CA 签名证书。这可返回对象类违反错误或其他映射器中的错误。选择适当的序列号范围来排除 CA 签名证书可以避免出现这个问题。CA 签名证书是 root CA 发布的第一个证书。
  • 通过将 predicate 参数的值改为 profileId!=caCACert，来修改用户证书的默认发布规则。
  • 使用 LdapCaCertPublisher publisher 插件模块添加另一个规则，将 predicate 参数设置为 profileId=caCACert，以发布从属 CA 证书。

9.12.2. 在目录中手动更新 CRL

证书管理器代理服务页面中的证书撤销列表 表单使用 CRL 相关信息手动更新目录。
通过执行以下操作手动更新 CRL 信息：
  1. 打开 证书管理器代理服务页面。
  2. 选择 Update Revocation List。
  3. 点 Update。
证书管理器开始在其内部数据库中使用 CRL 更新目录。如果 CRL 较大，更新目录需要相当长的时间。在此期间，对 CRL 所做的任何更改都不会包含在更新中。
更新目录后，证书管理器会显示状态报告。如果进程中断，服务器会记录错误消息。

9.13. 注册自定义映射程序和过期插件模块

新的映射程序或发布程序插件模块可以在证书管理器发布框架中注册。可以删除不需要的映射程序或发布程序插件模块。在删除模块之前，删除基于此模块的所有规则。
  1. 创建自定义作业类。在本例中，自定义发布者插件名为 MyPublisher.java。
  2. 编译新类。 
    javac -d . -classpath $CLASSPATH MyPublisher.java
  3. 在 CA 的 WEB-INF web 目录中创建一个目录来保存自定义类，以便 CA 可以访问它们。 
    mkdir /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes
  4. 将新插件文件复制到新的 类 目录中，并将所有者设置为证书系统用户(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
  5. 注册插件。
    1. 登录证书管理器控制台。 
      pkiconsole https://server.example.com:8443/ca
    2. 在 Configuration 选项卡中，从左侧的导航树中选择 Certificate Manager。选择 Publishing。
    3. 要注册映射程序模块，请选择 Mappers，然后选择 映射程序插件注册 选项卡。
      要注册发布者模块，请选择 站s，然后选择 附件 插件注册 选项卡。
    4. 要注册插件，请点击 Register。
    5. 设置插件名称和插件类名称。类名称为实现 Java 类的路径。如果这个类是软件包的一部分，请包含软件包名称。例如，若要在名为 com.customplugins 的软件包中注册名为 customMapper 的类，名称为 com.customplugins.customMapper。
注意
pkiconsole 已被弃用。

第 10 章 注册证书的身份验证

本章介绍了如何注册最终用户证书、创建和管理服务器证书、证书系统中可用的身份验证方法，以用于注册最终实体证书，以及如何设置这些身份验证方法。
注册 是将证书发布到结束实体的过程。这个过程正在创建和提交请求，验证请求它的用户，然后批准请求并发布证书。
用于验证最终实体的方法决定了整个注册过程。证书系统可以验证实体的三种方法：
  • 在 代理批准的 注册中，最终用户请求将发送到代理以进行批准。代理批准证书请求。
  • 在 自动注册 中，最终用户请求使用插件进行身份验证，然后处理证书请求；代理不涉及注册过程。
  • 在 CMC 注册 中，第三方应用程序可以创建由代理签名的请求，然后自动处理。
证书管理器最初是为代理批准的注册和 CMC 身份验证配置。通过配置其中一个身份验证插件模块来启用自动注册。可以在子系统的单一实例中配置多个身份验证方法。
注意
当通过配置自动通知为任何身份验证方法签发证书时，可以自动将电子邮件发送到结束实体。有关通知的详情，请查看 第 12 章 使用自动通知。

10.1. 配置代理应用注册

证书管理器最初是为代理批准的注册配置。最终实体发出请求，它发送到代理批准的代理队列。代理可以修改请求、更改请求的状态、拒绝请求或批准请求。批准请求后，已签名请求将发送到证书管理器进行处理。证书管理器处理请求并发布证书。
代理批准的注册方法不可配置。如果没有为任何其他注册方法配置证书管理器，服务器会自动将所有与证书相关的请求发送到等待代理批准的队列。这样可确保所有缺少身份验证凭据的请求发送到代理批准的请求。
要使用代理批准的注册，请将身份验证方法留空到配置文件的 .cfg 文件中。例如： 
auth.instance_id=

10.2. 自动注册

在自动注册中，当用户通过身份验证插件模块中设置的方法成功进行身份验证时，就会立即处理最终用户注册请求；不需要代理批准。提供以下身份验证插件模块：
  • 基于目录的注册。最终实体使用其用户 ID 和密码或其 DN 和密码对 LDAP 目录进行身份验证。请参阅 第 10.2.1 节 “设置基于目录的身份验证”。
  • 基于 PIN 的注册。结束实体使用在其目录条目中设置的用户 ID、密码和 PIN 对 LDAP 目录进行身份验证。请参阅 第 10.2.2 节 “设置基于 PIN 的注册”。
  • 基于证书的验证。某些类型的实体 - 最终用户和其他实体（如服务器或令牌）都使用 CA 发布的证书来证明其身份。这最常用于续订，其中显示了原始证书来验证续订过程。请参阅 第 10.2.3 节 “使用基于证书的身份验证”。
  • AgentCertAuth.如果提交了请求作为子系统代理进行身份验证，此方法会自动批准证书请求。用户通过提供代理证书来作为代理进行身份验证。如果显示的证书被子系统识别为代理证书，则 CA 会自动处理证书请求。
    这种形式的自动身份验证可与证书配置文件关联，以注册服务器证书。
    此插件默认为启用，且没有参数。
  • 基于平面文件的注册。专门用于路由器(SCEP)注册，使用文本文件，其中包含 IP 地址、主机名或其他标识符列表，通常是随机 PIN。路由器通过其 ID 和 PIN 验证 CA，然后将提供的凭据与文本文件的身份列表进行比较。请参阅 第 10.2.4 节 “配置平面文件身份验证”。

10.2.1. 设置基于目录的身份验证

UidPwdDirAuth 和 UdnPwdDirAuth 插件模块实施基于目录的身份验证。最终用户通过提供用户 ID 或 DN 和密码来为 LDAP 目录进行身份验证来注册证书。
  1. 创建 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. 选择 UidPwdDirAuth 用于用户 ID 和密码身份验证，或者选择 UdnPwdDirAuth 用于 DN 和密码身份验证。
    5. 在 Authentication Instance Editor 窗口中填写以下字段：
      • 身份验证实例 ID。接受默认实例名称，或输入一个新名称。
      • dnpattern.指定代表主题名称模式的字符串，从目录属性和条目 DN 中公式。
      • ldapStringAttributes.指定应被视为最终实体 验证的 LDAP 字符串属性列表。如果指定，与这些属性对应的值将从身份验证令牌复制到身份验证令牌中，证书配置文件使用它来生成主题名称。为此参数输入值是可选的。
      • ldapByteAttributes.指定应该被视为最终实体的 LDAP 字节(binary)属性列表。如果指定，与这些属性对应的值将从身份验证令牌复制到身份验证令牌中，供其他模块使用，如向用户的证书添加其他信息。
        为此参数输入值是可选的。
      • ldap.ldapconn.host.指定身份验证目录的完全限定 DNS 主机名。
      • ldap.ldapconn.port.指定身份验证目录侦听请求的 TCP/IP 端口；如果选择了 ldap.ldapconn.secureConn. 复选框，则这应该是 SSL 端口号。
      • ldap.ldapconn.secureConn.指定身份验证目录侦听证书系统请求的端口的类型 SSL 或非 SSL。如果这是 SSL 端口，请选择。
      • ldap.ldapconn.version.指定 LDAP 协议版本，可以是 2 或 3。默认值为 3，因为所有在版本 3.x 之后的 Directory 服务器都是 LDAPv3。
      • ldap.basedn.指定搜索身份验证目录的基本 DN。服务器使用 HTTP 输入中的 uid 字段的值（用户在注册表单中输入什么用户）和基本 DN 来构建 LDAP 搜索过滤器。
      • ldap.minConns.指定允许到身份验证目录的最小连接数。允许的值是 1 到 3。
      • ldap.maxConns.指定允许到身份验证目录的最大连接数。允许的值为 3 到 10。
    6. 点确定。身份验证实例已设置并启用。
  2. 通过为特定证书设置策略，将证书配置文件设置为用于注册用户。通过在证书配置文件中配置输入来自定义注册表单，并包含插件所需信息的输入来验证用户。如果默认输入不包含需要收集的所有信息，请提交使用第三方工具创建的请求。
    有关配置配置集的详情，请参考 第 3.7.2 节 “将 LDAP 目录属性值和其他信息插入到主题 Alt 名称”。
注意
pkiconsole 已被弃用。
设置 Bound 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 文件中使用的标签或提示；它也是 cms.passwordlist 和 authPrefix 选项下使用的名称。
  • 在 password.conf 中使用其密码从 CS.cfg 添加标签或提示： 
    externalLDAP=your_password
设置外部授权
也可以配置基于目录的身份验证插件，以评估用于身份验证的用户的组成员资格。要以这种方式设置插件，必须在 CS.cfg 中配置以下选项：
  • groupsEnable 是一个布尔值选项，它允许检索组。默认值为 false。
  • 基于组的组 是组的基本 DN。当它与默认的 基于值不同时，需要指定它。
  • groups 是组的 DN 组件。默认值为 ou=groups。
  • groupObjectClass 是以下组对象类之一： groupofuniquenames,groupofnames.默认值为 groupofuniquenames。
  • groupUseridName 是组对象成员属性中的用户 ID 属性的名称。默认值为 cn。
  • useridName 是用户 ID DN 组件的名称。默认值为 uid。
  • searchGroupUserByUserdn 是一个布尔值选项，它决定是否为 userdn 或 ${groupUserIdName}=${uid} 属性搜索组对象成员属性。默认值为 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"

10.2.2. 设置基于 PIN 的注册

基于 PIN 的身份验证涉及为 LDAP 目录中的每个用户设置 PIN，将这些 PIN 分发到用户，然后让用户在填充证书请求时提供 PIN 及其用户 ID 和密码。然后，用户会使用其用户 ID 和密码以及 LDAP 条目中的 PIN 根据 LDAP 目录进行身份验证。当用户成功验证时，请求会自动处理，并签发新证书。
证书系统提供了一个工具 setpin，它将 PIN 的必要模式添加到目录服务器，并为每个用户生成 PIN。
PIN 工具执行以下功能：
  • 将 PIN 的必要模式添加到 LDAP 目录中。
  • 为设置的 PIN 管理器用户添加具有读写权限的 PIN 管理器用户。
  • 设置 ACI，以便在使用 PIN 后允许 PIN 移除，为 PIN 管理器授予 PIN 的读写权限，并防止用户创建或更改 PIN。
  • 在每个用户条目中创建 PIN。
注意
此工具记录在 证书系统命令行工具指南 中。
  1. 使用 PIN 工具添加 PINs 所需的模式，将 PIN 添加到用户条目，然后将 PIN 分发到用户。
    1. 打开 /usr/share/pki/native-tools/ 目录。
    2. 在文本编辑器中打开 setpin.conf 文件。
    3. 按照文件中介绍的说明进行适当的更改。
      通常，需要更新的参数是目录服务器的主机名、目录管理器的绑定密码和 PIN 管理器的密码。
    4. 使用指向 setpin.conf 文件的 optfile 选项运行 setpin 命令。 
      setpin optfile=/usr/share/pki/native-tools/setpin.conf
      该工具使用新属性（默认为 pin）和新对象类（默认为 pinPerson）、创建一个 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。
      TIP
      首先，测试工具没有 写入 选项来生成 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 命令会导致固定以纯文本形式存储在用户 LDAP 条目中。
    8. 在完成设置所需的身份验证方法后，使用输出文件向用户发送 PIN。
      确认基于 PIN 的注册正常工作后，向用户提供 PIN，以便在注册期间使用它们。要保护 PIN 的隐私，请使用安全、带外交付方法。
  2. 在证书配置文件中为特定证书设置策略以注册用户。有关证书配置文件策略的详情，请查看 第 3 章 为颁发证书（证书配置文件）进行规则。
  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 字节(binary)属性列表。如果指定，与这些属性对应的值将从身份验证令牌复制到身份验证令牌中，供其他模块使用，如向用户的证书添加其他信息。
        为此参数输入值是可选的。
      • ldap.ldapconn.host.指定身份验证目录的完全限定 DNS 主机名。
      • ldap.ldapconn.port.指定身份验证目录侦听证书系统请求的 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 客户端对要删除 PIN 的身份验证的证书 nickname。确保证书有效，并由身份验证目录的证书数据库中信任的 CA 签名，并且身份验证目录的 certmap.conf 文件中已被正确配置，以正确将证书映射到目录中的 DN。这是仅删除 PIN 所必需的。
      • ldap.ldapAuthentication.authtype.指定身份验证类型、基本身份验证或 SSL 客户端身份验证，以便从身份验证目录中删除 PIN。
        • Basic auth 指定基本身份验证。使用此选项时，为 ldap.ldapAuthentication.bindDN 和密码 参数输入正确的值；服务器使用来自 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. 点确定。
  4. 通过在证书配置文件中配置输入来自定义注册表单。包含插件验证用户所需的信息。如果默认输入不包含需要收集的所有信息，请提交使用第三方工具创建的请求。
注意
pkiconsole 已被弃用。

10.2.3. 使用基于证书的身份验证

基于证书的验证 是在显示证书来验证请求者的身份并自动验证和验证要提交的请求时。这最常用于续订进程，当原始证书由用户、服务器和应用程序提供，且该证书用于验证请求。
在有些情况下，使用基于证书的验证进行初始请求证书可能很有用。例如，令牌可以使用通用证书批量加载，然后用于在用户注册其用户证书时验证用户，或者用户可以被签发签名证书，然后用来验证其对加密密钥的请求。
基于证书的验证模块 SSLclientCertAuth 会被默认启用，此身份验证方法可在任何自定义证书配置文件中引用。

10.2.4. 配置平面文件身份验证

使用随机生成的 PIN 注册并验证路由器证书。CA 使用 flatFileAuth 身份验证模块来处理包含路由器身份验证凭据的文本文件。
10.2.4.1. 配置 flatFileAuth 模块
已为 SCEP 注册配置了平面文件身份验证，但可以编辑扁平文件的位置及其身份验证参数。
  1. 打开 CA 控制台。 
    pkiconsole https://server.example.com:8443/ca
  2. 在 Configuration 选项卡中，在导航树中选择 Authentication。
  3. 选择 flatFileAuth 身份验证模块。
  4. 点 Edit/View。
  5. 要更改文件位置和名称，请重置 fileName 字段。
    要更改身份验证名称参数，请将 keyAttributes 值重置为 SCEP 注册表单提交的另一个值，如 CN。也可以通过逗号（如 UID、CN ）分隔多个 name 参数来使用它们。要更改 password 参数名称，请重置 authAttributes 字段。
  6. 保存编辑。
注意
pkiconsole 已被弃用。
10.2.4.2. 编辑 flatfile.txt
相同的 flatfile.txt 文件用于验证每个 SCEP 注册。每次向路由器发布新 PIN 时，都必须手动更新此文件。
默认情况下，此文件位于 /var/lib/pki/pki-ca/ca/conf/ 中，并为每个身份验证条目指定两个参数：站点 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.

10.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 请求通常用于获取用户的第一个签名证书，稍后用于获取其他证书。详情请查看 第 10.4 节 “CMC SharedSecret 身份验证”。
默认情况下，以下注册配置集使用 CMCUserSignedAuth 插件：
  • caFullCMCUserSignedCert
  • caECFullCMCUserSignedCert
  • caFullCMCSharedTokenCert
  • caECFullCMCSharedTokenCert

10.4. CMC SharedSecret 身份验证

使用 Shared Secret 功能让用户向服务器发送未签名的 CMC 请求。例如，如果用户想要获取第一个签名证书，则需要此项。此签名证书稍后可用于为此用户的其他证书签名。

10.4.1. 创建共享 Secret 令牌

Red Hat Certificate System Planning, Installation, and Deployment Guide 中的 Shared Secret Workflow 部分描述了使用共享 Secret 令牌时的工作流。根据情况，最终用户或管理员会创建共享 Secret 令牌。
注意
要使用共享机密令牌，证书系统必须使用 RSA 颁发保护证书。详情请参阅 RHCS 规划、安装和部署指南中的启用 CMC 共享 Secret 功能部分。
要创建共享 Secret Token，请输入： 
# CMCSharedToken -d /home/user_name/.dogtag/ -p NSS_password \
	     -s "CMC_enrollment_password" -o