4.4. Issuing Certificates Using CMC

This section describes the procedure to enroll a certificate using Certificate Management over CMS (CMC).
For general information about configuration and the workflow of enrolling certificates using CMC, see:
CMC enrollment is possible in various ways to meet the requirements for different scenarios. Section 4.4.1, “The CMC Enrollment Process” supplements the Enrolling with CMC section in the Red Hat Certificate System Planning, Installation, and Deployment Guide with more details. Additionally, the Section 4.4.2, “Practical CMC Enrollment Scenarios” section enables administrators to decide which mechanisms should be used in which scenario.

4.4.1. The CMC Enrollment Process

Use the following general procedure to request and issue a certificate using CMC:
  1. Create a Certificate Signing Request (CSR) in one of the following formats:
    • PKCS #10 format: 
      # PKCS10Client -d /home/user_name/.dogtag/nssdb/ -p password \
    -n "CN=subCA Signing Certificate,OU=pki-tomcat,O=security_domain" \
    -o /home/user_name/ca_pkcs10.req
    • Certificate Request Message Format (CRMF) format: 
      # CRMFPopClient -d /home/user_name/.dogtag/nssdb/ -p password \
     -n "cn=user, uid=test" -q POP_SUCCESS -b kra.transport -y -v \
     -o /home/user_name/crmf.req
  2. Create a configuration file for a CMC request, such as /home/user_name/cmc-request.cfg, with the following content: 
    # 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
    For further details, see the CMCRequest(1) man page.
  3. Create the CMC request: 
    # CMCRequest /home/user_name/cmc-request.cfg
    If the command succeeds, the CMCRequest utility stored the CMC request in the file specified in the output parameter in the request configuration file.
  4. Create a configuration file for HttpClient, such as /home/user_name/cmc-submit.cfg, which you use in a later step to submit the CMC request to the CA. Add the following content to the created file: 
    # PKI server host name
host=server.example.com

# PKI server port number
port=8443

# Use secure connection
# For secure connection with ECC, set environment variable
# 'export NSS_USE_DECODED_CKA_EC_POINT=1'.
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
  5. Depending on what type of certificate you request, add the following parameter to the configuration file created in the previous step: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
    For example, for a CA signing certificate: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
  6. Submit the CMC request to the CA: 
    # HttpClient /home/user_name/cmc-submit.cfg
  7. To convert the CMC response to a PKCS #7 certificate chain, pass the CMC response file to the -i parameter of the CMCResponse utility. For example: 
    # CMCResponse -i /home/user_name/cmc-response.bin -o /home/user_name/cert_chain.crt

4.4.2. Practical CMC Enrollment Scenarios

This section describes frequent practical usage scenarios and their workflows to enable CA administrators to decide which CMC method to use in which situation.
For a general process of enrolling a certificate using CMC, see Section 4.4.1, “The CMC Enrollment Process”.

4.4.2.1. Obtaining System and Server Certificates

If a service, such as LDAP or a web server, requires a TLS server certificate, the administrator of this server creates a CSR based on the documentation of the service and sends it to the CA's agent for approval. Use the procedure described in Section 4.4.1, “The CMC Enrollment Process” for this process. Additionally, consider the following requirements:
Enrollment Profiles
The agent must either use one of the existing CMC profiles listed in Section 12.11.2.1, “CMC Authentication Plug-ins” or, alternatively, create a custom profile that uses the CMCAuth authentication mechanism.
CMC Signing Certificate
For system certificates, the CA agent must generate and sign the CMC request. For this, set the nickname parameter in the CMCRequest configuration file to the nickname of the CA agent.

Note

The CA agent must have access to the own private key.
HttpClient SSL Client Nickname
Use the same certificate for signing in the CMCRequest utility's configuration file as for SSL client authentication in the configuration file for HttpClient.
HttpClient servlet Parameter
The servlet in the configuration file passed to the HttpClient utility refers to the CMC servlet and the enrollment profile which handles the request.
Depending on what type of certificate you request, add one of the following entries to the configuration file created in the previous step:
  • For a CA signing certificate: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
  • For a KRA transport certificate: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCkraTransportCert
  • For a OCSP signing certificate: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCocspCert
  • For a audit signing certificate: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCauditSigningCert
  • For a subsystem certificate:
    • For RSA certificates: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCsubsystemCert
    • For ECC certificates: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCsubsystemCert
  • For an SSL server certificate:
    • For RSA certificates: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
    • For ECC certificates: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCserverCert
  • For an admin certificate: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
Further details:
  • When an agent pre-signs a CSR, the Proof of Identification is considered established because the agent examines the CSR for identification. No additional CMC-specific identification proof is required.
  • PKCS #10 files already provide Proof of Possession information and no additional Proof of Possession (POP) is required.
  • In agent pre-approved requests, the PopLinkWittnessV2 feature must be disabled because the identification is checked by the agent.

4.4.2.2. Obtaining the First Signing Certificate for a User

There are two ways to approve a user's first signing certificate:
4.4.2.2.1. Signing a CMC Request with an Agent Certificate
The process for signing a CMC request with an agent certificate is the same as for system and server certificates described in Section 4.4.2.1, “Obtaining System and Server Certificates”. The only difference is that the user creates the CSR and sends it to a CA agent for approval.
4.4.2.2.2. Authenticating for Certificate Enrollment Using a Shared Secret
When a user wants to obtain the first signing certificate and the agent cannot approve the request as described in Section 4.4.2.2.1, “Signing a CMC Request with an Agent Certificate”, you can use a Shared Token. With this token, the user can obtain the first signing certificate. This certificate can then be used to sign other certificates of the user.
In this scenario, use the Shared Secret mechanism to obtain the first signing certificate of the user. Use the following information together with Section 4.4.1, “The CMC Enrollment Process”:
  1. Create a Shared Token either as the user or CA administrator. For details, see Section 12.11.4.2, “Creating a Shared Secret Token”.
    Note that:
    • If the user created the token, the user must send the token to the CA administrator.
    • If the CA administrator created the token, the administrator must share the password used to generate the token with the user. Use a secure way to transmit the password.
  2. As the CA administrator, add the Shared Token to the user entry in LDAP. For details, see Section 12.11.4.3.1, “Adding a CMC Shared Secret to a User Entry for Certificate Enrollment”.
  3. Use the following parameters in the configuration file passed to the CMCRequest utility:
    • identification.enable
    • witness.sharedSecret
    • identityProofV2.enable
    • identityProofV2.hashAlg
    • identityProofV2.macAlg
    • request.selfSign
    • request.privKeyId
  4. If required by the CA, additionally use the following parameters in the configuration file passed to the CMCRequest utility:
    • popLinkWitnessV2.enable
    • popLinkWitnessV2.keyGenAlg
    • popLinkWitnessV2.macAlg

4.4.2.3. Obtaining an Encryption-only Certificate for a User

This section describes the workflow for obtaining an encryption-only certificate which is signed with an existing user signing certificate:

Note

If a user owns multiple certificates for different usages, where one is signing, the user must obtain the signing certificate first. Once the user owns a signing certificate, it can be used for Proof Of Origin without requiring to set up and rely on the CMC Shared Secret mechanism.
For details about obtaining a user's first signing certificate, see Section 4.4.2.2, “Obtaining the First Signing Certificate for a User”.
As a user:
  1. Use the cryptographic token stored in a Network Security Services (NSS) database or on a smart card that contains the user's signing certificate and keys.
  2. Generate the CSR in PKCS #10 or the CRMF format.

    Note

    Use the CRMF format, if key archival is required.
  3. Generate the CMC request.
    Since this is an encryption-only certificate, the private key is not able to sign. Therefore, Proof Of Possession (POP) is not included. For this reason, the enrollment requires two steps: If the initial request is successful, results in a CMC status with the EncryptedPOP control. The user then uses the response and generates a CMC request that contains the DecryptedPOP control and submits it in the second step.
    1. For the first step, in addition to the default parameters, the user must set the following parameters in the configuration file passed to the CMCRequest utility:
      • identification.enable
      • witness.sharedSecret
      • identityProofV2.enable
      • identityProofV2.hashAlg
      • identityProofV2.macAlg
      • popLinkWitnessV2.enable if required by the CA
      • popLinkWitnessV2.keyGenAlg if required by the CA
      • popLinkWitnessV2.macAlg if required by the CA
      • request.privKeyId
      For details, see the CMCRequest(1) man page.
      The response contains:
      • A CMC encrypted POP control
      • The CMCStatusInfoV2 control with the POP required error
      • The request ID
    2. For the second step, in addition to the default parameters, the user must set the following parameters in the configuration file passed to the CMCRequest utility:
      • decryptedPop.enable
      • encryptedPopResponseFile
      • decryptedPopRequestFile
      • request.privKeyId
      For details, see the CMCRequest(1) man page.