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

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

5.5.2. CMC 注册过程

使用以下常规流程使用 CMC 请求和发布证书：

使用以下格式之一创建证书签名请求(CSR)：
- PKCS the10 格式
- 证书请求消息格式(CRMF)格式
有关以这些格式创建 CSR 的详情，请参考第 5.2 节 “创建证书签名请求”。
将 admin 证书导入到客户端 NSS 数据库中。例如：
- 执行以下命令，从 .p12 文件中提取 admin 客户端证书：
```
$ openssl pkcs12 -in /root/.dogtag/instance/ca_admin_cert.p12 -clcerts -nodes -nokeys -out /root/.dogtag/instance/ca_admin_cert.crt
```
- 根据 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
```

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

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

# NSS database password
password=password

# Token name (default is internal)
tokenname=internal

# Nickname for signing certificate
nickname=subsystem_admin

# Request format: pkcs10 or crmf
format=pkcs10

# Total number of PKCS10/CRMF requests
numRequests=1

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

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

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

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

为 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 请求的证书匹配。

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

向 CA 提交 CMC 请求：

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

要将 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. 获取用户的第一个签名证书

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

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

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 注册过程” 搭配使用：

以用户或 CA 管理员身份创建共享令牌。详情请参阅 Red Hat Certificate System 规划、安装和部署指南中的 共享 Secret 工作流 部分。
请注意：
- 如果用户创建了令牌，用户必须向 CA 管理员发送令牌。
- 如果 CA 管理员创建了令牌，管理员必须与用户共享用于生成令牌的密码。使用安全的方式传输密码。
作为 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 部分。
在传递给 CMCRequest 工具的配置文件中使用以下参数：
- identification.enable
- witness.sharedSecret
- identityProofV2.enable
- identityProofV2.hashAlg
- identityProofV2.macAlg
- request.useSharedSecret
- request.privKeyId
如果 CA 需要，还要使用传递给 CMCRequest 工具的配置文件中的以下参数：
- popLinkWitnessV2.enable
- popLinkWitnessV2.keyGenAlg
- popLinkWitnessV2.macAlg

5.5.3.3. 获取用户只加密的证书

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

注意

如果用户拥有多个用于不同用途的证书，其中有一个被签名，用户必须首先获取签名证书。用户拥有签名证书后，就可以将其用于参与 Of Origin，而无需设置并依赖 CMC 共享 Secret 机制。

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

以用户身份：

使用存储在网络安全服务(NSS)数据库或包含用户签名证书和密钥的智能卡中的加密令牌。
以 PKCS the10 或 CRMF 格式生成 CSR。
注意
如果需要密钥归档，请使用 CRMF 格式。
生成 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”。

搜索 KRA 传输证书。例如：

$ pki cert-find --name KRA_transport_certificate_subject_CN

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

为 CRMRequest 工具创建一个配置文件，如 /home/user_name/cmc.cfg，其内容如下：

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

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

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

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

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

#dbdir: directory for 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

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

为 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

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

通过将响应文件传递给 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

对于第二个往返，请为 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

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

为 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

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

要将 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