5.3. 使用 CMC 请求和接收证书

本节论述了通过 CMS (CMC)使用证书管理注册证书的步骤。

有关配置和使用 CMC 注册证书工作流的常规信息，请参阅：

计划、安装和部署指南（通用标准版） 中 CMC 的 9.6 配置。
2.4.1.1.2.2 在规划 、安装和部署指南（标准版） 中注册 CMC。
CMCRequest (1) 手册页
CMCResponse (1) 手册页

CMC 注册可以以不同的方式进行注册，以满足不同场景的要求。第 5.3.1 节 “CMC 注册过程” 规划、安装和部署指南（通用标准版） 中的 CMC 补充 2.4.1.1.2.2 注册，详情。另外，第 5.3.2 节 “实际 CMC 注册场景” 部分可让管理员决定在哪些场景中应使用哪些机制。

5.3.1. CMC 注册过程
复制链接

最常用的 CMC 注册过程是代理批准的证书注册：

用户生成 CSR 并将 CSR 发送到 CA 代理
收到 CSR 后，CA 代理（由 规划、安装和部署指南(Common Standard Edition)中的"设置 pki 代理的证书和角色"配置，并通过 HttpClient将请求发送到 CA
成功签发证书后，CA 代理将证书发送到请求用户
然后，用户会将新发布的证书导入到最初生成的 CSR 的 nssdb 中

本节的其余部分提供了使用 CMC 发布证书的更多详细信息：

请求用户首先以以下格式之一创建证书签名请求(CSR)：

PKCS #10 格式
证书请求消息格式(CRMF)格式

接下来，请求的用户应向包含 CA 代理角色的用户发送 CSR （如 /user_or_entity_database_directory/request.csr）。

批准 CSR 作为 CA 代理

作为 CA 代理，切换到包含代理证书的 nssdb 目录：
```
# cd /home/agent_username/.dogtag/nssdb/
```

将 CSR 放在目录中：

# cp request.csr /home/agent_username/.dogtag/nssdb/

将 CSR 放置到目录中后，使用以下内容为 CMC 请求创建一个配置文件，如 cmc-request.cfg ：

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

# NSS database password
password=password

# Token name (default is internal)
tokenname=internal

# Nickname for signing certificate
nickname=ca_agent

# Request format: pkcs10 or crmf
format=<type of CSR format>

# 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 a space.
input=/home/agent_username/.dogtag/nssdb/request.csr

# Path for the CMC request
output=/home/agent_username/.dogtag/nssdb/cmc-request.bin

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

创建 CMC 请求：

$ CMCRequest cmc-request.cfg

cert/key prefix =
path = /home/agent_username/.dogtag/nssdb
CryptoManger initialized
token internal logged in...
got signerCert: ca_agent
createPKIData: begins
k=0
createPKIData:  format: pkcs10
useSharedSecret is false...
signData: begins:
getPrivateKey: got signing cert
signData:  got signer privKey
createSignedData: begins
getSigningAlgFromPrivate: begins.
getSigningAlgFromPrivate: found signingKeyType=RSA
getSigningAlgFromPrivate: using SignatureAlgorithm: RSASignatureWithSHA256Digest
createSignedData: digest created for pkidata
createSignedData: digest algorithm =RSASignatureWithSHA256Digest
createSignedData: building cert chain
signData: signed request generated.
getCMCBlob: begins
getCMCBlob: generating signed data

The CMC enrollment request in base-64 encoded format:

. . . output omitted . . .


The CMC enrollment request in binary format is stored in /home/agent_username/.dogtag/nssdb/cmc-request.bin

如果命令成功，CMCRequest 工具会将 CMC 请求存储在请求配置文件的 output 参数中指定的文件中。

为 HttpClient 创建配置文件（如 cmc-submit.cfg ）以用于稍后的步骤中，将 CMC 请求提交到 CA。在创建的文件中添加以下内容：

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

# CA 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/agent_username/.dogtag/nssdb/

# NSS database password
password=password

# Token name (default: internal)
tokenname=internal

# Nickname of signing certificate
nickname=ca_agent

# Path for the CMC request
input=/home/agent_username/.dogtag/nssdb/cmc-request.bin

# Path for the CMC response
output=/home/agent_username/.dogtag/nssdb/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 插件。详情请查看第 8.3 节 “CMC 身份验证插件”。

将 CMC 请求提交到 CA：

$ HttpClient cmc-submit.cfg

Total number of bytes read = 6271
after SSLSocket created, thread token is NSS FIPS 140-2 User Private Key
client cert is not null
handshake happened
writing to socket

Response Headers begin
HTTP/1.1 200
Content-Type: application/pkcs7-mime
Content-Length: 4227
Date: Fri, 19 Jan 2024 20:57:26 GMT
Connection: close
end

. . . Output omitted . . .

The response in binary format is stored in home/agent_username/.dogtag/nssdb/cmc-response.bin

要将 CMC 响应转换为 PKCS #7 证书链，请将 CMC 响应文件传递给 CMCResponse 工具的 -i 参数。例如：
```
$ CMCResponse -i /home/user_name/cmc-response.bin -o /home/user_name/cert_chain.crt
```
重要
使用 "-v" 选项运行 CMCResponse 将链中每个证书的 PEM 返回为 Cert:0,Cert:1 等。在所有 PEM 下，输出也会以用户打印格式显示链中的每个证书。由于证书没有以固定顺序显示，因此为了确定其在链中的位置，您必须检查每个 "Certificate" 下的"Subject: "。对应的 PEM 显示在上面的同一位置。
成功签发证书后，CA 代理会将证书发送回请求用户。然后，用户可以将证书导入到其 nssdb 中。例如：
```
# pki -d /user_or_entity_database_directory/ -c <password> client-cert-import "user_name certificate" --cert cert_chain.crt
```

5.3.2. 实际 CMC 注册场景
复制链接

本节介绍常用的实际使用场景及其工作流，使 CA 管理员能够决定在什么情况下使用哪些 CMC 方法。

有关使用 CMC 注册证书的一般过程，请参考第 5.3.1 节 “CMC 注册过程”。

5.3.2.1. 获取系统和服务器证书
复制链接

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

注册配置集

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

CMC 签名证书

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

注意

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

httpclient nickname 参数

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

httpclient servlet 参数

传递到 HttpClient 实用程序的配置文件中的 servlet 指的是处理请求的 CMC servlet 和注册配置文件。

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

对于 CA 签名证书：

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

对于 KRA 传输证书：

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

对于 OCSP 签名证书：

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

对于审计签名证书：

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

对于子系统证书：

对于 RSA 证书：

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

对于 ECC 证书：

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

对于 TLS 服务器证书：

对于 RSA 证书：

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

对于 ECC 证书：

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

对于管理证书：

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

更多详情：

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

5.3.2.2. 获取用户的第一个签名证书
复制链接

批准用户的第一个签名证书有两种方法：

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

5.3.2.2.1. 使用代理证书签署 CMC 请求
复制链接

使用代理证书签署 CMC 请求的过程与获取系统和服务器证书的过程相同，可在第 5.3.1 节 “CMC 注册过程” 中找到。

5.3.2.2.2. 使用共享 secret 为证书注册进行身份验证
复制链接

CMC SharedToken 方法旨在允许非代理用户安全地注册自己的用户证书，而无需参与 CA 代理。当用户希望获取第一个签名证书时，代理无法批准请求，如第 5.3.2.2.1 节 “使用代理证书签署 CMC 请求” 所述，您可以使用 Shared Token。使用这个令牌，用户可以获取第一个签名证书。然后，此证书可用于为用户的其他证书签名。

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

以用户或 CA 管理员身份创建共享令牌。详情请查看第 8.4.1 节 “创建共享 Secret 令牌”。
请注意： 如果用户创建了令牌，用户必须将令牌发送到 CA 管理员。 如果 CA 管理员创建了令牌，管理员必须共享用于通过用户生成令牌的密码。使用安全的方式传输密码。
作为 CA 管理员，将 Shared Token 添加到 LDAP 中的用户条目。详情请参阅 计划、安装和部署指南（标准版）中的 9.6.3 将 CMC Shared Secret 添加到证书注册的用户条目中和 启用 CMC 共享 Secret 功能。
使用传递给 CMCRequest 程序的配置文件中的以下参数：
- identification.enable
- 身份识别
- witness.sharedSecret
- identityProofV2.enable
- identityProofV2.hashAlg
- identityProofV2.macAlg
- request.useSharedSecret
- request.privKeyId
如果 CA 需要，还要使用传递给 CMCRequest 程序的配置文件中的以下参数：
- popLinkWitnessV2.enable
- popLinkWitnessV2.keyGenAlg
- popLinkWitnessV2.macAlg
  注意
  有关 CA 是否需要 popLinkWitness 的更多信息，请参阅 规划、安装和部署指南(Common Standard Edition) 中的 9.6.2 中的配置参数值。

参阅以下示例，了解如何在 CMC 注册配置文件中使用参数。例如，在请求的用户的 nssdb 中创建 shrTok_example_request.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.
### Multiple files are supported. They must be separated by a space.
input=/home/user_name/.dogtag/nssdb/request.csr

### output: full path for the CMC request in binary format
output=/home/user_name/.dogtag/nssdb/cmc-request.bin

### tokenname: name of the token where agent signing cert can be found (default is internal)
tokenname=internal
request.useSharedSecret=true

### nickname: nickname for the agent certificate which will be used to sign the CMC full request. This is not needed for shared secret enrollments.
#nickname=

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

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

### format: request format, pkcs10 if request is created using PKCS10Client, or crmf if request created using CRMFPopClient
format=<pkcs10 or crmf>

### identityProofV2.enable: if true, then the request will contain this control. Otherwise, false.
### Note that if both identityProof and identityProofV2 are enabled,
### identityProofV2 takes precedence; Only one of them can be active at a time
### Supported hashAlg are:
### SHA-256, SHA-384, and SHA-512
### Supported macAlg are:
### SHA-256-HMAC, SHA-384-HMAC, and SHA-512-HMAC
identityProofV2.enable=true
identityProofV2.hashAlg=SHA-512
identityProofV2.macAlg=SHA-256-HMAC

### identityProofV2.sharedSecret: Shared Secret
### The shared secret passphrase assigned when creating shared token with CMCSharedToken command
witness.sharedSecret=<shared secret>

popLinkWitnessV2.enable=true
popLinkWitnessV2.keyGenAlg=SHA-256
popLinkWitnessV2.macAlg=SHA-256-HMAC

request.privKeyId=<output from PKCS10Client | CRMFPopClient xxx.priv>

### identification works with identityProofV2
identification.enable=true
identification=<The UID of the requesting user in LDAP>

注意

您可以在 规划、安装和部署指南(Common criteria Edition)中的"测试 CMC 共享令牌"中找到更完整的 CMC 注册到 共享机密。

5.3.2.3. 为用户获取仅限加密的证书
复制链接

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

注意

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

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

作为用户：

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

5.3.2.3.1. 使用密钥 Archival 获取仅加密证书的示例
复制链接

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

注意

以下流程描述了用于仅加密密钥的双行颁发，这些密钥无法用于签名。如果您使用可签署证书的密钥，请将 -q POP_SUCCESS 选项而不是 -q POP_NONE 传递给 CRMFPopClient 实用程序，以进行单行颁发。

获取仅加密证书的过程只需要使用带有 POP_NONE 选项的 CRMPopClient 生成 CRMF 请求。有关将 CRMFPopClient 与 POP_SUCCESS 搭配使用的说明，请参阅第 5.2.3.1 节 “使用 CRMFPopClient 创建带有密钥 archival 的 CSR” 和第 5.2.3.2 节 “使用 CRMFPopClient 为基于 SharedSecret 的 CMC 创建 CSR”。

生成 CSR

切换到请求证书的用户或实体的证书数据库目录，例如：
```
$ cd /home/user_name/.dogtag/nssdb/
```

搜索 KRA 传输证书。例如：

$ pki -p 8443 ca-cert-find --name "DRM Transport Certificate"

使用您在上一步中检索的 KRA 传输证书的序列号，将证书存储在文件中。例如，要将带有 12345 序列号的证书存储在 kra.transport 文件中：
```
$ pki -p 8443 ca-cert-export 12345 --output kra.transport
```

使用 CRMFPopClient 实用程序创建带有 POP_NONE 的 CRMF 请求，其中 RSA 私钥由 KRA 传输证书包装。例如，要生成并存储 /home/user_name/.dogtag/nssdb/crmf.req 文件中的请求：

$ CRMFPopClient -d . -p token_password -n "cn=subject_name" -q POP_NONE -b kra.transport -w "AES KeyWrap/Wrapped" -v -o crmf.req -oaep

Initializing security database: .
archival option enabled
Loading transport certificate
Parsing subject DN
RDN: CN=subject_name
Generating key pair: temporary: false
CryptoUtil: generateRSAKeyPair: calling kg.setKeyPairUsages
Keypair private key id: 2500b867acad0064bdba3fde9762a3ff1487fcfa
Using key wrap algorithm: AES KeyWrap/Wrapped
Creating certificate request
Creating CRMF request
Storing CRMF request into crmf.req
Storing CRMF request key id into crmf.req.keyId

CMCRequest 第一行(EncryptedPop)

为 CMCRequest 程序创建一个配置文件，如 cmc-crmf-request.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/.dogtag/nssdb/crmf.req

#output: full path for the CMC request in binary format
output=/home/user_name/.dogtag/nssdb/cmc-round_1.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

decryptedPop.enable=false
request.selfSign=false

创建 CMC 请求：

$ CMCRequest cmc-crmf-request.cfg

cert/key prefix =
path = /home/user_name/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: signing_certificate
createPKIData: begins
k=0
createPKIData:  format: crmf
useSharedSecret is false...
signData: begins:
getPrivateKey: got signing cert
signData:  got signer privKey
createSignedData: begins
getSigningAlgFromPrivate: begins.
getSigningAlgFromPrivate: found signingKeyType=EC
getSigningAlgFromPrivate: using SignatureAlgorithm: ECSignatureWithSHA256Digest
createSignedData: digest created for pkidata
createSignedData: digest algorithm =ECSignatureWithSHA256Digest
createSignedData: building cert chain
signData: signed request generated.
getCMCBlob: begins
getCMCBlob: generating signed data

The CMC enrollment request in base-64 encoded format:

. . . output omitted . . .


The CMC enrollment request in binary format is stored in /home/user_name/.dogtag/nssdb/cmc-round_1.req

如果命令成功，CMCRequest 工具会将 CMC 请求存储在请求配置文件的 output 参数中指定的文件中。

为 HttpClient 创建配置文件（如 cmc-submit.cfg ）以用于稍后的步骤中，将 CMC 请求提交到 CA。在创建的文件中添加以下内容：

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

#port: CA 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/.dogtag/nssdb/cmc-round_1.req

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

#tokenname: name of token where TLS mutual 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

将 CMC 请求提交到 CA：

$ HttpClient cmc-submit.cfg

Total number of bytes read = 5578
after SSLSocket created, thread token is NSS FIPS 140-2 User Private Key
client cert is not null
handshake happened
writing to socket

Response Headers begin
HTTP/1.1 200
Content-Type: application/pkcs7-mime
Content-Length: 3317
Date: Thu, 25 Jan 2024 21:58:32 GMT
Connection: close
End

Total number of bytes read = 3317

. . . output omitted . . .

The response in binary format is stored in /home/user_name/.dogtag/nssdb/cmc-response_round_1.bin

如果命令成功，HTTPClient 实用程序会将 CMC 响应存储在配置文件 output 参数中指定的文件中。

将响应文件传递给 CMCResponse 工具来验证响应。例如：

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

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

Certificates:
    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x425C240
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
            Validity:
                Not Before: Thursday, September 28, 2023 4:06:41 PM EDT America/New_York
                Not  After: Monday, September 28, 2043 4:06:41 PM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
...
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
CMC Full Response.
ERROR: CMC status for [1]: pop required

CMCRequest second trip (DecryptedPop)

对于第二行，为 DecryptedPOP 创建一个配置文件，如 /home/user_name/.dogtag/nssdb/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 the 2nd trip
input=/home/user_name/.dogtag/nssdb/crmf.req

#output: full path for the CMC request in binary format
#this field is actually unused in 2nd trip
output=/home/user_name/.dogtag/nssdb/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
request.selfSign=false
oaep=true
encryptedPopResponseFile=/home/user_name/.dogtag/nssdb/cmc-response_round_1.bin

request.privKeyId=-25aa0a8aad395ebac7e6a19c364f0dcb5350cfef
decryptedPopRequestFile=/home/user_name/.dogtag/nssdb/cmc.DecryptedPOP.req

注意

对于 request.privKeyId= 参数值，请输入在运行 CRMFPopClient 后保存的私钥 ID，如 crmf.req.keyId。

创建 DecryptPOP CMC 请求：

$ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg

cert/key prefix =
path = /home/user_name/.dogtag/nssdb
CryptoManger initialized
token internal logged in...
got signerCert: signing_certificate
got request privKeyId: -5db9e71d7f6fbf8cca8dba3f933aa1beea69fb5f
got private key
processEncryptedPopResponse:  begins.
processEncryptedPopResponse:  previous response read.
processEncryptedPopResponse: Number of controls is 3
processEncryptedPopResponse: Control #0: CMC encrypted POP
processEncryptedPopResponse:    OID: {1 3 6 1 5 5 7 7 9}
processEncryptedPopResponse:      encryptedPOP decoded successfully
processEncryptedPopResponse: Control #1: CMCStatusInfoV2
processEncryptedPopResponse:    OID: {1 3 6 1 5 5 7 7 25}
processEncryptedPopResponse:    BodyList: 1
processEncryptedPopResponse:    OtherInfo type: FAIL
processEncryptedPopResponse:      failInfo=POP required
processEncryptedPopResponse:    what we expected, as decryptedPOP.enable is true;
processEncryptedPopResponse: Control #2: CMC ResponseInfo
processEncryptedPopResponse:    requestID: 256
processEncryptedPopResponse: ends
constructDecryptedPopRequest: begins
constructDecryptedPopRequest:  previous response parsed.
constructDecryptedPopRequest: symKey unwrapped.
constructDecryptedPopRequest: challenge decrypted.
constructDecryptedPopRequest: Yay! witness verified
constructDecryptedPopRequest: calculating POP Proof Value
constructDecryptedPopRequest: popProofValue length = 32
constructDecryptedPopRequest: constructing DecryptedPOP...
constructDecryptedPopRequest: DecryptedPOP constructed successfully
constructDecryptedPopRequest: adding decryptedPop control
constructDecryptedPopRequest: decryptedPop control added
constructDecryptedPopRequest: regInfo control added
constructDecryptedPopRequest:  completes.
useSharedSecret is false...
signData: begins:
getPrivateKey: got signing cert
signData:  got signer privKey
createSignedData: begins
getSigningAlgFromPrivate: begins.
getSigningAlgFromPrivate: found signingKeyType=EC
getSigningAlgFromPrivate: using SignatureAlgorithm: ECSignatureWithSHA256Digest
createSignedData: digest created for pkidata
createSignedData: digest algorithm =ECSignatureWithSHA256Digest
createSignedData: building cert chain
signData: signed request generated.
getCMCBlob: begins
getCMCBlob: generating signed data

The CMC enrollment request in base-64 encoded format:

. . . output omitted . .


The CMC enrollment request in binary format is stored in /home/user_name/.dogtag/nssdb/cmc.DecryptedPOP.req

如果命令成功，CMCRequest 实用程序将 CMC 请求存储在请求配置文件中的 decryptedPopRequestFile 参数中指定的文件中。

为 HttpClient 创建配置文件（如 decrypted_POP_cmc-submit.cfg ）以便在稍后的步骤中使用，将 DecryptedPOP CMC 请求提交到 CA。在创建的文件中添加以下内容：

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

#port: CA 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/.dogtag/nssdb/cmc.DecryptedPOP.req

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

#tokenname: name of token where TLS mutual 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/profileSubmitCMCFull?profileId=caFullCMCUserSignedCert

将 DecryptedPOP CMC 请求提交到 CA：

$ HttpClient decrypted_POP_cmc-submit.cfg

Total number of bytes read = 5676
after SSLSocket created, thread token is NSS FIPS 140-2 User Private Key
client cert is not null
handshake happened
writing to socket

Response Headers begin
HTTP/1.1 200
Content-Type: application/pkcs7-mime
Content-Length: 4210
Date: Fri, 26 Jan 2024 00:41:57 GMT
Connection: close
end

Total number of bytes read = 4210

. . . output omitted . . .


The response in binary format is stored in /home/user_name/.dogtag/nssdb/cmc-response_round_2.bin

如果命令成功，HTTPClient 实用程序会将 CMC 响应存储在配置文件 output 参数中指定的文件中。

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

$ CMCResponse -i cmc-response_round_2.bin -o encryption_only_certs.p7

或者，要以 PEM 格式显示单个证书，请将 -v 传递给实用程序。

如果第二个往返成功，CMCResponse 会显示类似于如下的输出：

Certificates:
    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x35EEA2A
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA
            Validity:
                Not Before: Thursday, January 25, 2024 5:09:51 PM EST America/New_York
                Not  After: Tuesday, July 23, 2024 5:09:51 PM EDT America/New_York
            Subject: CN=user_name,UID=example,OU=keyArchivalExample

. . .

Number of controls is 1
Control #0: CMCStatusInfoV2
   OID: {1 3 6 1 5 5 7 7 25}
   BodyList: 1
   Status: SUCCESS
CMC Full Response.

PKCS#7 now stored in file: encryption_only_certs.p7

成功签发证书后，用户可以将证书导入到自己的 /home/user_name/.dogtag/nssdb/ 数据库中。例如：

# pki -d /home/user_name/.dogtag/nssdb/ -c <password> client-cert-import "user_name certificate" --cert encryption_only_certs.p7

5.3. 使用 CMC 请求和接收证书

5.3.1. CMC 注册过程
复制链接

5.3.2. 实际 CMC 注册场景
复制链接

5.3.2.1. 获取系统和服务器证书
复制链接

5.3.2.2. 获取用户的第一个签名证书
复制链接

5.3.2.2.1. 使用代理证书签署 CMC 请求
复制链接

5.3.2.2.2. 使用共享 secret 为证书注册进行身份验证
复制链接

5.3.2.3. 为用户获取仅限加密的证书
复制链接

5.3.2.3.1. 使用密钥 Archival 获取仅加密证书的示例
复制链接

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

5.3. 使用 CMC 请求和接收证书

5.3.1. CMC 注册过程复制链接链接已复制到粘贴板!

5.3.2. 实际 CMC 注册场景复制链接链接已复制到粘贴板!

5.3.2.1. 获取系统和服务器证书复制链接链接已复制到粘贴板!

5.3.2.2. 获取用户的第一个签名证书复制链接链接已复制到粘贴板!

5.3.2.2.1. 使用代理证书签署 CMC 请求复制链接链接已复制到粘贴板!

5.3.2.2.2. 使用共享 secret 为证书注册进行身份验证复制链接链接已复制到粘贴板!

5.3.2.3. 为用户获取仅限加密的证书复制链接链接已复制到粘贴板!

5.3.2.3.1. 使用密钥 Archival 获取仅加密证书的示例复制链接链接已复制到粘贴板!

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

5.3.1. CMC 注册过程
复制链接

5.3.2. 实际 CMC 注册场景
复制链接

5.3.2.1. 获取系统和服务器证书
复制链接

5.3.2.2. 获取用户的第一个签名证书
复制链接

5.3.2.2.1. 使用代理证书签署 CMC 请求
复制链接

5.3.2.2.2. 使用共享 secret 为证书注册进行身份验证
复制链接

5.3.2.3. 为用户获取仅限加密的证书
复制链接

5.3.2.3.1. 使用密钥 Archival 获取仅加密证书的示例
复制链接