2.3. 证书系统架构概述

虽然每个服务都提供不同的服务，但所有 RHCS 子系统(CA、KRA、OCSP、TKS、TPS)共享一个通用架构。以下架构图显示了所有这些子系统共享的通用架构。

2.3.1. Java Application Server

Java 应用服务器是运行服务器应用程序的 Java 框架。证书系统设计为在 Java 应用服务器内运行。目前，Tomcat 8 唯一支持的 Java 应用程序服务器。以后可能会添加对其他应用服务器的支持。如需更多信息，请参阅 http://tomcat.apache.org/。
每个证书系统实例都是 Tomcat 服务器实例。Tomcat 配置存储在 server.xml 中。以下链接提供有关 Tomcat 配置的更多信息： https://tomcat.apache.org/tomcat-8.0-doc/config/
每个证书系统子系统（如 CA 或 KRA）都部署为 Tomcat 中的 Web 应用程序。Web 应用程序配置存储在 web.xml 文件中，该文件在 Java Servlet 3.1 规范中定义。详情请查看 https://www.jcp.org/en/jsr/detail?id=340。
证书系统配置本身存储在 CS.cfg 中。
有关这些文件的实际位置，请参阅 第 2.3.15 节 “实例布局”。

2.3.2. Java 安全管理器

Java 服务可以选择使用安全管理器，为应用程序定义不安全和安全操作。安装子系统后，它们会自动启用 Security Manager，这意味着每个 Tomcat 实例都会从运行 Security Manager 开始。
如果实例是通过运行 pkispawn 创建的，并使用覆盖配置文件（在其自己的 Tomcat 部分下指定 pki_security_manager=false 选项）创建，则安全管理器会被禁用。
可以按照以下流程从已安装的实例禁用安全管理器： 
  1. # pki-server stop instance_name
    或（如果使用 nuxwdog watchdog） 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
  2. 打开 /etc/sysconfig/instance_name 文件，并设置 SECURITY_MANAGER="false" 
  3. # pki-server start instance_name
    或（如果使用 nuxwdog watchdog） 
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
当实例启动或重启时，会在以下文件中由 pkidaemon 构建或重新构建 Java 安全策略： 
/usr/share/pki/server/conf/catalina.policy
/usr/share/tomcat/conf/catalina.policy
/var/lib/pki/$PKI_INSTANCE_NAME/conf/pki.policy
/var/lib/pki/$PKI_INSTANCE_NAME/conf/custom.policy
然后，它被保存到 /var/lib/pki/instance_name/conf/catalina.policy 中。

2.3.3. 接口

2.3.3.1. Servlet 接口

每个子系统包含允许与子系统的不同部分交互的接口。所有子系统共享一个通用管理界面，并有一个代理接口，允许代理执行分配给它们的任务。CA 子系统有一个端点接口，它允许终端实体注册到 PKI。OCSP Responder 子系统有一个最终用户接口，允许终端化和应用程序检查当前证书撤销状态。最后，TPS 有一个 operator 接口。
虽然应用服务器提供连接入口点，但证书系统通过提供特定于每个接口的 servlet 来完成接口。
每个子系统的 servlet 在对应的 web.xml 文件中定义。同一文件还定义每个 servlet 的 URL 和访问 servlet 的安全要求。请参阅 第 2.3.1 节 “Java Application Server” 了解更多信息。

2.3.3.2. 管理界面

代理接口提供 Java servlet 来处理来自代理入口点的 HTML 表单提交。根据每个表单提交中提供的信息，代理 servlet 允许代理执行代理任务，如编辑和批准证书批准请求、证书续订和证书撤销、批准证书配置文件。KRA 子系统或 TKS 子系统的代理接口，或 OCSP Responder 特定于子系统。
在非TMS 设置中，代理接口也用于 CA-to-KRA 可信连接的 CIMC 边界通信。此连接受 SSL 客户端身份验证保护，并由单独的可信角色区分，称为 受信任的管理器。与 agent 角色一样，受信任的管理器（仅为 CIMC 边界连接创建的伪用户）需要 SSL 客户端验证。但是，与代理角色不同，它们不提供任何代理功能。
在 TMS 设置中，inter-CIMC 边界通信来自 TPS-to-CA、TPS-to-KRA 和 TPS-to-TKS。

2.3.3.3. 端到端接口

对于 CA 子系统，最终用户接口提供 Java servlet 来处理来自最终用户入口点的 HTML 表单提交。根据表格提交中收到的信息，最终用户 servlet 允许终端实体注册、续订证书、撤销自己的证书，以及获取签发的证书。OCSP Responder 子系统的 End-Entity 接口提供 Java servlet 以接受和处理 OCSP 请求。KRA、TKS 和 TPS 子系统不提供任何最终用户。

2.3.3.4. Operator Interface

操作器接口仅在 TPS 子系统中找到。

2.3.4. REST 接口

Representational state transfer (REST)是一种使用 HTTP 定义和组织 Web 服务的方法，可简化与其他应用程序的互操作性。Red Hat Certificate System 提供了一个 REST 接口来访问服务器上的各种服务。
红帽证书系统中的 REST 服务使用 RESTEasy 框架来实施。RESTEasy 实际上作为 servlet 在 web 应用中运行，因此 RESTEasy 配置也可以在对应的子系统的 web.xml 中找到。有关 RESTEasy 的更多信息，请访问 http://resteasy.jboss.org/。
每个 REST 服务都定义为一个单独的 URL。例如：
  • CA 证书服务： http:// <host_name>: &lt;port&gt; /ca/rest/certs/
  • KRA 密钥服务： http:// &lt;host_name>:<port> /kra/rest/agent/keys/
  • TKS 用户服务： http:// <host_name>:<port> /tks/rest/admin/users/
  • TPS 组服务： http:// &lt;host_name>:<port> /tps/rest/admin/groups/
有些服务可以使用普通 HTTP 连接访问，但有些服务可能需要 HTTPS 连接才能实现安全性。
REST 操作指定为 HTTP 方法（如 GET、PUT、POST、DELETE）。例如，若要获取 CA 用户，客户端将发送 GET /ca/rest/users 请求。
REST 请求和响应消息可以以 XML 或 JSON 格式发送。例如： 
{
	"id":"admin",
	"UserID":"admin",
	"FullName":"Administrator",
	"Email":"admin@example.com",
	...
}
可以使用 CLI、Web UI 或通用 REST 客户端等工具访问 REST 接口。证书系统还提供 Java、Python 和 JavaScript 库，以编程方式访问服务。
REST 接口支持两种类型的身份验证方法：
  • 用户名和密码
  • 客户端证书
每个服务所需的身份验证方法在 /usr/share/pki/ca/conf/auth-method.properties 中定义。
REST 接口可能需要某些权限才能访问该服务。权限在 LDAP 中的 ACL 资源中定义。REST 接口映射到 /usr/share/pki/ <subsystem> /conf/acl.properties 中的 ACL 资源。
有关 REST 接口的更多信息，请参阅 http://www.dogtagpki.org/wiki/REST。

2.3.5. JSS

Java 安全服务 (JSS)为 NSS 执行的加密操作提供了一个 Java 接口。JSS 及更高级别的证书系统架构使用 Java 原生接口(JNI)构建，提供对 Java 虚拟机(JVM)内原生系统库的访问。这个设计允许我们使用 FIPS 批准的加密供应商，比如作为系统一部分分发的 NSS。JSS 支持 NSS 支持的大多数安全标准和加密技术。JSS 还为 ASN.1 类型和 BER-DER 编码提供了一个纯 Java 接口。

2.3.6. tomcatjss

Red Hat Certificate System 中的基于 Java 的子系统使用一个名为 tomcatjss 的 JAR 文件作为 Tomcat 服务器 HTTP 引擎和 JSS 之间的桥接，Java 接口用于 NSS 执行的安全操作。tomcatjss 是一个 Java 安全套接字扩展(JSSE)实现，使用 Tomcat 的 Java 安全服务(JSS)实现。
tomcatjs 实现了使用 TLS 并创建 TLS 套接字所需的接口。tomcatjss 实施的套接字工厂利用下面列出的各种属性来创建 TLS 服务器侦听套接字并将其返回到 tomcat。tomcatjs 本身使用 java JSS 系统最终与机器上的原生 NSS 加密服务通信。
加载 Tomcat 服务器和证书系统类时，会加载 tomcatjs。载入过程如下所述：
  1. 服务器已启动。
  2. Tomcat 指向为证书系统安装创建侦听套接字需要的位置。
  3. server.xml 文件已被处理。此文件中的配置告知系统使用 Tomcatjs 实施的套接字工厂。
  4. 对于每个请求的套接字，Tomcajss 会在创建套接字时读取和处理包含的属性。生成的套接字的行为是因为已被这些参数要求。
  5. 服务器运行后，我们所需的一组侦听套接字等待进入基于 Tomcat 的证书系统的连接。
请注意，在启动时创建套接字时，Tomcatjs 是证书系统 中的第一个 实体，实际上处理底层 JSS 安全服务。处理第一个侦听套接字后，会创建一个 JSS 实例以供继续使用。
有关 server.xml 文件的详情，请参考 第 14.4 节 “Tomcat Engine 和 Web 服务的配置文件”。

2.3.7. PKCS #11

公钥加密标准(PKCS)是指定用来与保存加密信息的设备通信的 API，并执行加密操作。由于它支持 PKCS rebased，证书系统与广泛的硬件和软件设备兼容。
任何证书系统子系统实例必须至少有一个 PKCSBACKEND 模块可用。PKCSBACKEND 模块（也称为加密模块或加密服务提供商）管理加密服务，如加密和解密。PKCS current 模块与可以在硬件或软件中实施的加密设备的驱动程序类似。证书系统包含一个内置的 PKCS facilities 模块，可以支持第三方模块。
PKCSBACKEND 模块始终具有一个或多个插槽，可作为物理读取器中的物理硬件插槽（如智能卡或软件中的概念插槽）实现。PKCSjpeg 模块的每个插槽可以包含一个令牌，它是一个硬件或软件设备，它实际提供加密服务，并选择性地存储证书和密钥。
证书系统定义了两种类型的令牌，即 内部和外部 。内部令牌用于存储证书信任锚。外部令牌用于存储属于证书系统子系统的密钥对和证书。

2.3.7.1. NSS 软令牌（内部令牌）

注意
证书系统使用 NSS 软令牌来存储证书信任锚。
NSS 软令牌也称为内部令牌或软件令牌。软件令牌由两个文件组成，这些文件通常称为证书数据库(cert9.db)和密钥数据库(key4.db)。文件是在证书系统子系统配置期间创建的。这些安全数据库位于 /var/lib/pki/instance_name/alias 目录中。
由 NSS 软令牌提供的两个加密模块包含在证书系统中：
  • 默认内部 PKCSROX 模块，它附带两个令牌：
    • 内部加密服务令牌，执行所有加密操作，如加密、解密和哈希。
    • 内部密钥存储令牌("Certificate DB 令牌")，它处理与存储证书和密钥的证书和密钥数据库文件的所有通信。
  • FIPS 140 模块。这个模块符合对加密模块实现的 FIPS 140 政府标准。FIPS 140 模块包含一个内置 FIPS 140 证书数据库令牌，它处理加密操作以及与证书和密钥数据库文件的通信。
有关如何将证书导入到 NSS 软令牌的具体信息包括在 第 15 章 管理证书/密钥加密策略 中。
有关网络安全服务(NSS)的更多信息，请参阅相同名称的 Mozilla Developer web 页面。

2.3.7.2. 硬件安全模块(HSM、外部令牌)

注意
证书系统使用 HSM 存储属于证书系统子系统的密钥对和证书。
任何 PKCSGIO 模块都可以与证书系统一起使用。要将外部硬件令牌与子系统搭配使用，请在配置子系统前加载其 PKCSBACKEND 模块，并且新令牌可供子系统使用。
可用的 PKCS Anaconda 模块在子系统的 pkcs11.txt 数据库中跟踪。当系统 有变化时，modutil 实用程序用于修改此文件，如安装用于签名操作的硬件加速器。有关 modutil 的更多信息，请参阅 Mozilla Developer 网页上的网络安全服务(NSS)。
PKCSBACKEND 硬件设备还为存储在硬件令牌中的信息提供密钥备份和恢复功能。有关从令牌检索密钥的详情，请参考 PKCSROX 供应商文档。
有关如何导入证书和管理 HSM 的具体说明位于 第 15 章 管理证书/密钥加密策略 中。
支持的硬件安全模块位于 第 4.4 节 “支持的硬件安全模块” 中。

2.3.8. 证书系统序列号管理

2.3.8.1. 序列号范围

证书请求和序列号由 Java 的大整数表示
默认情况下，由于其效率，CA 子系统按顺序分配证书请求号、证书序列号和副本 ID。
序列号范围对于请求、证书和副本 ID 可指定：
  • 当前序列号管理基于分配顺序序列号的范围。
  • 当超过定义的阈值时，实例会请求新的范围。
  • 实例在分配给实例后存储有关新获取范围的信息。
  • 实例继续使用旧的范围，直到所有数字都用尽，然后移动到新范围。
  • 克隆的子系统通过复制冲突来同步其范围分配。
对于新克隆：
  • 在克隆过程中，当前 master 范围的一部分被传送到一个新的克隆。
  • 如果传输的范围低于定义的阈值，新的克隆可能会请求新的范围。
所有范围均可在 CA 实例安装时配置，方法是向 PKI 实例覆盖配置文件中添加 [CA] 部分，并根据需要在该部分下添加以下 name=value 对。以下示例中显示了 /etc/pki/default.cfg 中已存在的默认值： 
[CA]
pki_serial_number_range_start=1
pki_serial_number_range_end=10000000
pki_request_number_range_start=1
pki_request_number_range_end=10000000
pki_replica_number_range_start=1
pki_replica_number_range_end=100

2.3.8.2. 随机序列号管理

除了顺序序列号管理外，红帽认证系统还提供可选的随机序列号管理。通过在 PKI 实例覆盖文件中添加 [CA] 部分并在该部分下添加以下 name=value 对，可以在 CA 实例安装时选择随机序列号： 
[CA]
pki_random_serial_numbers_enable=True
如果选择，证书请求号和证书序列号将在指定的范围内随机选择。

2.3.9. 安全域

安全域 是 PKI 服务的注册表。CA 等服务注册这些域中自身的信息，因此 PKI 服务的用户可以通过检查注册表来查找其他服务。RHCS 中的安全域服务管理为证书系统子系统和一组共享信任策略的 PKI 服务注册。
详情请查看 第 5.3 节 “规划安全域”。

2.3.10. 密码和 Watchdog (nuxwdog)

在默认设置中，RHCS 子系统实例需要充当客户端并向某些其他服务进行身份验证，如 LDAP 内部数据库（除非设置了 TLS 客户端身份验证，其中将用来进行身份验证的证书）、NSS 令牌数据库或有时带有密码的 HSM。在安装配置时，管理员会提示您设置此密码。然后，此密码将写入文件 < instance_dir>/conf/password.conf。同时，标识字符串存储在主配置文件中 CS.cfg 中，作为参数 cms.passwordlist 的一部分。
配置文件 CS.cfg 受 Red Hat Enterprise Linux 的保护，且只能被 PKI 管理员访问。没有密码存储在 CS.cfg 中。
在安装过程中，安装程序会选择并登录到内部软件令牌或硬件加密令牌。到这些令牌的登录密码短语也写入 password.conf。
稍后配置也可以将密码放在 password.conf 中。LDAP 发布是一个示例，新为发布目录配置的 Directory Manager 密码被输入 password.conf。
nuxwdog (watchdog)是一种轻量级辅助守护进程进程，用于启动、停止、监控其状态并重新配置服务器程序。当用户需要提示您输入密码以启动服务器时，它最有用，因为它会在内核密钥环中安全地缓存这些密码，以便在服务器崩溃时自动重启。
注意
nuxwdog 是唯一 允许的 watchdog 服务。
安装完成后，可以完全删除 password.conf 文件。重启时，nuxwdog watchdog 程序将提示管理员输入所需的密码，使用参数 cms.passwordlist （如果使用 cms.tokenList ），作为要提示的密码列表。然后，在内核密钥环中由 nuxwdog 缓存密码，以允许从服务器崩溃自动恢复。当出现不受控制的关闭(crash)时，会发生此自动恢复（自动子系统重启）。如果管理员控制的关闭，管理员将再次提示输入密码。
使用 watchdog 服务时，启动和停止 RHCS 实例会有所不同。详情请查看 第 14.3.2 节 “使用证书系统 Watchdog 服务”。
有关详情请参考 第 14.3 节 “管理系统密码”。

2.3.11. 内部 LDAP 数据库

Red Hat Certificate System 使用红帽目录服务器(RHDS)作为其内部数据库，用于存储证书、请求、用户、角色、ACL 等信息，以及其他各种内部信息。证书系统可以通过密码与内部 LDAP 数据库通信，或者通过 SSL 身份验证安全地通信。
如果在证书系统实例和目录服务器之间需要基于证书的身份验证，务必要按照说明在这两个实体之间设置信任。安装此类证书系统实例也需要正确 pkispawn 选项。
详情请查看 第 6.5 节 “安装 Red Hat Directory Server”。

2.3.12. Security-Enhanced Linux (SELinux)

SELinux 是强制访问控制规则的集合，用于限制未经授权的访问和篡改。在 Red Hat Enterprise Linux 8中使用 SELinux 指南中 更详细地描述了 SELinux。
基本上，SELinux 会识别系统上的 对象，可以是文件、目录、用户、进程、套接字或 Linux 主机上的任何其他资源。这些对象与 Linux API 对象对应。然后，每个对象 都会映射到一个安全上下文，用于定义对象类型以及如何在 Linux 服务器上正常工作。
对象可以被分组到域中，然后为每个域分配正确的规则。每个安全上下文都有规则设置对其可以执行什么操作的限制、它可以访问哪些资源，以及它们具有什么权限。
证书系统的 SELinux 策略被合并到标准系统 SELinux 策略中。这些 SELinux 策略适用于证书系统使用的每个子系统和服务。通过以 enforcing 模式运行 SELinux 的证书系统，增强了由证书系统创建和管理的信息的安全性。

图 2.1. CA SELinux 端口策略

CA SELinux 端口策略
证书系统 SELinux 策略为每个子系统实例定义 SELinux 配置：
  • 每个子系统实例的文件和目录使用特定的 SELinux 上下文标记。
  • 每个子系统实例的端口使用特定的 SELinux 上下文标记。
  • 所有证书系统进程都在特定于子系统的域中进行限制。
  • 每个域具有特定的规则，用于定义授权域的操作。
  • SELinux 策略中没有指定的访问权限都会被拒绝访问证书系统实例。
对于证书系统，每个子系统被视为 SELinux 对象，每个子系统分配有唯一的规则。定义的 SELinux 策略允许证书系统对象在 enforcing 模式下设置 SELinux 运行。
每次运行 pkispawn 时，用来配置证书系统子系统，与该子系统关联的文件和端口都会使用所需的 SELinux 上下文标记。使用 pkidestroy 删除特定子系统时，这些上下文将被删除。
SELinux 策略中的中央定义是 pki_tomcat_t 域。证书系统实例是 Tomcat 服务器，pki_tomcat_t 域扩展了标准 tomcat_t Tomcat 域的策略。服务器上的所有证书系统实例共享相同的域。
当每个证书系统进程启动时，它最初在无限制域(unconfined_t)中运行，然后过渡到 pki_tomcat_t 域。然后，这个进程具有某些访问权限，如对标记为 pki_tomcat_log_t 的日志文件进行写入访问，对标记为 pki_tomcat_etc_rw_t 的配置文件进行读写访问，或者对 http_port_t 端口打开和写入。
SELinux 模式可以从 enforcing 模式改为 permissive，即使不建议这样做。

2.3.13. self-tests

Red Hat Certificate System 提供了一个自测试框架，它允许在启动或按需进行期间检查 PKI 系统完整性。如果出现非关键自我测试失败，则消息将存储在日志文件中，而如果出现关键自我测试失败，则消息将存储在日志文件中，而证书系统子系统将正确关闭。如果管理员希望在启动时看到自测试报告，则管理员预期会在子系统启动期间观察自测试日志。它们也可以在启动时查看日志。
当因为自测试失败而关闭子系统时，也会自动禁用它。这是为了确保子系统不会部分运行，并生成误导的响应。解决此问题后，可以通过在服务器上运行以下命令来重新启用子系统： 
# pki-server subsystem-enable <subsystem>
有关如何配置自助测试的详情，请参考 第 18.3.2 节 “配置自测试”。

2.3.14. 日志

证书系统子系统创建记录与活动相关的日志文件，如管理、使用服务器支持的协议的通信，以及由子系统使用的各种其他进程。在子系统实例运行时，它会保留其管理的所有组件的信息和错误消息的日志。此外，Apache 和 Tomcat Web 服务器还会生成错误和访问日志。
每个子系统实例维护自己的日志文件，用于安装、审计和其他日志记录功能。
日志插件模块是作为 Java™ 类实施的监听程序，并在配置框架中注册。
当实例使用 pkispawn 创建时，所有日志文件和轮转的日志文件（除审计日志除外）都位于 pki_subsystem_log_path 中指定的任何目录中。 常规审计日志位于日志目录中，使用其他类型的日志进行日志，而签名的审计日志则写入 /var/log/pki/instance_name/subsystem_name/signedAudit。可以通过修改配置来更改日志的默认位置。
有关在安装过程中日志配置的详情，请参考 第 18 章 配置日志。
有关安装后日志管理的详情，请参考 Red Hat Certificate System Administration Guide 中的 Configuring Subsystem Logs 部分。

2.3.14.1. 审计日志

审计日志包含为可记录事件设置的可选择事件的记录。您还可以将审计日志配置为签名以进行完整性检查。
注意
审计记录应根据 -第 18.4 节 “审计保留” 中指定的审计保留规则保存。

2.3.14.2. 调试日志

调试日志（默认启用）会为所有子系统维护，不同的程度和类型的信息。
每个子系统记录详细信息的调试日志，包含子系统执行的每个操作的非常具体的信息，包括运行插件和 servlets 的插件和 servlet，以及服务器请求和响应消息。
记录到调试日志的服务包括授权请求、处理证书请求、证书状态检查以及归档和恢复密钥以及访问 Web 服务。
debug 记录有关子系统进程的详细信息。每个日志条目都采用以下格式： 
[date:time] [processor]: servlet: message
消息 可以是来自子系统的返回消息，也可以包含提交到子系统的值。
例如，TKS 记录此消息以连接到 LDAP 服务器： 
[10/Jun/2022:05:14:51][main]: Established LDAP connection using basic authentication to host localhost port 389 as cn=Directory Manager
处理器 是主 的，消息 是服务器有关 LDAP 连接的消息，没有 servlet。
另一方面，CA 记录有关证书操作的信息以及子系统连接： 
[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443
在这种情况下，处理器是通过 CA 的代理端口的 HTTP 协议，而它指定了处理配置文件的 servlet，并包含提供 profile 参数（请求的子系统所有者）及其值(KRA 启动请求) 的消息。

例 2.1. CA 证书请求日志消息

[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileapprovedby$ value=admin
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request$ value=MIIBozCCAZ8wggEFAgQqTfoHMIHHgAECpQ4wDDEKMAgGA1UEAxMBeKaBnzANBgkqhkiG9w0BAQEFAAOB...
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profile$ value=true
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request_type$ value=crmf
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestversion$ value=1.0.0
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_locale$ value=en
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.dbstatus$ value=NOT_UPDATED
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.subject$ value=uid=jsmith, e=jsmith@example.com
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requeststatus$ value=begin
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.user$ value=uid=KRA-server.example.com-8443,ou=People,dc=example,dc=com
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_key$ value=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLP^M
				HcN0cusY7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChV^M
				k9HYDhmJ8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaM^M
				HTmlOqm4HwFxzy0RRQIDAQAB
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authmgrinstname$ value=raCertAuth
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.uid$ value=KRA-server.example.com-8443
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userid$ value=KRA-server.example.com-8443
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestor_name$ value=
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileid$ value=caUserCert
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userdn$ value=uid=KRA-server.example.com-4747,ou=People,dc=example,dc=com
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestid$ value=20
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authtime$ value=1212782378071
				[06/Jun/2022:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_x509info$ value=MIICIKADAgECAgEAMA0GCSqGSIb3DQEBBQUAMEAxHjAcBgNVBAoTFVJlZGJ1ZGNv^M
				bXB1dGVyIERvbWFpbjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X^M
				DTA4MDYwNjE5NTkzOFoXDTA4MTIwMzE5NTkzOFowOzEhMB8GCSqGSIb3DQEJARYS^M
				anNtaXRoQGV4YW1wbGUuY29tMRYwFAYKCZImiZPyLGQBARMGanNtaXRoMIGfMA0G^M
				CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLPHcN0cusY^M
				7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChVk9HYDhmJ^M
				8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaMHTmlOqm4^M
				HwFxzy0RRQIDAQABo4HFMIHCMB8GA1UdIwQYMBaAFG8gWeOJIMt+aO8VuQTMzPBU^M
				78k8MEoGCCsGAQUFBwEBBD4wPDA6BggrBgEFBQcwAYYuaHR0cDovL3Rlc3Q0LnJl^M
				ZGJ1ZGNvbXB1dGVyLmxvY2FsOjkwODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBeAw^M
				HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMCQGA1UdEQQdMBuBGSRyZXF1^M
				ZXN0LnJlcXVlc3Rvcl9lbWFpbCQ=
同样，OCSP 显示 OCSP 请求信息： 
[07/Jul/2022:06:25:40][http-11180-Processor25]: OCSPServlet: OCSP Request:
				[07/Jul/2022:06:25:40][http-11180-Processor25]: OCSPServlet:
				MEUwQwIBADA+MDwwOjAJBgUrDgMCGgUABBSEWjCarLE6/BiSiENSsV9kHjqB3QQU

2.3.14.3. 安装日志

所有子系统都保留安装日志。
每次通过初始安装创建子系统时，或使用 pkispawn 创建额外实例，安装文件包含安装的完整调试输出，包括任何错误，如果安装成功，则为实例配置界面的 URL 和 PIN。该文件在实例的 /var/log/pki/ 目录中创建一个，格式为 pki-subsystem_name-spawn.timestamp.log。
安装日志中的每一行都遵循安装过程中的一个步骤。

例 2.2. CA 安装日志

    ==========================================================================
                                INSTALLATION SUMMARY
    ==========================================================================

      Administrator's username:             caadmin
      Administrator's PKCS #12 file:
            /root/.dogtag/pki-tomcat/ca_admin_cert.p12

      Administrator's certificate nickname:
            caadmin
      Administrator's certificate database:
            /root/.dogtag/pki-tomcat/ca/alias

      To check the status of the subsystem:
            systemctl status pki-tomcatd@pki-tomcat.service

      To restart the subsystem:
            systemctl restart pki-tomcatd@pki-tomcat.service

      The URL for the subsystem is:
            https://localhost.localdomain:8443/ca

      PKI instances will be enabled upon system boot

    ==========================================================================

2.3.14.4. Tomcat 错误和访问日志

CA、KRA、OCSP、CKS 和 TPS 子系统将 Tomcat Web 服务器实例用于其代理和终端实体的接口。
Tomcat web 服务器创建错误和访问日志，该服务器安装有证书系统并提供 HTTP 服务。错误日志包含服务器遇到的 HTTP 错误消息。访问日志通过 HTTP 接口列出访问活动。
Tomcat 创建的日志：
  • admin.timestamp
  • catalina.timestamp
  • catalina.out
  • host-manager.timestamp
  • localhost.timestamp
  • localhost_access_log.timestamp
  • manager.timestamp
这些日志在证书系统中不可用或可配置；它们只能在 Apache 或 Tomcat 中进行配置。有关配置这些日志的详情，请查看 Apache 文档。

2.3.14.5. 自助测试日志

当服务器启动或者自助测试被手动运行时，self-tests 记录在 self-tests 期间获得的信息。可以通过打开此日志来查看测试。此日志无法通过控制台配置。这个日志只能通过更改 CS.cfg 文件中的设置来配置。本节中有关日志的信息与此日志无关。有关自测试的更多信息，请参阅 第 2.6.5 节 “自助测试”。

2.3.14.6. journalctl Logs

启动证书系统实例时，在设置并启用 logging 子系统之前会有一个短暂的时间。在此期间，日志内容被写入标准输出，由 systemd 捕获并通过 journalctl 实用程序公开。
要查看这些日志，请运行以下命令： 
# journalctl -u pki-tomcatd@instance_name.service
如果使用 nuxwdog 服务： 
# journalctl -u pki-tomcatd-nuxwdog@instance_name.service
通常，在实例启动时监控这些日志会很有用（例如，在启动时出现自测试失败）。要做到这一点，请在启动实例前在单独的控制台中运行这些命令： 
# journalctl -f -u pki-tomcatd@instance_name.service
如果使用 nuxwdog 服务： 
# journalctl -f -u pki-tomcatd-nuxwdog@instance_name.service

2.3.15. 实例布局

每个证书系统实例都取决于多个文件。其中一些位于特定于实例的文件夹中，另一些则位于共同的文件夹中，与其他服务器实例共享。
例如，服务器配置文件存储在 /etc/pki/instance_name/server.xml 中，后者是特定于实例的，但 CA servlet 在 /usr/share/pki/ca/webapps/ca/WEB-INF/web.xml 中定义，后者由系统上的所有服务器实例共享。

2.3.15.1. 证书系统的文件和目录位置

证书系统服务器是由一个或多个证书系统子系统组成的 Tomcat 实例。证书系统子系统是提供特定类型的 PKI 功能的 Web 应用。一般的共享子系统信息包含在不可重新分配的、RPM 定义的共享库、Java 归档文件、二进制文件和模板中。它们存储在固定的位置。
这些目录特定于实例，与实例名称相关联。在这些示例中，实例名称为 pki-tomcat; true 值是在使用 pkispawn 创建子系统时指定的。
目录包含子系统的自定义配置文件和模板、配置文件、证书数据库和其他文件。

表 2.2. Tomcat 实例信息

设置 值
主目录 /var/lib/pki/pki-tomcat
配置目录 /etc/pki/pki-tomcat
配置文件
/etc/pki/pki-tomcat/server.xml
/etc/pki/pki-tomcat/password.conf
安全数据库 /var/lib/pki/pki-tomcat/alias
子系统证书
SSL 服务器证书
子系统证书 [a]
日志文件 /var/log/pki/pki-tomcat
Web 服务文件
/usr/share/pki/server/webapps/ROOT - Main page
/usr/share/pki/server/webapps/pki/admin - Admin templates
/usr/share/pki/server/webapps/pki/js - JavaScript 库
[a] 子系统证书始终由安全域发布，以便需要客户端身份验证的域级别操作基于此子系统证书。
注意
/var/lib/pki/instance_name/conf/ 目录是到 /etc/pki/instance_name/ 目录的符号链接。

2.3.15.2. CA 子系统信息

这些目录特定于实例，与实例名称相关联。在这些示例中，实例名称为 pki-tomcat; true 值是在使用 pkispawn 创建子系统时指定的。

表 2.3. CA 子系统信息

设置 值
主目录 /var/lib/pki/pki-tomcat/ca
配置目录 /etc/pki/pki-tomcat/ca
配置文件 /etc/pki/pki-tomcat/ca/CS.cfg
子系统证书
CA 签名证书
OCSP 签名证书（用于 CA 的内部 OCSP 服务）
审计日志签名证书
日志文件 /var/log/pki/pki-tomcat/ca
安装日志 /var/log/pki/pki-ca-spawn.YYYYMMDDhhmmss.log
配置集文件 /var/lib/pki/pki-tomcat/ca/profiles/ca
电子邮件通知模板 /var/lib/pki/pki-tomcat/ca/emails
Web 服务文件
/usr/share/pki/ca/webapps/ca/agent - Agent 服务
/usr/share/pki/ca/webapps/ca/admin - Admin 服务
/usr/share/pki/ca/webapps/ca/ee - 最终用户服务

2.3.15.3. KRA 子系统信息

这些目录特定于实例，与实例名称相关联。在这些示例中，实例名称为 pki-tomcat; true 值是在使用 pkispawn 创建子系统时指定的。

表 2.4. KRA 子系统信息

设置 值
主目录 /var/lib/pki/pki-tomcat/kra
配置目录 /etc/pki/pki-tomcat/kra
配置文件 /etc/pki/pki-tomcat/kra/CS.cfg
子系统证书
传输证书
存储证书
审计日志签名证书
日志文件 /var/log/pki/pki-tomcat/kra
安装日志 /var/log/pki/pki-kra-spawn.YYYYMMDDhhmmss.log
Web 服务文件
/usr/share/pki/kra/webapps/kra/agent - Agent 服务
/usr/share/pki/kra/webapps/kra/admin - Admin services

2.3.15.4. OCSP 子系统信息

这些目录特定于实例，与实例名称相关联。在这些示例中，实例名称为 pki-tomcat; true 值是在使用 pkispawn 创建子系统时指定的。

表 2.5. OCSP 子系统信息

设置 值
主目录 /var/lib/pki/pki-tomcat/ocsp
配置目录 /etc/pki/pki-tomcat/ocsp
配置文件 /etc/pki/pki-tomcat/ocsp/CS.cfg
子系统证书
OCSP 签名证书
审计日志签名证书
日志文件 /var/log/pki/pki-tomcat/ocsp
安装日志 /var/log/pki/pki-ocsp-spawn.YYYYMMDDhhmmss.log
Web 服务文件
/usr/share/pki/ocsp/webapps/ocsp/agent - Agent 服务
/usr/share/pki/ocsp/webapps/ocsp/admin - Admin services

2.3.15.5. TKS 子系统信息

这些目录特定于实例，与实例名称相关联。在这些示例中，实例名称为 pki-tomcat; true 值是在使用 pkispawn 创建子系统时指定的。

表 2.6. TKS 子系统信息

设置 值
主目录 /var/lib/pki/pki-tomcat/tks
配置目录 /etc/pki/pki-tomcat/tks
配置文件 /etc/pki/pki-tomcat/tks/CS.cfg
子系统证书 审计日志签名证书
日志文件 /var/log/pki/pki-tomcat/tks
安装日志 /var/log/pki/pki-tomcat/pki-tks-spawn.YYYYMMDDhhmmss.log

2.3.15.6. TPS 子系统信息

这些目录特定于实例，与实例名称相关联。在这些示例中，实例名称为 pki-tomcat; true 值是在使用 pkispawn 创建子系统时指定的。

表 2.7. TPS 子系统信息

设置 值
主目录 /var/lib/pki/pki-tomcat/tps
配置目录 /etc/pki/pki-tomcat/tps
配置文件 /etc/pki/pki-tomcat/tps/CS.cfg
子系统证书 审计日志签名证书
日志文件 /var/log/pki/pki-tomcat/tps
安装日志 /var/log/pki/pki-tps-spawn.YYYYMMDDhhhmmss.log
Web 服务文件 /usr/share/pki/tps/webapps/tps - TPS 服务

2.3.15.7. 共享证书系统子系统文件位置

有一些目录供所有证书系统子系统实例用于常规服务器操作，列在 表 2.8 “子系统文件位置” 中。

表 2.8. 子系统文件位置

目录位置 内容
/usr/share/pki 包含用于创建证书系统实例的常用文件和模板。除了所有子系统的共享文件外，子文件夹中还有特定于子系统的文件：
  • pki/ca (CA)
  • pki/kra (KRA)
  • pki/ocsp (OCSP)
  • pki/tks (TKS)
  • pki/tps (TPS)
/usr/bin 包含 pkispawn 和 pkidestroy 实例配置脚本，以及由证书系统子系统共享的 Java、原生和安全性。
/usr/share/java/pki 包含由本地 Tomcat Web 应用程序共享的 Java 归档文件，并由证书系统子系统共享。