Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

Chapter 7. Installing and configuring Red Hat Certificate System

Red Hat Certificate System provides different subsystems that can be installed individually. For example, you can install multiple subsystem instances on a single server or you can run them independently on different hosts. This enables you to adapt the installation to your environment to provide a higher availability, scalability, and fail-over support.

In a Common Criteria evaluated environment, the Certificate System includes the following subsystems:

  • Certificate Authority (CA)
  • Key Recovery Authority (KRA)
  • Online Certificate Status Protocol (OCSP) Responder
  • Token Key Service (TKS)
  • Token Processing System (TPS)
Note

TKS and TPS are for TMS (Token Management System) only.

Each subsystem is installed and configured individually as a standalone Tomcat web server instance.

Important

The order in which the individual subsystems are set up is important because of relationships between the different subsystems:

  1. At least one CA running as a security domain is required before any of the other public key infrastructure (PKI) subsystems can be installed.
  2. Install the OCSP after you have configured the CA.
  3. The KRA and TKS subsystems can be installed in any order, after you have configured the CA and OCSP.
  4. The TPS subsystem depends on the CA and TKS, and optionally on the KRA and OCSP subsystem.
Note

For a non-TMS setup, you can install CA, OCSP, and KRA subsystems, while in a TMS setup, you can install CA, OCSP, KRA, TKS, and TPS.

Note

In general, it is more secure to store passwords in an adequately protected file rather than entering them on the command line. However, for ease of demonstration, this example installation procedure may specify passwords as command-line parameters.

Note

Please note that during installation, before the system is up and running, you will see that we instruct readers to configure the system by editing the files directly. However, for auditing purposes, once a PKI instance is installed, PKI administrators are expected to use the appropriate CLI (as demonstrated when applicable) or pkiconsole (becoming deprecated) to configure the PKI instances.
In the examples that follow, you will see a mix of both methods being used. The CLI examples are shown in some cases to help the reader get familiar with them as an alternative, before they start using them post-installation.

7.1. Preparing a pkispawn setup
Copiar o link

The following sections describe the preparation for a RSA Common Criteria setup on a RHEL 8.6 operating system.

7.1.1. Creating OS users and groups
Copiar o link

When installing Red Hat Certificate System, the pkiuser account and the corresponding pkiuser group are automatically created. Certificate System uses this account and group to start services.

This section describes the creation of users and groups on the OS that hosts the RHCS system; rhcs10.example.com in this example.

pkiadmin is a group at the OS level which allows users under this group to have access to PKI files. This group should contain the following users:

  • pkiuser, which is the default user that owns PKI files at installation and runs PKI processes upon installation.
  • Members that belong to the "Administrators" group of a PKI/CS instance. These are assigned pkiadmin OS membership because they need to have access to certain PKI configuration files at times. As part of a post-installation procedure, you will later be instructed to create an OS user for each Certificate System administrator who should be able to start and stop or directly configure the instance on the operating system. For details, see Section 7.13, “Post-installation”.

Other PKI roles such as Agents and Auditors do not have direct access to the PKI/CS files on the OS file systems, so they are only recognized and authenticated through a PKI/CS instance.

For the purpose of this example, three OS users will be created to serve the three distinct PKI roles:

  • jgenie (Jane Genie): this non-root user belongs to the pkiadmin administrator group on the OS, as well as to the PKI Administrators group.
  • jsmith (John Smith): a non-root regular user on the OS, but belongs to the PKI Agents group.
  • aguru (Astrid Guru): a non-root regular user on the OS, but belongs to the PKI Auditors group.

Procedure:

  1. Create an OS administrator group (e.g. pkiadmin): 

    # /usr/sbin/groupadd -r pkiadmin
    Copy to Clipboard Toggle word wrap

  2. Create OS users:

    1. Create an OS user that belongs to the OS group pkiadmin (e.g. Jane Genie - jgenie). In our example, this person will serve as a PKI Administrator user: 

      # /usr/sbin/useradd -g pkiadmin -d /home/jgenie -s /bin/bash -c "Red Hat Certificate System Administrator Jane Genie" -m jgenie
      Copy to Clipboard Toggle word wrap

    2. Create an OS user (e.g John Smith - jsmith). In our example, this person will serve as a PKI Agent user: 

      # /usr/sbin/useradd -c "Red Hat Certificate System Agent John Smith" -m jsmith
      Copy to Clipboard Toggle word wrap

    3. Create an OS user (e.g. Astrid Guru - aguru). In our example, this person will serve as a PKI Auditor user: 

      # /usr/sbin/useradd -c "Red Hat Certificate System Auditor Astrid Guru" -m aguru
      Copy to Clipboard Toggle word wrap

  3. Associate pkiuser with the pkiadmin and nfast groups: 

    # /usr/sbin/usermod -a -G pkiadmin pkiuser
    Copy to Clipboard Toggle word wrap 
    # /usr/sbin/usermod -a -G nfast pkiuser
    Copy to Clipboard Toggle word wrap
    NOTE

    If using a Thales Luna HSM, associate pkiuser with the hsmusers group (instead of nfast): 

    # /usr/sbin/usermod -a -G hsmusers pkiuser
    Copy to Clipboard Toggle word wrap

    Please see Section 4.4, “Supported Hardware Security Modules” for more information on Luna’s limitations.

  4. Since the tests in this example use an Entrust HSM, associate the users who are to administer the HSM device with the nfast group: 

    # /usr/sbin/usermod -a -G nfast jgenie
    Copy to Clipboard Toggle word wrap
    NOTE

    Again, if using a Thales Luna HSM, associate the users who are to administer the HSM device with the hsmusers group (instead of nfast). For example: 

    # /usr/sbin/usermod -a -G hsmusers jgenie
    Copy to Clipboard Toggle word wrap

    Please see Section 4.4, “Supported Hardware Security Modules” for more information on Luna’s limitations.

Verification:

  • List the groups pkiuser and jgenie belong to: 

    # groups pkiuser jgenie

pkiuser : pkiuser nfast pkiadmin

jgenie : pkiadmin nfast
    Copy to Clipboard Toggle word wrap
Note

At a later stage, once you have completed the SubCA installation, you will be instructed on how to get user certificates issued for these PKI role users individually, in order for them to perform their privileged functions.

7.1.2. Installing and configuring the DS instances
Copiar o link

Install and configure DS instances on the second machine, e.g. rhds11.example.com. For the purpose of our examples, we are creating the following instances:

  • CC-RSA-RootCA-LDAP: the internal database for the RootCA instance
  • CC-RSA-OCSP-rootca-LDAP: the internal database for the RootCA’s OCSP instance (optional: see Section 7.1.2.2, “Installing a DS instance for the RootCA’s OCSP”)
  • CC-RSA-SubCA-LDAP: the internal database for the SubCA
  • CC-RSA-OCSP-subca-LDAP: the internal database for the SubCA’s OCSP instance
  • CC-RSA-KRA-LDAP: the internal database for the KRA
  • CC-RSA-TKS-LDAP: if TMS is of interest, this instance will act as the internal database and the authentication database for the TKS
  • CC-RSA-TPS-LDAP: if TMS is of interest, this instance will act as the internal database and the authentication database for the TPS
Important

Before proceeding, make sure you have followed the Chapter 6, Prerequisites for installation.

7.1.2.1. Installing a DS instance for the RootCA
Copiar o link

The DS instance CC-RSA-RootCA-LDAP will host the RootCA’s internal database. It is listening over the standard LDAP/LDAPS ports, 389 and 636, respectively.

The port numbers used by this example are listed under Section 6.8, “Adding ports to the firewall and with SELinux context”.

On rhds11.example.com:

  1. Create the RootCA directory server installation file at a chosen location (e.g. /root/pki_rsa): 

    # vim /root/pki_rsa/rootca-ldap.cfg

[general]
full_machine_name = rhds11.example.com

[slapd]
port = 389
secure_port = 636
instance_name = CC-RSA-RootCA-LDAP
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
create_suffix_entry = True
suffix = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    Important

    Make sure you specify the FQDN (see Section 6.3, “Setting the FQDN”) of the machine hosting the Directory Server instance in the full_machine_name, and that the suffix matches.

  2. Optional: To view other configuration options for future reference, you can create a template file using the dscreate create-template command: 

    # dscreate create-template /root/pki_rsa/ldap-template.cfg
    Copy to Clipboard Toggle word wrap

  3. Set up the directory server instance using the .cfg file: 

    # dscreate from-file /root/pki_rsa/rootca-ldap.cfg

Starting installation...

Completed installation for CC-RSA-RootCA-LDAP
    Copy to Clipboard Toggle word wrap
Note

By default for each new Directory Server instance, a bootstrap SSL server certificate with the nickname "Server-Cert" is created for temporary use. It is issued by a bootstrap self-signed CA certificate with the nickname "Self-Signed-CA".

The /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/dse.ldif file has nsslapd-security: on and nsSSLPersonalitySSL: Server-Cert.

Verification:

  1. List the bootstrap certificates to verify: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
Self-Signed-CA                                  CT,,
Server-Cert                                     u,u,u
    Copy to Clipboard Toggle word wrap

  2. Export the certificate: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-rootca-cert.pem
    Copy to Clipboard Toggle word wrap

  3. Copy the certificate to rhcs10.example.com: 

    # scp /opt/pki_rsa/temp-dirsrv-rootca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-rootca-cert.pem
    Copy to Clipboard Toggle word wrap

  4. Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-rootca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

  5. Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-rootca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    The LDAP search should be successful, e.g: 

    # extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
    Copy to Clipboard Toggle word wrap

7.1.2.2. Installing a DS instance for the RootCA’s OCSP
Copiar o link

Note

In general, a root CA is not recommended for doing day-to-day certificate issuance. Therefore, an OCSP for the root CA is not required. In the example that follows, the RootCA’s OCSP is only presented for demonstration purposes.

The DS instance CC-RSA-OCSP-rootca-LDAP will host the internal database for the RootCA’s OCSP. It is listening over the standard LDAP/LDAPS ports, 6389 and 6636, respectively.

The port numbers used by this example are listed under Section 6.8, “Adding ports to the firewall and with SELinux context”.

On rhds11.example.com:

  1. Create the RootCA’s OCSP directory server installation file at a chosen location (e.g. /root/pki_rsa): 

    # vim /root/pki_rsa/ocsp-rootca-ldap.cfg

[general]
full_machine_name = rhds11.example.com

[slapd]
port = 6389
secure_port = 6636
instance_name = CC-RSA-OCSP-rootca-LDAP
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
create_suffix_entry = True
suffix = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    Important

    Make sure you specify the FQDN (see Section 6.3, “Setting the FQDN”) of the machine hosting the Directory Server instance in the full_machine_name, and that the suffix matches.

  2. Set up the directory server instance using the .cfg file: 

    # dscreate from-file /root/pki_rsa/ocsp-rootca-ldap.cfg

Starting installation...

Completed installation for CC-RSA-OCSP-rootca-LDAP
    Copy to Clipboard Toggle word wrap
Note

By default for each new Directory Server instance, a bootstrap SSL server certificate with the nickname "Server-Cert" is created for temporary use. It is issued by a bootstrap self-signed CA certificate with the nickname "Self-Signed-CA".

The /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/dse.ldif file has nsslapd-security: on and nsSSLPersonalitySSL: Server-Cert.

Verification:

  1. List the bootstrap certificates to verify: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
Self-Signed-CA                                  CT,,
Server-Cert                                     u,u,u
    Copy to Clipboard Toggle word wrap

  2. Export the certificate: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-ocsp-rootca-cert.pem
    Copy to Clipboard Toggle word wrap

  3. Copy the certificate to rhcs10.example.com: 

    # scp /opt/pki_rsa/temp-dirsrv-ocsp-rootca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-ocsp-rootca-cert.pem
    Copy to Clipboard Toggle word wrap

  4. Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-ocsp-rootca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:6636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

  5. Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-ocsp-rootca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:6636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    The LDAP search should be successful, e.g: 

    # extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
    Copy to Clipboard Toggle word wrap

7.1.2.3. Installing a DS instance for the SubCA
Copiar o link

The DS instance CC-RSA-SubCA-LDAP will host the SubCA’s internal database. It is listening over the LDAP/LDAPS ports, 7389 and 7636 respectively.

The port numbers used by this example are listed under Section 6.8, “Adding ports to the firewall and with SELinux context”.

On rhds11.example.com:

  1. Create the SubCA directory server installation file at a chosen location (e.g. /root/pki_rsa): 

    # vim /root/pki_rsa/subca-ldap.cfg

[general]
full_machine_name = rhds11.example.com

[slapd]
port = 7389
secure_port = 7636
instance_name = CC-RSA-SubCA-LDAP
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
create_suffix_entry = True
suffix = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    Important

    Make sure you specify the FQDN (see Section 6.3, “Setting the FQDN”) of the machine hosting the Directory Server instance in the full_machine_name, and that the suffix matches.

  2. Set up the directory server instance using the .cfg file: 

    # dscreate from-file /root/pki_rsa/subca-ldap.cfg

Starting installation...

Completed installation for CC-RSA-SubCA-LDAP
    Copy to Clipboard Toggle word wrap
Note

By default for each new Directory Server instance, a bootstrap SSL server certificate with the nickname "Server-Cert" is created for temporary use. It is issued by a bootstrap self-signed CA certificate with the nickname "Self-Signed-CA".

The /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/dse.ldif file has nsslapd-security: on and nsSSLPersonalitySSL: Server-Cert.

Verification:

  1. List the bootstrap certificates to verify: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
Self-Signed-CA                                  CT,,
Server-Cert                                     u,u,u
    Copy to Clipboard Toggle word wrap

  2. Export the certificate: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-subca-cert.pem
    Copy to Clipboard Toggle word wrap

  3. Copy the certificate to rhcs10.example.com: 

    # scp /opt/pki_rsa/temp-dirsrv-subca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-subca-cert.pem
    Copy to Clipboard Toggle word wrap

  4. Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-subca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:7636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

  5. Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-subca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:7636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    The LDAP search should be successful, e.g: 

    # extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
    Copy to Clipboard Toggle word wrap

7.1.2.4. Installing a DS instance for the SubCA’s OCSP
Copiar o link

The DS instance CC-RSA-OCSP-subca-LDAP will host the internal database for the SubCA’s OCSP. It is listening over the LDAP/LDAPS ports, 11389 and 11636 respectively.

The port numbers used by this example are listed under Section 6.8, “Adding ports to the firewall and with SELinux context”.

On rhds11.example.com:

  1. Create the SubCA’s OCSP directory server installation file at a chosen location (e.g. /root/pki_rsa): 

    # vim /root/pki_rsa/ocsp-subca-ldap.cfg

[general]
full_machine_name = rhds11.example.com

[slapd]
port = 11389
secure_port = 11636
instance_name = CC-RSA-OCSP-subca-LDAP
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
create_suffix_entry = True
suffix = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    Important

    Make sure you specify the FQDN (see Section 6.3, “Setting the FQDN”) of the machine hosting the Directory Server instance in the full_machine_name, and that the suffix matches.

  2. Set up the directory server instance using the .cfg file: 

    # dscreate from-file /root/pki_rsa/ocsp-subca-ldap.cfg

Starting installation...

Completed installation for CC-RSA-OCSP-subca-LDAP
    Copy to Clipboard Toggle word wrap
Note

By default for each new Directory Server instance, a bootstrap SSL server certificate with the nickname "Server-Cert" is created for temporary use. It is issued by a bootstrap self-signed CA certificate with the nickname "Self-Signed-CA".

The /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/dse.ldif file has nsslapd-security: on and nsSSLPersonalitySSL: Server-Cert.

Verification:

  1. List the bootstrap certificates to verify: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
Self-Signed-CA                                  CT,,
Server-Cert                                     u,u,u
    Copy to Clipboard Toggle word wrap

  2. Export the certificate: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-ocsp-subca-cert.pem
    Copy to Clipboard Toggle word wrap

  3. Copy the certificate to rhcs10.example.com: 

    # scp /opt/pki_rsa/temp-dirsrv-ocsp-subca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-ocsp-subca-cert.pem
    Copy to Clipboard Toggle word wrap

  4. Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-ocsp-subca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:11636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

  5. Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-ocsp-subca-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:11636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    The LDAP search should be successful, e.g: 

    # extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
    Copy to Clipboard Toggle word wrap

7.1.2.5. Installing a DS instance for the KRA
Copiar o link

The DS instance CC-RSA-KRA-LDAP will host the KRA’s internal database. It is listening over the LDAP/LDAPS ports, 22389 and 22636 respectively.

The port numbers used by this example are listed under Section 6.8, “Adding ports to the firewall and with SELinux context”.

On rhds11.example.com:

  1. Create the KRA directory server installation file at a chosen location (e.g. /root/pki_rsa): 

    # vim /root/pki_rsa/kra-ldap.cfg

[general]
full_machine_name = rhds11.example.com

[slapd]
port = 22389
secure_port = 22636
instance_name = CC-RSA-KRA-LDAP
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
create_suffix_entry = True
suffix = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    Important

    Make sure you specify the FQDN (see Section 6.3, “Setting the FQDN”) of the machine hosting the Directory Server instance in the full_machine_name, and that the suffix matches.

  2. Set up the directory server instance using the .cfg file: 

    # dscreate from-file /root/pki_rsa/kra-ldap.cfg

Starting installation...

Completed installation for CC-RSA-KRA-LDAP
    Copy to Clipboard Toggle word wrap
Note

By default for each new Directory Server instance, a bootstrap SSL server certificate with the nickname "Server-Cert" is created for temporary use. It is issued by a bootstrap self-signed CA certificate with the nickname "Self-Signed-CA".

The /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/dse.ldif file has nsslapd-security: on and nsSSLPersonalitySSL: Server-Cert.

Verification:

  1. List the bootstrap certificates to verify: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
Self-Signed-CA                                  CT,,
Server-Cert                                     u,u,u
    Copy to Clipboard Toggle word wrap

  2. Export the certificate: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-kra-cert.pem
    Copy to Clipboard Toggle word wrap

  3. Copy the certificate to rhcs10.example.com: 

    # scp /opt/pki_rsa/temp-dirsrv-kra-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-kra-cert.pem
    Copy to Clipboard Toggle word wrap

  4. Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-kra-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:22636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

  5. Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-kra-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:22636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    The LDAP search should be successful, e.g: 

    # extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
    Copy to Clipboard Toggle word wrap

7.1.2.6. Installing a DS instance for the TKS
Copiar o link

If TMS is of interest, install and configure a DS instance on rhds11.example.com, to host the TKS internal database. Red Hat Directory Server is listening over the LDAP/LDAPS ports, 16389 and 16636 respectively.

Note

Please note that TMS is not supported for ECC.

On rhds11.example.com:

  1. Create the TKS directory server installation file at a chosen location (e.g. /root/pki_rsa): 

    # vim /root/pki_rsa/tks-ldap.cfg

[general]
full_machine_name = rhds11.example.com

[slapd]
port = 16389
secure_port = 16636
instance_name = CC-RSA-TKS-LDAP
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
create_suffix_entry = True
suffix = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    Important

    Make sure you specify the FQDN (see Section 6.3, “Setting the FQDN”) of the machine hosting the Directory Server instance in the full_machine_name, and that the suffix matches.

  2. Set up the directory server instance using the .cfg file: 

    # dscreate from-file /root/pki_rsa/tks-ldap.cfg

Starting installation...

Completed installation for CC-RSA-TKS-LDAP
    Copy to Clipboard Toggle word wrap
Note

By default for each new Directory Server instance, a bootstrap SSL server certificate with the nickname "Server-Cert" is created for temporary use. It is issued by a bootstrap self-signed CA certificate with the nickname "Self-Signed-CA".

The /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/dse.ldif file has nsslapd-security: on and nsSSLPersonalitySSL: Server-Cert.

Verification:

  1. List the bootstrap certificates to verify: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
Self-Signed-CA                                  CT,,
Server-Cert                                     u,u,u
    Copy to Clipboard Toggle word wrap

  2. Export the certificate: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-tks-cert.pem
    Copy to Clipboard Toggle word wrap

  3. Copy the certificate to rhcs10.example.com: 

    # scp /opt/pki_rsa/temp-dirsrv-tks-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-tks-cert.pem
    Copy to Clipboard Toggle word wrap

  4. Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-tks-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:16636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

  5. Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-tks-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:16636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    The LDAP search should be successful, e.g: 

    # extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
    Copy to Clipboard Toggle word wrap

7.1.2.7. Installing a DS instance for the TPS
Copiar o link

If TMS is of interest, install and configure a DS instance on rhds11.example.com, to host the TPS internal database. Red Hat Directory Server is listening over the LDAP/LDAPS ports, 17389 and 17636 respectively.

On rhds11.example.com:

  1. Create the TPS directory server installation file at a chosen location (e.g. /root/pki_rsa): 

    # vim /root/pki_rsa/tps-ldap.cfg

[general]
full_machine_name = rhds11.example.com

[slapd]
port = 17389
secure_port = 17636
instance_name = CC-RSA-TPS-LDAP
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
create_suffix_entry = True
suffix = dc=example,dc=com
    Copy to Clipboard Toggle word wrap
    Important

    Make sure you specify the FQDN (see Section 6.3, “Setting the FQDN”) of the machine hosting the Directory Server instance in the full_machine_name, and that the suffix matches.

  2. Set up the directory server instance using the .cfg file: 

    # dscreate from-file /root/pki_rsa/tps-ldap.cfg

Starting installation...

Completed installation for CC-RSA-TPS-LDAP
    Copy to Clipboard Toggle word wrap
Note

By default for each new Directory Server instance, a bootstrap SSL server certificate with the nickname "Server-Cert" is created for temporary use. It is issued by a bootstrap self-signed CA certificate with the nickname "Self-Signed-CA".

The /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/dse.ldif file has nsslapd-security: on and nsSSLPersonalitySSL: Server-Cert.

Verification:

  1. List the bootstrap certificates to verify: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
Self-Signed-CA                                  CT,,
Server-Cert                                     u,u,u
    Copy to Clipboard Toggle word wrap

  2. Export the certificate: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-tps-cert.pem
    Copy to Clipboard Toggle word wrap

  3. Copy the certificate to rhcs10.example.com: 

    # scp /opt/pki_rsa/temp-dirsrv-tps-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-tps-cert.pem
    Copy to Clipboard Toggle word wrap

  4. Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-tps-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:17636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

  5. Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com: 

    # LDAPTLS_CACERT=/opt/pki_rsa/temp-dirsrv-tps-cert.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:17636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    The LDAP search should be successful, e.g: 

    # extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
description: dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
    Copy to Clipboard Toggle word wrap

7.1.3. Enabling TLS authentication between CS and its internal LDAP server
Copiar o link

This section is for general information about TLS authentication before you proceed with installing Certificate System. Actual steps with complete example installation files are presented in later sections.

The examples in Section 7.1.2, “Installing and configuring the DS instances” instructed you to set up the LDAP instances with support for TLS authentication. The following explains the parameters in the configuration file you pass to the pkispawn utility when installing Certificate System so that CS and DS can communicate via TLS. 

pki_ds_database=back_end_database_name
pki_ds_hostname=host_name
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=path_to_CA_or_self-signed_certificate
pki_ds_password=password
pki_ds_ldaps_port=port
pki_ds_bind_dn=cn=Directory Manager
Copy to Clipboard Toggle word wrap
  • The value of the pki_ds_database parameter is a name used by the pkispawn utility to create the corresponding subsystem database on the Directory Server instance.
  • The value of the pki_ds_hostname parameter depends on the install location of the Directory Server instance. This depends on the values used in Section 7.1.2, “Installing and configuring the DS instances”.

When you set pki_ds_secure_connection=True, you must set the following parameters:

  • pki_ds_secure_connection_ca_pem_file: Sets the fully-qualified path including the file name of the file which contains an exported copy of the Directory Server’s CA certificate. This file must exist prior to pkispawn being able to utilize it.
  • pki_ds_ldaps_port: Sets the value of the secure LDAPS port Directory Server is listening to. The default is 636.
Enabling TLS mutual authentication between CS and DS

Pkispawn will assume and create a basic TLS server authentication connection with the selected DS instance based on the parameters described above and used in our example settings.
However, optionally, Red Hat Certificate System can communicate with its internal LDAP server via TLS mutual authentication. After you complete the installation, you will have the possibility to make the connection require TLS mutual authentication against the Directory Server by following Section 7.13.13, “Enabling TLS mutual authentication from CS to DS” in the post-installation section.
Note that at that time, once you have set up mutual authentication, the pki_ds_password would no longer be relevant.

7.2. Installing RHCS using the pkispawn utility
Copiar o link

In Red Hat Certificate System, administrators set up the individual subsystems using the pkispawn utility. This section gives you an overall understanding of how installing using pkispawn works. Please read it carefully to ensure that you make the right choices when following the installation examples.

Note

If you are already familiar with pkispawn, you can go directly to Section 7.2.3, “Installation example (introduction)”.

7.2.1. Creating the pkispawn configuration file
Copiar o link

The pkispawn utility requires a configuration file. This file contains parameters that are grouped into sections. These sections are stacked, so that parameters defined in earlier sections can be overridden by parameters defined in later sections. The sections are read in the following order:

  1. [DEFAULT] - subsystem-independent settings
  2. [Tomcat]
  3. [CA], [KRA], [OCSP], [TKS], or [TPS] - the subsystem-specific sections

When it runs, pkispawn:

  1. Reads the default values from the /usr/share/pki/server/etc/default.cfg file. For further details, see the pki_default.cfg(5) man page.

    Important

    Do not edit the /usr/share/pki/server/etc/default.cfg file. Instead, you will be instructed to create a configuration file that will override the defaults. For details about using a configuration file, see the example pkispawn configuration files in the following sections that correspond to each different type of subsystem.

  2. Reads the administrator-provided configuration file mentioned above to override the default values.
  3. Performs the installation of the requested subsystem.
  4. Passes the settings to a Java servlet that performs the configuration based on the settings.
pkispawn settings

The following provides information on how to create a configuration file for pkispawn along with some of the major parameters. Please see the pkispawn(8) and pki_default.cfg(5) man pages, specifically /usr/share/pki/server/etc/default.cfg on details such as

  • which [ ] section a parameter belongs to or
  • the exact spelling of a parameter,
  • etc.

Create a text file for the pkispawn configuration settings, such as /root/pki/config.subsystem.txt, and fill it with the settings described below. You must add every setting under the corresponding [ ] section. You can refer to the /usr/share/pki/server/etc/default.cfg file to confirm the proper placement.

Important

This section describes a general minimum configuration with Directory Server running on the same host as Certificate System. Depending on your environment, additional parameters may be necessary. For additional examples, see the EXAMPLES section in the pkispawn(8) man page.

For descriptions about the parameters covered in this section, see the pki_default.cfg(5) man page.

Subsystem-independent settings

Independently of the subsystem you install, the following settings are required in the configuration file in the [DEFAULT] section:

  1. Set a unique instance name: 

    # pki_instance_name=instance_name
    Copy to Clipboard Toggle word wrap

  2. Set the host name: 

    # pki_hostname=server.example.com
    Copy to Clipboard Toggle word wrap
    Note

    Certificate System creates unique certificate nicknames based on these parameters and the instance name. The uniqueness of certificate nicknames is very important in keeping the HSM token shared by multiple PKI instances functional.

  3. Set the port numbers for the HTTP and HTTPS protocols: 

    pki_https_port=port_number
pki_http_port=port_number
    Copy to Clipboard Toggle word wrap
    Important

    To run more than one Certificate System instance on the same host, you must set ports in the pki_https_port and pki_http_port parameters that are not used by any other service on the host. By default, Certificate System uses port 8080 for HTTP and 8443 for HTTPS.

  4. Set the HSM-specific parameters: 

    pki_hsm_enable=True
pki_hsm_libfile=HSM_PKCS11_library_path
pki_hsm_modulename=HSM_module_name
pki_token_name=HSM_token_name
pki_token_password=HSM_token_password

pki_audit_signing_token=HSM_token_name
pki_subsystem_token=HSM_token_name
pki_sslserver_token=HSM_token_name
    Copy to Clipboard Toggle word wrap

    For further details, see Section 6.6.3, “Preparing for installing Certificate System with an HSM”.

  5. If building an RSA Certificate System instance, use the following configuration: 

    pki_admin_key_algorithm=SHA256withRSA
pki_admin_key_size=4096
pki_admin_key_type=rsa
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_key_size=4096
pki_sslserver_key_type=rsa
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_key_size=4096
pki_subsystem_key_type=rsa
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=4096
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA
    Copy to Clipboard Toggle word wrap

    Allowed choices for the key_algorithm parameters are: 

    SHA256withRSA
SHA384withRSA
SHA512withRSA
    Copy to Clipboard Toggle word wrap
    Note

    You can set these algorithm parameters to a value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA’s CS.cfg file. For details, see the B.2.10 Signing Algorithm Constraint annex in the Administration Guide (Common Criteria Edition). Signature algorithm must match key_type.

  6. To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: 

    pki_admin_key_algorithm=SHA256withEC
pki_admin_key_size=nistp256
pki_admin_key_type=ecc
pki_sslserver_key_algorithm=SHA256withEC
pki_sslserver_key_size=nistp256
pki_sslserver_key_type=ecc
pki_subsystem_key_algorithm=SHA256withEC
pki_subsystem_key_size=nistp256
pki_subsystem_key_type=ecc
pki_audit_signing_key_algorithm=SHA256withEC
pki_audit_signing_key_size=nistp256
pki_audit_signing_key_type=ecc
pki_audit_signing_signing_algorithm=SHA256withEC
    Copy to Clipboard Toggle word wrap

    Allowed choices for the key_algorithm parameters are: 

    SHA256withEC
SHA384withEC
SHA512withEC
    Copy to Clipboard Toggle word wrap
    Note

    You can set these algorithm parameters to a value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA’s CS.cfg file. For details, see the For details, see the B.2.10 Signing Algorithm Constraint annex in the Administration Guide (Common Criteria Edition). The signature algorithm must match with key_type.

    For ECC, the allowed choices for key_size are: 

    nistp256
nistp384
nistp521
    Copy to Clipboard Toggle word wrap

    For ECC, the allowed choice for key_type is ecc.

  7. Set the client directory of the bootstrap admin user: 

    pki_client_dir=bootstrap_admin_directory
    Copy to Clipboard Toggle word wrap

    By default, the path is set to ~/.dogtag/instance_name/

    Important

    The pki_admin_* and pki_client_* parameters belong to the bootstrap user that is automatically created by the installation process. For further information about default roles (privileges) and the bootstrap user, see Section 2.6.6, “Users, authorization, and access controls”. For descriptions about the parameters covered in this section, see the pki_default.cfg(5) man page.

  8. Set various passwords for the bootstrap admin user: 

    pki_admin_password=password
pki_client_database_password=password
pki_client_pkcs12_password=password
    Copy to Clipboard Toggle word wrap

  9. Set the parameters for the LDAPS connection to Directory Server running on the same host: 

    pki_ds_database=back-end database name
pki_ds_hostname=hostname
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=path_to_CA_or_self-signed_certificate
pki_ds_password=password
    Copy to Clipboard Toggle word wrap

  10. If you use a self-signed certificate in Directory Server use the following command to export it from the Directory Server’s Network Security Services (NSS) database: 

    # certutil -L -d /etc/dirsrv/slapd-instance_name/ \ -n "server-cert" -a -o /root/ds.crt
    Copy to Clipboard Toggle word wrap

  11. For the CA that will act as a security domain, set the proper parameters: 

    # for a CA that acts as a security domain
pki_security_domain_hostname=
pki_security_domain_name=example.com Security Domain
pki_security_domain_user=caadmin
pki_security_domain_password=SD password
    Copy to Clipboard Toggle word wrap

[Tomcat] section:

  1. Set the Tomcat JServ Protocol (AJP) port: 

    pki_ajp_port=Tomcat_AJP_port
    Copy to Clipboard Toggle word wrap

  2. Set the Tomcat server port: 

    pki_tomcat_server_port=Tomcat_server_port
    Copy to Clipboard Toggle word wrap
Important

To run more than one PKI subsystem instance on the same host, you must set ports in the pki_ajp_port and pki_tomcat_server_port parameters that are not used by any other service on the host. By default, the pki_ajp_port is set to 8009 and pki_tomcat_server_port to 8005.

Subsystem-specific settings

After you have created the initial configuration file, add the subsystem-specific settings to it. Search for subsystem-specific sections ([CA], [OCSP], [KRA], [TKS], or [TPS]) in the /usr/share/pki/server/etc/default.cfg file.

For examples, see:

7.2.2. Installation methods (single-step or two-step)
Copiar o link

You can run pkispawn in either single-step installation or two-step installation:

Single-step installation

In a single-step installation process, you first create a configuration file and then run pkispawn once against this file as follows: 

# pkispawn -s [CA, OCSP, KRA, TKS, TPS] -f cs_inst.cfg –debug
Copy to Clipboard Toggle word wrap
Note

Before starting the installation, it is good practice to first run a precheck using the configuration file:

E.g. for the CA: 

# pkispawn -s CA -f rootca_inst.cfg --precheck --debug
# pkispawn -s CA -f rootca_inst.cfg --debug
Copy to Clipboard Toggle word wrap

For a complete example, see Section 7.3.1, “Installing the RootCA instance (single-step method)”.

Two-step installation

In a two-step installation, administrators are allowed to manually update configuration files between the two parts of the installation. This method allows for better customization.

The two-step installation consists of the following major parts:

First step

During this step, pkispawn copies configuration files from the /usr/share/pki/ directory to the instance-specific /etc/pki/instance_name/ directory. Additionally, pkispawn sets the settings based on values defined in the deployment configuration file. The first step of pkispawn is run as the following: 

# pkispawn -s [CA, OCSP, KRA, TKS, TPS] -f cs_inst.cfg --skip-configuration –debug
Copy to Clipboard Toggle word wrap
Note

Before starting the installation, it is good practice to first run a precheck using the configuration file.

E.g. for the CA: 

# pkispawn -s CA -f rootca_inst.cfg --skip-configuration --precheck --debug
# pkispawn -s CA -f rootca_inst.cfg --skip-configuration --debug
Copy to Clipboard Toggle word wrap

Between step customization

Between running the two pkispawn steps, you have the opportunity to manually update some instance-specific configuration files before the next pkispawn step. Parameters you customize at this point are in general things that you cannot configure in the pkispawn configuration file but would affect the outcome or behavior of the system. Examples for such customization include, but are not limited to:

  • system certificate enrollment profiles under /var/lib/pki/<CA instance name>/ca/conf/*.profile (see Chapter 11, Configuring certificate profiles)

    • e.g. adding a desired certificate extension (which is not in the default profile) to a system certificate by editing the corresponding system certificate profile
    • e.g. Changing the validity period of a system certificate by editing the corresponding system certificate profile

  • ciphers list (see Section 7.13.11, “Update the ciphers list”)

    • e.g. further restricting the supported ciphers
  • etc.

Second step

During this step, pkispawn continues the installation based on the configuration files in the instance-specific /etc/pki/instance_name/ directory. This second step is run as the following: 

# pkispawn -s [CA, OCSP, KRA, TKS, TPS] -f cs_inst.cfg --skip-installation –debug
Copy to Clipboard Toggle word wrap
Note

Before starting the installation, it is good practice to first run a precheck using the configuration file.

E.g. for the CA: 

# pkispawn -s CA -f rootca_inst.cfg --skip-installation --precheck --debug
# pkispawn -s CA -f rootca_inst.cfg --skip-installation --debug
Copy to Clipboard Toggle word wrap

For a complete example, see Section 7.3.2, “Installing the RootCA instance (two-step method)”.

7.2.3. Installation example (introduction)
Copiar o link

To better demonstrate how you can install each type of CS instance, we provide the following installation/configuration procedure example of a RSA setup for the following RSA RHCS subsystems on separate Tomcat instances where an Entrust nShield Connect XC unit is employed with supported firmware/software:

  • non-TMS: root CA (RootCA), OCSP (for the RootCA), subordinate CA (SubCA), OCSP (for the SubCA), KRA (for the SubCA).
  • TMS (if of interest): TKS (for the SubCA), TPS (for the SubCA).
Note

In general, a root CA is not recommended for doing day-to-day certificate issuance. Therefore, an OCSP for the root CA is not required. In our present example, the RootCA’s OCSP is only presented for demonstration purposes.

For an ECC environment, please see the ECC example.

In the following example setup procedures, we will use the pkispawn utility to create the following PKI topology, where the RootCA (having its own OCSP instance) provides the certificate issuance for the SubCA’s CA signing certificate, while the SubCA is the security domain to both its own OCSP and KRA instances, and if TMS is of interest, the TKS and TPS instances:

pkitopology
View larger image
pkitopology
Important

To gain a better picture of the process involved, we advise you to:

  1. Follow Chapter 6, Prerequisites for installation if you have not done it yet.

  2. Follow either the single-step installation or two-step installation example to install

    1. RootCA
    2. OCSP of RootCA (optional)
    3. SubCA
    4. OCSP of SubCA
    5. KRA

  3. (if TMS is of interest - RSA only) continue to follow either the single-step installation or two-step installation example to install

    1. TKS
    2. TPS

7.3. Create and configure the RootCA (Part I)
Copiar o link

To install and configure a RootCA instance, use either one of two pkispawn methods:

7.3.1. Installing the RootCA instance (single-step method)
Copiar o link

Configuring a RootCA instance using the single-step method requires creating a configuration file and running the pkispawn tool once.
In this example, the RootCA is installed on rhcs10.example.com (as well as other instances), with its internal directory server on rhds11.example.com.

Prerequisites

Procedure

  1. Create a CA installation file at a chosen location (e.g. /root/pki_rsa) on the machine that will host the RHCS instance (rhcs10.example.com). 

    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # vi rootca_inst.cfg
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation.

    The values specified in the installation file below are examples. In addition to changing the HSM password, edit the values accordingly, for example ports, directories, nicknames, domains…​ 

    [DEFAULT]
pki_instance_name=rhcs10-RSA-RootCA
pki_https_port=8443
pki_http_port=8080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
### by default, if pki_client_dir, pki_client_database_dir,
### and pki_client_admin_cert_p12 are not specified, items will be placed
### under some default directories in /root/.dogtag
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-RootCA/ca_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-RootCA/certs_db
pki_client_database_password=SECret.123
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-RootCA
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=389
pki_ds_ldaps_port=636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/temp-dirsrv-rootca-cert.pem
pki_ds_secure_connection_ca_nickname=DS temp CA certificate

### Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_name=Example-rhcs10-RSA-RootCA
pki_security_domain_password=SECret.123


[Tomcat]
pki_ajp_port=8009
pki_tomcat_server_port=8005


[CA]
pki_import_admin_cert=False
pki_admin_nickname=PKI Bootstrap Administrator for RSA-RootCA
pki_admin_name=caadmin
pki_admin_uid=caadmin
pki_admin_email=caadmin@example.com

pki_ca_signing_token=NHSM-CONN-XC
pki_ca_signing_key_algorithm=SHA256withRSA
pki_ca_signing_key_size=3072
pki_ca_signing_key_type=rsa
pki_ca_signing_nickname=CA Signing Cert - %(pki_instance_name)s
pki_ca_signing_signing_algorithm=SHA256withRSA

pki_ocsp_signing_token=NHSM-CONN-XC
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=3072
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-RootCA
pki_ds_database=CC-RSA-RootCA-LDAP
pki_share_db=False

### Enable random serial numbers
pki_random_serial_numbers_enable=True
    Copy to Clipboard Toggle word wrap

  2. Run the pkispawn tool to install the RHCS CA instance: 

    # pkispawn -s CA -f rootca_inst.cfg --debug
    Copy to Clipboard Toggle word wrap

Verification steps

  1. Show the status of the installed CA: 

    # pki-server status rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

    Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs.

  2. Verify the sanity of the CA by running the following command. It should display certificates: 

    # pki -p 8443 -h rhcs10.example.com ca-cert-find
    Copy to Clipboard Toggle word wrap
Note

An untrusted issuer warning for the CA signing certificate will display when connecting to the RootCA with a pki command for the first time, as seen below: 

WARNING: UNTRUSTED ISSUER encountered on 'CN=rhcs10.example.com,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA'
Trust this certificate (y/N)?
Copy to Clipboard Toggle word wrap

Select y to trust the CA signing cert if the Subject DN matches the hostname as expected. The warning will not display again.

Note

Once you are done with this section (single-step method), skip directly to Section 7.3.3, “Disable non-CMC and non-installation profiles” to continue with the RootCA installation.

7.3.2. Installing the RootCA instance (two-step method)
Copiar o link

Configuring a RootCA instance using the two-step method requires creating a configuration file and running the pkispawn tool twice.
In this example, the RootCA is installed on rhcs10.example.com.

Prerequisites

First step of RootCA installation

  1. Create a CA installation file at a chosen location (e.g. /root/pki_rsa) on the machine that will host the RHCS instance (rhcs10.example.com). 

    # cd /root/pki_rsa

# vi rootca_inst.cfg
    Copy to Clipboard Toggle word wrap 
    [DEFAULT]
pki_instance_name=rhcs10-RSA-RootCA
pki_https_port=8443
pki_http_port=8080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
### by default, if pki_client_dir, pki_client_database_dir,
### and pki_client_admin_cert_p12 are not specified, items will be placed
### under some default directories in /root/.dogtag
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-RootCA
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-RootCA/ca_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-RootCA/certs_db
pki_client_database_password=SECret.123
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=389
pki_ds_ldaps_port=636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/temp-dirsrv-rootca-cert.pem
pki_ds_secure_connection_ca_nickname=DS temp CA certificate

### Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_name=Example-rhcs10-RSA-RootCA
pki_security_domain_password=SECret.123


[Tomcat]
pki_ajp_port=8009
pki_tomcat_server_port=8005


[CA]
pki_import_admin_cert=False
pki_admin_nickname=PKI Bootstrap Administrator for RSA-RootCA
pki_admin_name=caadmin
pki_admin_uid=caadmin
pki_admin_email=caadmin@example.com

pki_ca_signing_token=NHSM-CONN-XC
pki_ca_signing_key_algorithm=SHA256withRSA
pki_ca_signing_key_size=3072
pki_ca_signing_key_type=rsa
pki_ca_signing_nickname=CA Signing Cert - %(pki_instance_name)s
pki_ca_signing_signing_algorithm=SHA256withRSA

pki_ocsp_signing_token=NHSM-CONN-XC
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=3072
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-RootCA
pki_ds_database=CC-RSA-RootCA-LDAP
pki_share_db=False

### Enable random serial numbers
pki_random_serial_numbers_enable=True
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation. However, in a two-step installation, the pki_instance_name value of both files should match. The following values are just examples.

  2. Run the pkispawn tool to install the RHCS CA instance: 

    # pkispawn -s CA -f rootca_inst.cfg --skip-configuration --debug
    Copy to Clipboard Toggle word wrap

Between-step configuration

As explained in Between step customization, you can customize certain things, such as the certificate profile of a system certificate.

  • Setting the Subject Key Identifier extension message digest algorithm for the CA signing certificate:

    1. Open the enrollment profile for this CA’s signing certificate: 

      # vi /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/caCert.profile
      Copy to Clipboard Toggle word wrap

    2. Add the following parameter: 

      7.default.params.messageDigest=SHA-256
      Copy to Clipboard Toggle word wrap
    3. Save the file.

    Likewise, do the same for the CA signing cert that this CA will be issuing in the future:

    1. Open the enrollment profile for the CA signing certificate: 

      # vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caInstallCACert.cfg
      Copy to Clipboard Toggle word wrap 
      # vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCcaCert.cfg
      Copy to Clipboard Toggle word wrap

    2. Add the following parameter: 

      policyset.caCertSet.8.default.params.messageDigest=SHA-256
      Copy to Clipboard Toggle word wrap
    3. Save the file.

  • Other between-step configuration changes can take place here too. For example, if you wish to extend the validity period of the audit signing certificate of this subsystem:

    1. Open the corresponding configuration file: 

      # vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caInternalAuthAuditSigningCert.cfg
      Copy to Clipboard Toggle word wrap

    2. Change the following range parameters to the desired values: 

      policyset.auditSigningCertSet.2.constraint.params.range=720
policyset.auditSigningCertSet.2.default.params.range=720
      Copy to Clipboard Toggle word wrap
    3. Save the file. Once you have done the second step of pkispawn in the next section, you should expect the validity of the audit signing certificate of this subsystem to match the values you have changed to.

Second step of RootCA installation

The second step of pkispawn in this case involves running the tool against the same file in a different manner to configure the RHCS CA instance.

  • Run the pkispawn tool to configure the CA: 

    # pkispawn -s CA -f rootca_inst.cfg --skip-installation --debug
    Copy to Clipboard Toggle word wrap

Verification steps

  1. Show the status of the installed CA: 

    # pki-server status rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

    Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs.

  2. Verify the sanity of the CA by running the following command. It should display certificates: 

    # pki -p 8443 -h rhcs10.example.com ca-cert-find
    Copy to Clipboard Toggle word wrap
Note

An untrusted issuer warning for the CA signing certificate will display when connecting to the RootCA with a pki command for the first time, as seen below: 

WARNING: UNTRUSTED ISSUER encountered on 'CN=rhcs10.example.com,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA'
Trust this certificate (y/N)?
Copy to Clipboard Toggle word wrap

Select y to trust the CA signing cert if the Subject DN matches the hostname as expected. The warning will not display again.

7.3.3. Disable non-CMC and non-installation profiles
Copiar o link

The profiles are stored in /var/lib/pki_rsa/rhcs10-RSA-RootCA/ca/profiles/ca/. CMC profiles contain "CMC" in their profile ID. This section provides procedures to disable non-CMC and non-installation profiles.

Procedure

  1. Generate a list of non-CMC profiles to be edited: 

    # ls /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca | grep -v CMC | grep -v Install | grep -v caInternal | grep -v caECInternal | grep -v caAdminCert | grep -v caECAdminCert | tee /root/pki_rsa/ca-profile-deletelist.txt
    Copy to Clipboard Toggle word wrap

  2. Stop the RootCA instance: 

    pki-server stop rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

  3. For every profile in the list, change the visible and enable parameters from true to false. For example, use the following command to set visible=false and enable=false: 

    # cat /root/pki_rsa/ca-profile-deletelist.txt | while read line; do sed -i 's/^visible=true/visible=false/g' /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/$line; sed -i 's/^enable=true/enable=false/g' /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/$line; done
    Copy to Clipboard Toggle word wrap

  4. In addition, also change the visible parameter for the caCMCUserCert profile to false: 

    # sed -i 's/^visible=true/visible=false/' /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCUserCert.cfg
    Copy to Clipboard Toggle word wrap

  5. Start the RootCA instance: 

    pki-server start rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

7.3.4. Create a CA chain file
Copiar o link

In later procedures, you will need the CA certificates and CA chain. It is important to keep the certificate chain file up to date. We are placing the CA chain file, ca-chain.pem, as well as the individual CA .pem files under the /opt/pki_rsa directory on both rhcs10.example.com (the machine hosting the CS instances), and rhds11.example.com (the machine hosting the DS instances).

  1. Create a CA chain file for later use: 

    # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias -n "CA Signing Cert - rhcs10-RSA-RootCA" -a > /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # cp /opt/pki_rsa/rootCA.pem /opt/pki_rsa/ca-chain.pem
    Copy to Clipboard Toggle word wrap

  2. Copy the files to rhds11.example.com (the machine that hosts the DS instances): 

    # scp /opt/pki_rsa/rootCA.pem root@rhds11.example.com:/opt/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # scp /opt/pki_rsa/ca-chain.pem root@rhds11.example.com:/opt/pki_rsa
    Copy to Clipboard Toggle word wrap

  3. On rhds11.example.com, edit the /etc/openldap/ldap.conf file so that TLS_CACERT points to the CA chain file we just created: 

    # echo "TLS_CACERT /opt/pki_rsa/ca-chain.pem" >> /etc/openldap/ldap.conf
    Copy to Clipboard Toggle word wrap

  4. Restart the DS instance for the RootCA: 

    # dsctl slapd-CC-RSA-RootCA-LDAP restart
    Copy to Clipboard Toggle word wrap

7.3.5. Prepare the RootCA to sign other CMC certificate requests
Copiar o link

The procedure in this section aims to create an nssdb containing the RootCA’s bootstrap admin certificate/key, thus allowing the pki administrators to sign CMC full requests for role user certificates at later steps.

Note

Previously, in the pkispawn configuration file, we specified the following parameters: 

pki_client_dir=/opt/pki_rsa/rhcs10-RSA-RootCA
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-RootCA/ca_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-RootCA/certs_db
Copy to Clipboard Toggle word wrap

These parameters tell pkispawn where to place the bootstrap admin certificate and keys, therefore, in theory, you would not need to follow the steps in this section. However, since we would like to demonstrate a working example to the readers, for ease of execution and description, we are designating /root/.dogtag/pki_rsa_bootstrap/certs_db to be the location of the nssdb that contains all the bootstrap admin user’s certificates and keys throughout this example.

Prerequisite

  • You are logged in to rhcs10.example.com as root user.

Procedure

  1. Create a client nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-init
    Copy to Clipboard Toggle word wrap
    NOTE

    The directory specified at -d should not already exist. If it does exist, another RHCS instance might be using it. In that case, it’s advised to move it out of the way or specify a different path. You can check if there are any certificates with: 

    # certutil -L -d /root/.dogtag/pki_rsa_bootstrap/certs_db
    Copy to Clipboard Toggle word wrap

    and if none exist, you can select Yes to overwrite.

  2. Import the CA signing certificate into the nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-RootCA" --ca-cert /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap

  3. Import the RootCA bootstrap admin certificate/key into the nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-import --pkcs12 /opt/pki_rsa/rhcs10-RSA-RootCA/ca_admin_cert.p12 --pkcs12-password SECret.123

----------------------------------------
Imported certificates from PKCS #12 file
----------------------------------------
    Copy to Clipboard Toggle word wrap

Verification:

  1. List the certificates: 

    # certutil -d /root/.dogtag/pki_rsa_bootstrap/certs_db -L

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI

PKI Bootstrap Administrator for RSA-RootCA      u,u,u
CA Signing Cert - rhcs10-RSA-RootCA             CT,C,C
    Copy to Clipboard Toggle word wrap

  2. As the bootstrap admin user, list the users in the RootCA: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 8443 -n "PKI Bootstrap Administrator for RSA-RootCA" ca-user-find
    Copy to Clipboard Toggle word wrap 
    -----------------
3 entries matched
-----------------
  User ID:  CA-rhcs10.example.com-8443
  Full name:  CA-rhcs10.example.com-8443

  User ID: caadmin
  Full name: caadmin

  User ID: pkidbuser
  Full name: pkidbuser
----------------------------
Number of entries returned 3
    Copy to Clipboard Toggle word wrap

7.3.6. Check for random serial numbers
Copiar o link

  • List the certificates to make sure all the subsystem certificates have random serial numbers. 

    # pki -p 8443 ca-cert-find | grep -i serial
    Copy to Clipboard Toggle word wrap

7.3.7. Verify that the RootCA signing certificate has no AIA
Copiar o link

It is important to note that since this is a self-signed (root) CA signing certificate, it should not contain an AIA (Authority Information Access) extension.

  • To verify that the RootCA signing certificate is issued correctly: 

    # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA"
    Copy to Clipboard Toggle word wrap

    You should observe that there is no AIA extension.

Note

To allow for the RootCA role user certificates to contain AIA extensions pointing to the OCSP instance (yet to be created in the following section), relevant sections are placed in Section 7.5, “Create and configure the RootCA (Part II)”, AFTER the OCSP instance creation.

7.3.8. Configure support for CRL Distribution Point
Copiar o link

Note

For more information on CRL Distribution Points, why they are needed and where they are best suited, see Section 9.4.1.2, “Enabling automatic revocation checking on the CA”.

To configure support for CRL Distribution Points, as an example, we describe how to set up a file-based CRL publisher as well as the partitioning of the CRL. You will also learn how to enable a certificate enrollment profile to issue certificates with the CRL Distribution Point extension. Finally, we describe how to replace the temporary Server-Cert of the CA’s LDAP server with a certificate issued from the CRL Distribution Point profiles.

Before proceeding with the following changes, stop the RootCA instance: 

# pki-server stop rhcs10-RSA-RootCA
Copy to Clipboard Toggle word wrap

7.3.8.1. CA Setup to support Server Cert CRL File Publishing
Copiar o link

Note

Before proceeding, save a copy of the configuration file before editing: 

# cp /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg  /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg.bak.<date>
Copy to Clipboard Toggle word wrap
7.3.8.1.1. Set up the file-based publisher: crlFilePublisher
Copiar o link

The configuration in this section creates a file-based CRL publisher called crlFilePublisher. When set up correctly, the CRL is stored under directory /var/lib/pki/rhcs10-RSA-RootCA/crl in DER format.

  1. Create the CRL directory for publishing the file-based partitioned CRL: 

    # mkdir /var/lib/pki/rhcs10-RSA-RootCA/crl
# chown pkiuser.pkiuser /var/lib/pki/rhcs10-RSA-RootCA/crl
    Copy to Clipboard Toggle word wrap

  2. Add the following to the CA’s CS.cfg: 

    ca.publish.publisher.instance.crlFilePublisher.Filename.b64=false
ca.publish.publisher.instance.crlFilePublisher.Filename.der=true
ca.publish.publisher.instance.crlFilePublisher.crlLinkExt=crl
ca.publish.publisher.instance.crlFilePublisher.directory=/var/lib/pki/rhcs10-RSA-RootCA/crl
ca.publish.publisher.instance.crlFilePublisher.latestCrlLink=true
ca.publish.publisher.instance.crlFilePublisher.maxAge=0
ca.publish.publisher.instance.crlFilePublisher.maxFullCRLs=0
ca.publish.publisher.instance.crlFilePublisher.pluginName=FileBasedPublisher
ca.publish.publisher.instance.crlFilePublisher.timeStamp=LocalTime
ca.publish.publisher.instance.crlFilePublisher.zipCRLs=false
ca.publish.publisher.instance.crlFilePublisher.zipLevel=9
    Copy to Clipboard Toggle word wrap
7.3.8.1.2. Set up the file-based publishing rule: FileCrlRule
Copiar o link

The configuration in this section creates a file-based publishing rule called FileCrlRule. The predicate specifies the issuing point to a partitioned CRL called ServerCertCRL (defined in Section 7.3.8.1.4, “Set up the CRL-partitioning for certificates issued via a profile”).

  • Add the following to the CA’s CS.cfg: 

    ca.publish.rule.instance.FileCrlRule.enable=true
ca.publish.rule.instance.FileCrlRule.mapper=NoMap
ca.publish.rule.instance.FileCrlRule.pluginName=Rule
ca.publish.rule.instance.FileCrlRule.predicate=issuingPointId==ServerCertCRL
ca.publish.rule.instance.FileCrlRule.publisher=crlFilePublisher
ca.publish.rule.instance.FileCrlRule.type=crl
    Copy to Clipboard Toggle word wrap
7.3.8.1.3. Modify the LDAP-based publishing rule: LdapCrlRule
Copiar o link

This configuration explicitly sets the LdapCrlRule predicate to the master (full) CRL. The master CRL is continuously supplied to the OCSP responder for proper OCSP support.

  • Modify the following in the CA’s CS.cfg: 

    ca.publish.rule.instance.LdapCrlRule.predicate=issuingPointId==MasterCRL
    Copy to Clipboard Toggle word wrap
7.3.8.1.4. Set up the CRL-partitioning for certificates issued via a profile
Copiar o link

The configuration in this section demonstrates how to partition a CRL to a smaller subset that could be utilized in the FileCrlRule defined above. The CRL is partitioned by the certificate enrollment profile(s) specified in the profileList parameter. A comma-separated list can be used for multiple profiles (for example, caCMCserverCertWithCRLDP.cfg and caCMCECserverCertWithCRLDP.cfg).

  • Add the following to the CA’s CS.cfg: 

    ca.crl.ServerCertCRL.allowExtensions=true
ca.crl.ServerCertCRL.alwaysUpdate=false
ca.crl.ServerCertCRL.autoUpdateInterval=240
ca.crl.ServerCertCRL.caCertsOnly=false
ca.crl.ServerCertCRL.cacheUpdateInterval=15
ca.crl.ServerCertCRL.class=com.netscape.ca.CRLIssuingPoint
ca.crl.ServerCertCRL.dailyUpdates=1:00
ca.crl.ServerCertCRL.description=CA's Certificate Revocation List containing certificates issued via the caCMCserverCertWithCRLDP and caCMCECserverCertWithCRLDP enrollment profile
ca.crl.ServerCertCRL.enable=true
ca.crl.ServerCertCRL.enableCRLCache=false
ca.crl.ServerCertCRL.enableCRLUpdates=true
ca.crl.ServerCertCRL.enableCacheRecovery=true
ca.crl.ServerCertCRL.enableCacheTesting=false
ca.crl.ServerCertCRL.enableDailyUpdates=true
ca.crl.ServerCertCRL.enableUpdateInterval=true
ca.crl.ServerCertCRL.extendedNextUpdate=true
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessLocation0=""
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessLocationType0=URI
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessMethod0=caIssuers
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.class=com.netscape.cms.crl.CMSAuthInfoAccessExtension
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.critical=false
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.enable=false
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.numberOfAccessDescriptions=1
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.type=CRLExtension
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.class=com.netscape.cms.crl.CMSAuthorityKeyIdentifierExtension
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.critical=false
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.enable=false
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.type=CRLExtension
ca.crl.ServerCertCRL.extension.CRLNumber.class=com.netscape.cms.crl.CMSCRLNumberExtension
ca.crl.ServerCertCRL.extension.CRLNumber.critical=false
ca.crl.ServerCertCRL.extension.CRLNumber.enable=true
ca.crl.ServerCertCRL.extension.CRLNumber.type=CRLExtension
ca.crl.ServerCertCRL.extension.CRLReason.class=com.netscape.cms.crl.CMSCRLReasonExtension
ca.crl.ServerCertCRL.extension.CRLReason.critical=false
ca.crl.ServerCertCRL.extension.CRLReason.enable=true
ca.crl.ServerCertCRL.extension.CRLReason.type=CRLEntryExtension
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.class=com.netscape.cms.crl.CMSDeltaCRLIndicatorExtension
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.critical=true
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.enable=false
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.type=CRLExtension
ca.crl.ServerCertCRL.extension.FreshestCRL.class=com.netscape.cms.crl.CMSFreshestCRLExtension
ca.crl.ServerCertCRL.extension.FreshestCRL.critical=false
ca.crl.ServerCertCRL.extension.FreshestCRL.enable=false
ca.crl.ServerCertCRL.extension.FreshestCRL.numPoints=0
ca.crl.ServerCertCRL.extension.FreshestCRL.pointName0=""
ca.crl.ServerCertCRL.extension.FreshestCRL.pointType0=""
ca.crl.ServerCertCRL.extension.FreshestCRL.type=CRLExtension
ca.crl.ServerCertCRL.extension.InvalidityDate.class=com.netscape.cms.crl.CMSInvalidityDateExtension
ca.crl.ServerCertCRL.extension.InvalidityDate.critical=false
ca.crl.ServerCertCRL.extension.InvalidityDate.enable=true
ca.crl.ServerCertCRL.extension.InvalidityDate.type=CRLEntryExtension
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.class=com.netscape.cms.crl.CMSIssuerAlternativeNameExtension
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.critical=false
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.enable=false
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.name0=""
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.nameType0=""
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.numNames=0
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.type=CRLExtension
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.class=com.netscape.cms.crl.CMSIssuingDistributionPointExtension
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.critical=true
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.enable=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.indirectCRL=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlyContainsCACerts=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlyContainsUserCerts=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlySomeReasons=""
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.pointName=
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.pointType=
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.type=CRLExtension
ca.crl.ServerCertCRL.includeExpiredCerts=false
ca.crl.ServerCertCRL.includeExpiredCertsOneExtraTime=false
ca.crl.ServerCertCRL.minUpdateInterval=0
ca.crl.ServerCertCRL.nextAsThisUpdateExtension=0
ca.crl.ServerCertCRL.nextUpdateGracePeriod=0
ca.crl.ServerCertCRL.profileCertsOnly=true
ca.crl.ServerCertCRL.profileList=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP
ca.crl.ServerCertCRL.publishOnStart=false
ca.crl.ServerCertCRL.saveMemory=false
ca.crl.ServerCertCRL.signingAlgorithm=SHA256withRSA
ca.crl.ServerCertCRL.updateSchema=1
    Copy to Clipboard Toggle word wrap
Note

For an ECC CA, set the following to SHA512withEC: 

ca.crl.ServerCertCRL.signingAlgorithm=SHA512withEC
Copy to Clipboard Toggle word wrap

7.3.8.2. Set up CRL HTTP service in the CA
Copiar o link

The CRL served by the CRL Distribution Point is published to a file (see sections above). This file is served by a non-SSL Tomcat service that we are adding to the CA’s server.xml as shown below:

  1. Add the following CRL service before the Catalina service in the file /var/lib/pki/rhcs10-RSA-RootCA/conf/server.xml: 

    <Service name="CRL">
  <Connector port="8085" protocol="HTTP/1.1" connectionTimeout="80000"
   maxParameterCount="1000" name="Unsecure" maxHttpHeaderSize="8192"
   acceptCount="100" maxThreads="15" minSpareThreads="25"
   enableLookups="false" disableUploadTimeout="true"/>
  <Engine name="CRL" defaultHost="localhost">
    <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
      <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
       prefix="localhost_crl_access_log" suffix=".txt" pattern="common"/>
    </Host>
  </Engine>
</Service>
    Copy to Clipboard Toggle word wrap

  2. In the above CRL service, choose a connector port number that has not been used. For example, if the root CA’s HTTP port is 8080, then pick 8085. Ensure that the port is added for SELinux and firewall, for example: 

    # semanage port -a -t http_port_t -p tcp 8085
# firewall-cmd --permanent --add-port=8085/tcp
# firewall-cmd --reload
    Copy to Clipboard Toggle word wrap
    Note

    If your selected port has been pre-assigned with another SELinux context, you will see an error message that looks like the following: 

    ValueError: Port tcp/8085 already defined
    Copy to Clipboard Toggle word wrap

    You can also search and find out whether the CRL HTTP port is pre-assigned by using the following command: 

    # semanage port -l | grep <port>
    Copy to Clipboard Toggle word wrap

    We recommend that you select another port. However, if you wish to use the same port, you could do the following: 

    # semanage port -m -t http_port_t -p tcp 8085
    Copy to Clipboard Toggle word wrap

  3. When the server is restarted, the directory CRL/localhost is created under the CA’s conf directory if it does not exist. However, to prepare for the addition of the crl.xml file, do the following: 

    # mkdir -p  /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost
# chown -R pkiuser:pkiuser /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost
    Copy to Clipboard Toggle word wrap

  4. Create a crl.xml file under /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost, and add the following content: 

    <Context docBase="/var/lib/pki/rhcs10-RSA-RootCA/crl">
 <Resources allowLinking="true" cachingAllowed="false" />
</Context>
    Copy to Clipboard Toggle word wrap

  5. Set the user:group ownership for the crl.xml file: 

    chown pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost/crl.xml
    Copy to Clipboard Toggle word wrap
Note

The CRL Distribution Point set in the enrollment profile looks like this (see next section for full example): http://rhcs10.example.com:8085/crl/ServerCertCRL.crl

Important

File-based CRL publisher is only recommended for smaller CRLs with less frequently issued or revoked certificates. It is only recommended if necessary, such as in the case of CA startup setup described in this section.

7.3.8.3. CA’s enrollment profile configuration with CRL Distribution Points
Copiar o link

Enable the desired profile(s) to include the CRL Distribution Points. These are the profiles corresponding to the configuration in the sections above.

  1. Open the caCMCserverCertWithCRLDP.cfg profile (for enrollments with RSA keys) in the /var/lib/pki/<ca instance directory/ca/profiles/ca/ directory and update as follows: 

    # vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:8085/crl/ServerCertCRL.crl
…
    Copy to Clipboard Toggle word wrap

  2. Open the caCMCECserverCertWithCRLDP.cfg (for enrollments with ECC keys) in the /var/lib/pki/<ca instance directory/ca/profiles/ca/ directory and update as follows: 

    # vi /var/lib/pki/rhcs10-ECC-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:20085/crl/ServerCertCRL.crl
…
    Copy to Clipboard Toggle word wrap

  3. Set user:group ownership: 

    # chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
# chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
    Copy to Clipboard Toggle word wrap

  4. Register a new profile in the CA’s CS.cfg:

    1. Add the following lines for each profile: 

      profile.caCMCserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg

profile.caCMCECserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCECserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
      Copy to Clipboard Toggle word wrap

    2. Edit the profile.list entry to add the two new profiles. For example:: 

      profile.list=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP,acmeServerCert,caCMCserverCert,caCMCECserverCert, …
      Copy to Clipboard Toggle word wrap

7.3.8.4. Set up for more immediate CRL update
Copiar o link

Since server certs do not often get revoked, it is reasonable to update the CRL as soon as there is a revocation. Edit the CA’s CS.cfg: 

ca.crl.ServerCertCRL.alwaysUpdate=true
Copy to Clipboard Toggle word wrap

7.3.8.5. Start up the CA once the CA’s configuration is updated
Copiar o link

Once configuration is complete, start up the CA: 

# pki-server start rhcs10-RSA-RootCA
Copy to Clipboard Toggle word wrap
Note

You will be instructed to verify the CRL Distribution Point setup at the end of Section 7.5.1, “Replace the temporary DS certificate (RootCA)” once the CA’s Directory Server Server-Cert has been replaced correctly.

7.4. Create and configure the OCSP instance (RootCA)
Copiar o link

This section describes installing and configuring an OCSP instance against the RootCA.
The OCSP system certificates will be issued by the RootCA, and the OCSP will join the RootCA security domain.
In this example, the RootCA’s OCSP is installed on rhcs10.example.com, with its internal directory server on rhds11.example.com.

Note

This is optional. In general, a root CA is not recommended for doing day-to-day certificate issuance. Therefore, an OCSP for the root CA is not required. In our present example, the RootCA’s OCSP is only presented for demonstration purposes.

Note

Make sure that the file /opt/pki_rsa/ca-chain.pem contains the complete CA certificate chain (at this point, only the RootCA certificates): 

# ls -l /opt/pki_rsa/ca-chain.pem

# cat /opt/pki_rsa/ca-chain.pem
Copy to Clipboard Toggle word wrap

7.4.1. Replace the temporary DS certificate (OCSP-rootca)
Copiar o link

Prior to installing the OCSP for the RootCA, we are issuing an official SSL server certificate for the OCSP’s Directory Server to replace the temporary bootstrap one. To do that, we first create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-OCSP-rootca-LDAP stop
    Copy to Clipboard Toggle word wrap
    Note

    If you are not certain about the name of a DS instance, list all instances using: dsctl -l.

  2. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/Server-Cert-ocsp-rootca.csr -z /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-ocsp-rootca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/Server-Cert-ocsp-rootca.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

  3. Remote copy the Server-Cert-ocsp-rootca.csr file to the system where the CA resides. For example: 

    # scp /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/Server-Cert-ocsp-rootca.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-rootca.csr
    Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-rootca.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-RootCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-RootCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-ocsp-rootca.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-RootCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-ocsp-rootca.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response:

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.resp -v

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:

  Certificate:
      Data:
          Version:  v3
          Serial Number: 0xA383694
          Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
          Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-OCSP-rootca,O=Example-rhcs10-RSA-OCSP-rootca
          Validity:
              Not Before: Tuesday, April 5, 2022 8:41:36 AM EDT America/New_York
              Not  After: Monday, March 25, 2024 8:41:36 AM EDT America/New_York
          Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x5C8FAD4
            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: Tuesday, April 5, 2022 8:36:21 AM EDT America/New_York
                Not  After: Saturday, April 5, 2042 8:36:21 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x80296C3
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-OCSP-rootca
            Validity:
                Not Before: Tuesday, April 5, 2022 8:39:43 AM EDT America/New_York
                Not  After: Friday, April 5, 2041 8:39:43 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-OCSP-rootca,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-rootca.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-ocsp-rootca.pem is the new Server-Cert certificate of the Directory Server instance that serves as the internaldb of the OCSP for the RootCA.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-rootca.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-OCSP-rootca-LDAP/
    Copy to Clipboard Toggle word wrap

  2. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  3. Import the newly created DS certificate and its CA certificate in chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/Server-Cert-ocsp-rootca.pem
    Copy to Clipboard Toggle word wrap

  4. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/

Certificate Nickname                           Trust Attributes
                                               SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA            CT,C,C
Server-Cert                                    u,u,u
    Copy to Clipboard Toggle word wrap

  5. Start DS: 

    # dsctl slapd-CC-RSA-OCSP-rootca-LDAP start
    Copy to Clipboard Toggle word wrap

  6. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:6636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:6636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

7.4.2. Install the OCSP instance for the RootCA
Copiar o link

To install the OCSP instance for the RootCA, use either the single-step method or the two-step method. The following procedure describes the single-step method. If you wish to install using the two-step method, please refer to Section 7.2.2, “Installation methods (single-step or two-step)” as well as Section 7.3.2, “Installing the RootCA instance (two-step method)”.

Prerequisites

Procedure

  1. Create an OCSP installation file at a chosen location (e.g. /root/pki_rsa) for generating certificate requests: 

    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # vi ocsp_rootca_inst.cfg
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation.

    The values specified in the installation file below are examples. In addition to changing the HSM password, edit the values accordingly, for example ports, directories, nicknames, domains…​ 

    [DEFAULT]
pki_instance_name=rhcs10-RSA-OCSP-rootca
pki_https_port=33443
pki_http_port=33080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### CA cert chain concatenated in PEM format
pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-OCSP-rootca/ocsp_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-OCSP-rootca/certs_db
pki_client_database_password=SECret.123
pki_client_database_purge=False
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-OCSP-rootca
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=6389
pki_ds_ldaps_port=6636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/ca-chain.pem
pki_ds_secure_connection_ca_nickname=CA Signing Cert - rhcs10-RSA-RootCA

### Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_https_port=8443
pki_security_domain_password=SECret.123
pki_security_domain_user=caadmin


[Tomcat]
pki_ajp_port=33009
pki_tomcat_server_port=33005

[OCSP]
pki_import_admin_cert=False

pki_ocsp_signing_token=NHSM-CONN-XC
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=3072
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA

pki_admin_nickname=PKI Bootstrap Administrator for RSA-OCSP-rootca
pki_admin_name=ocspadmin
pki_admin_uid=ocspadmin
pki_admin_email=ocspadmin@example.com

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-OCSP-rootca
pki_ds_database=CC-RSA-OCSP-rootca-LDAP
pki_share_db=False
    Copy to Clipboard Toggle word wrap

  2. Run the pkispawn tool to install the OCSP subsystem: 

    # pkispawn -s OCSP -f ocsp_rootca_inst.cfg --debug
    Copy to Clipboard Toggle word wrap

    This will create the OCSP instance in /var/lib/pki/rhcs10-RSA-OCSP-rootca.

Note

For ease of reference, if you wanted to install this OCSP using the two-step method:

  1. First run the pkispawn tool with the --skip-configuration option to install the RootCA’s OCSP instance: 

    # pkispawn -s OCSP -f ocsp_rootca_inst.cfg --skip-configuration --debug
    Copy to Clipboard Toggle word wrap
  2. Customize the configuration files between the two installation steps

  3. Run the pkispawn tool to configure the OCSP: 

    # pkispawn -s OCSP -f ocsp_rootca_inst.cfg --skip-installation --debug
    Copy to Clipboard Toggle word wrap

Verification

  • Show the status of the installed OCSP instance: 

    # pki-server status rhcs10-RSA-OCSP-rootca
    Copy to Clipboard Toggle word wrap

7.4.3. Increase the RootCA’s OCSP pkiconsole timeout
Copiar o link

  1. Log in to rhcs10.example.com as root.

  2. Stop the RootCA’s OCSP service: 

    pki-server stop rhcs10-RSA-OCSP-rootca
    Copy to Clipboard Toggle word wrap

  3. Edit /var/lib/pki/rhcs10-RSA-OCSP-rootca/conf/server.xml to increase the timeout period: 

    <Connector name="Secure" port="33443" …
connectionTimeout="3000000"
    Copy to Clipboard Toggle word wrap

  4. Start the RootCA’s OCSP service: 

    # pki-server start rhcs10-RSA-OCSP-rootca
    Copy to Clipboard Toggle word wrap

7.4.4. Set the default AIA extension to point to this OCSP
Copiar o link

By default, unless explicitly specified, the CA issues certificates with an AIA (Authority Information Access) extension pointing to the CA’s own internal OCSP. Now that you have set up an OCSP instance, you can configure the RootCA to start issuing certificates with an AIA extension that points to the OCSP instance instead.

On rhcs10.example.com as root:

  1. Stop the RootCA: 

    # pki-server stop rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

  2. Edit the RootCA’s CS.cfg and set the ca.defaultOcspUri variable to point to the OCSP. For example: 

    ca.defaultOcspUri=http://rhcs10.example.com:33080/ocsp/ee/ocsp
    Copy to Clipboard Toggle word wrap

  3. Start the RootCA: 

    # pki-server start rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap
Note

The OCSP URL of each subsystem (e.g. KRA) is set in its server.xml file by default. When enabled, this directs the RHCS instance to use the static URL when looking up a certificate status, instead of the AIA extension embedded in the peer certificate. To use the AIA extension, you will be directed to follow Section 7.13.10.2, “Enabling OCSP for the CA / KRA / TKS / TPS” when installing the subsystem.

7.4.5. Create OCSP role users
Copiar o link

  • Follow the steps in Section 7.12, “Create PKI role users” to create single-role admin, agent, audit users in OCSP. In order to do so, you will need to import the RootCA’s OCSP bootstrap administrator certificate, ocsp_admin_cert.p12. E.g.: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-import --pkcs12 /opt/pki_rsa/rhcs10-RSA-OCSP-rootca/ocsp_admin_cert.p12 --pkcs12-password SECret.123

----------------------------------------
Imported certificates from PKCS #12 file
----------------------------------------
    Copy to Clipboard Toggle word wrap

7.4.6. Login to the OCSP pkiconsole with client authentication
Copiar o link

  1. Configure OCSP with authType=sslclientauth and import the role user certificate by following Section 7.13.6, “Configure pkiconsole login with client authentication”.

  2. Login to pkiconsole with the client authentication certificate of the role user: 

    # pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:33443/ocsp
    Copy to Clipboard Toggle word wrap

    And select the role user certificate nickname from the list, for example OCSP adminV. Login to the console should be successful.

7.4.7. Configuration for CRL publishing
Copiar o link

Red Hat Certificate System offers two methods of CRL publishing to be consumed by an OCSP instance external to the CA:

  • Direct CA→OCSP CRL publishing
  • Indirect publishing with CA→LDAP, then OCSP←LDAP

By default, once you set up an OCSP instance, the first CRL publishing method is automatically set up as well, which allows direct CA→OCSP CRL publishing.

This section details the second method, which is to have the CA publish its CRLs to an LDAP server, and the OCSP can then pull the CRLs from the LDAP server.

7.4.7.1. Setting up the LDAP server for CRL publishing
Copiar o link

On rhds11.example.com as root:

  1. Install a Directory Server instance, which the CA will use to publish the CRL. Red Hat Directory Server is listening over the LDAP/LDAPS ports, 12389 and 12636 respectively.

    1. Use the dscreate create-template command to create a template .cfg file at a chosen location (e.g. /root/pki_rsa): 

      # dscreate create-template /root/pki_rsa/rootca-crl-publish-ldap.cfg
      Copy to Clipboard Toggle word wrap

    2. Edit the .cfg file created in the previous step. Uncomment the below parameters and set them to customize the installation: 

      full_machine_name = rhds11.example.com
port = 12389
secure_port = 12636
instance_name = CC-RSA-RootCA-CRL-PUBLISH
root_password = SECret.123
suffix = dc=example,dc=com
create_suffix_entry = True
      Copy to Clipboard Toggle word wrap

    3. Install the Directory Server instance: 

      # dscreate from-file /root/pki_rsa/rootca-crl-publish-ldap.cfg

Starting installation...

Completed installation for CC-RSA-RootCA-CRL-PUBLISH
      Copy to Clipboard Toggle word wrap

  2. Add an ACI (Access Control Instruction) rule to allow anonymous bind access. By default, this is disabled.

    1. Create the ldapaci.ldif file at a chosen location (e.g. /root/pki_rsa/dirsrv/) with the following content: 

      dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
      Copy to Clipboard Toggle word wrap

    2. Run the ldapmodify command to add the ACI: 

      # ldapmodify -x -h rhds11.example.com -p 12389 -D 'cn=Directory Manager' -W -f /root/pki_rsa/dirsrv/ldapaci.ldif
      Copy to Clipboard Toggle word wrap

  3. Prepare the CRL publishing subtree:

    1. Create two files in the /root/pki_rsa/dirsrv directory with the following content:

      • For the rootca_pki_subtree.ldif file: 

        dn: dc=pki,dc=example,dc=com
objectClass: domain
dc: pki
        Copy to Clipboard Toggle word wrap

      • For the rootca_crl_subtree.ldif file: 

        dn: dc=crl,dc=pki,dc=example,dc=com
objectClass: domain
dc: crl
        Copy to Clipboard Toggle word wrap

    2. Add both entries to the CRL instance: 

      # ldapadd -x -H ldap://rhds11.example.com:12389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/rootca_pki_subtree.ldif
      Copy to Clipboard Toggle word wrap 
      # ldapadd -x -H ldap://rhds11.example.com:12389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/rootca_crl_subtree.ldif
      Copy to Clipboard Toggle word wrap

7.4.7.2. Configuring CRL publishing on the RootCA
Copiar o link

To configure CRL publishing:

  1. Add the ca.publish. properties:

    1. Stop the RootCA instance: 

      # pki-server stop rhcs10-RSA-RootCA
      Copy to Clipboard Toggle word wrap

    2. Configure the following properties in the RootCA’s CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg): 

      ca.publish.ldappublish.enable=true
ca.publish.ldappublish.ldap.ldapauth.authtype=BasicAuth
ca.publish.ldappublish.ldap.ldapauth.bindDN=cn=Directory Manager
ca.publish.ldappublish.ldap.ldapauth.bindPWPrompt=CA LDAP Publishing
ca.publish.ldappublish.ldap.ldapconn.host=rhds11.example.com
ca.publish.ldappublish.ldap.ldapconn.port=12389
ca.publish.ldappublish.ldap.ldapconn.secureConn=false
ca.publish.publisher.instance.LdapCaCertPublisher.caCertAttr=cACertificate;binary
ca.publish.publisher.instance.LdapCaCertPublisher.caObjectClass=pkiCA
ca.publish.publisher.instance.LdapCaCertPublisher.pluginName=LdapCaCertPublisher
ca.publish.mapper.instance.LdapCaCertMap.createCAEntry=true
ca.publish.mapper.instance.LdapCaCertMap.dnPattern=cn=$subj.cn,dc=crl,dc=pki,dc=example,dc=com
ca.publish.mapper.instance.LdapCaCertMap.pluginName=LdapCaSimpleMap
ca.publish.rule.instance.LdapCaCertRule.enable=true
ca.publish.rule.instance.LdapCaCertRule.mapper=LdapCaCertMap
ca.publish.rule.instance.LdapCaCertRule.pluginName=Rule
ca.publish.rule.instance.LdapCaCertRule.predicate=
ca.publish.rule.instance.LdapCaCertRule.publisher=LdapCaCertPublisher
ca.publish.rule.instance.LdapCaCertRule.type=cacert
ca.publish.publisher.instance.LdapCrlPublisher.crlAttr=certificateRevocationList;binary
ca.publish.publisher.instance.LdapCrlPublisher.crlObjectClass=pkiCA
ca.publish.publisher.instance.LdapCrlPublisher.pluginName=LdapCrlPublisher
ca.publish.mapper.instance.LdapCrlMap.createCAEntry=true
ca.publish.mapper.instance.LdapCrlMap.dnPattern=cn=$subj.cn,dc=crl,dc=pki,dc=example,dc=com
ca.publish.mapper.instance.LdapCrlMap.pluginName=LdapCaSimpleMap
ca.publish.rule.instance.LdapCrlRule.enable=true
ca.publish.rule.instance.LdapCrlRule.mapper=LdapCrlMap
ca.publish.rule.instance.LdapCrlRule.pluginName=Rule
ca.publish.rule.instance.LdapCrlRule.predicate=issuingPointId==MasterCRL
ca.publish.rule.instance.LdapCrlRule.publisher=LdapCrlPublisher
ca.publish.rule.instance.LdapCrlRule.type=crl
ca.publish.enable=true
      Copy to Clipboard Toggle word wrap
      NOTE

      Alternatively, you can use the ca-config-set command to update the properties. For example: 

      # pki-server ca-config-set -i rhcs10-RSA-RootCA ca.publish.ldappublish.ldap.ldapconn.host rhds11.example.com; pki-server ca-config-set -i rhcs10-RSA-RootCA ca.publish.ldappublish.ldap.ldapconn.port 12389; pki-server ca-config-set -i rhcs10-RSA-RootCA ca.publish.mapper.instance.LdapCaCertMap.dnPattern "cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com"; pki-server ca-config-set -i rhcs10-RSA-RootCA ca.publish.mapper.instance.LdapCrlMap.dnPattern cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com
      Copy to Clipboard Toggle word wrap

      And so on.

      You can check that the parameters were successfully updated by using the ca-config-show command. For example: 

      # pki-server ca-config-show -i rhcs10-RSA-RootCA ca.publish.ldappublish.ldap.ldapconn.host rhds11.example.com; pki-server ca-config-show -i rhcs10-RSA-RootCA ca.publish.ldappublish.ldap.ldapconn.port 12389; pki-server ca-config-show -i rhcs10-RSA-RootCA ca.publish.mapper.instance.LdapCaCertMap.dnPattern "cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com"; pki-server ca-config-show -i rhcs10-RSA-RootCA ca.publish.mapper.instance.LdapCrlMap.dnPattern cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com
      Copy to Clipboard Toggle word wrap

    3. Start the RootCA instance: 

      pki-server start rhcs10-RSA-RootCA
      Copy to Clipboard Toggle word wrap

  2. Push the CRL and CA certificate to the LDAP directory via curl. For example: 

    # curl \
    -d "xml=true" \
    --cert-type P12 \
    --cert /opt/pki_rsa/rhcs10-RSA-RootCA/ca_admin_cert.p12:SECret.123 \
    -k \
    https://rhcs10.example.com:8443/ca/agent/ca/updateCRL \
    | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xml>
  <header>
    <crlIssuingPoint>MasterCRL</crlIssuingPoint>
    <crlUpdate>Scheduled</crlUpdate>
  </header>
  <fixed/>
  <records/>
</xml>
    Copy to Clipboard Toggle word wrap

  3. Disable the direct CA→OCSP CRL publishing method:

    1. Stop the RootCA: 

      pki-server stop rhcs10-RSA-RootCA
      Copy to Clipboard Toggle word wrap

    2. Edit the CA’s CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg) and set the following to false: 

      ca.publish.rule.instance.ocsprule-<host/port info>.enable=false
      Copy to Clipboard Toggle word wrap

      For example: 

      ca.publish.rule.instance.ocsprule-rhcs10-example-com-33443.enable=false
      Copy to Clipboard Toggle word wrap

    3. Start the CA for the configuration change to take effect: 

      # pki-server start rhcs10-RSA-RootCA
      Copy to Clipboard Toggle word wrap

  4. Update the Directory Server using curl. For example: 

    # curl \
  -d "updateCRL=yes&updateCA=yes&xml=true" \
  --cert-type P12 --cert /opt/pki_rsa/rhcs10-RSA-RootCA/ca_admin_cert.p12:SECret.123 \
  -k https://rhcs10.example.com:8443/ca/agent/ca/updateDir | xmllint --format -
    Copy to Clipboard Toggle word wrap

  5. Display the CRL using curl: 

    # curl \
   -d "pageSize=50&crlIssuingPoint=MasterCRL&pageStart=1&crlDisplayType=entireCRL&xml=true" \
   --cert-type P12 \
   --cert /opt/pki_rsa/rhcs10-RSA-RootCA/ca_admin_cert.p12:SECret.123 \
   -k \
   https://rhcs10.example.com:8443/ca/agent/ca/displayCRL | xmllint --format -
    Copy to Clipboard Toggle word wrap

  6. Run ldapsearch to verify that the CRL and the CA certificate are pushed to the LDAP directory: 

    # ldapsearch -x -D "cn=Directory Manager" -h "rhds11.example.com" -p 12389 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap 
    . . . Output omitted . . .

# CA Signing Certificate, crl.pki.example.com
dn: cn=CA Signing Certificate,dc=crl,dc=pki,dc=example,dc=com
cn: CA Signing Certificate
sn: CA Signing Certificate
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: pkiCA


cACertificate;binary::
MIICBzCB8AIBATANBgkqhkiG9w0BAQ0FADBdMRYwFAYDVQQKEw1FeGFtcGxlLVN1YkNBMSIwIAYDVQQLExlyaGNzOTMtVE1TLVN1YkNBLWFha2tpYW5nMR8wHQYDVQQDExZDQSBTaWduaW5nIENlcnRpZmljYXRlFw0xODAzMDkxODA

. . . Output omitted . . .

certificateRevocationList;binary::
IID9DCCAtygAwIBAgIEBwa6XDANBgkqhkiG9w0BAQsFADBiMR4wHAYDVQQKDBVFeGFtcGxlLXJoY3M5My1UTVMtQ0ExHzAdBgNVBAsMFnJoY3M5My1UTVMtQ

. . . Output omitted . . .
    Copy to Clipboard Toggle word wrap
  7. Disable certificate publishing for the RootCA (optional):
Note

The following procedure is to prevent a WARNING message in the debug logs like the following: 

2024-01-29 00:04:10 [Thread-18] INFO: CAPublisherProcessor: No rules enabled
2024-01-29 00:04:10 [Thread-18] SEVERE: PublishProcessor::publishCert : Failed to publish using rule: No rules enabled
2024-01-29 00:04:10 [Thread-18] WARNING: Could not publish certificate serial number 0x9c2762c. Error Failed to publish using rule: No rules enabled
Failed to publish using rule: No rules enabled
Copy to Clipboard Toggle word wrap

  1. Stop the RootCA: 

    # pki-server stop rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

  2. Edit /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg and set the following: 

    ca.publish.cert.enable=false
    Copy to Clipboard Toggle word wrap

  3. Start the RootCA for the configuration change to take effect: 

    # pki-server start rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

7.4.7.3. Configuring the OCSP to pull the CRLs from the LDAP server
Copiar o link

When you chose the alternative CRL publishing method, you need to set up the OCSP so that it knows where to pull the CRLs from. In order to do so, you need to configure the OCSP Revocation Info store information to point to the CRL publishing LDAP instance beforehand (that you have set up earlier in this chapter).

To configure the OCSP Revocation Info Store:

  1. Stop the OCSP: 

    # pki-server stop rhcs10-RSA-OCSP-rootca
    Copy to Clipboard Toggle word wrap

  2. Set the ldapStore properties in the OCSP’s CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/conf/CS.cfg). Make sure you change the ocsp.storeId parameter from defStore to ldapStore and add the following parameters: 

    ocsp.storeId=ldapStore
ocsp.store.ldapStore.numConns=1
ocsp.store.ldapStore.host0=rhds11.example.com
ocsp.store.ldapStore.port0=12389
ocsp.store.ldapStore.baseDN0=dc=crl,dc=pki,dc=example,dc=com
ocsp.store.ldapStore.refreshInSec0=120
ocsp.store.ldapStore.byName=true
ocsp.store.ldapStore.caCertAttr=cACertificate;binary
ocsp.store.ldapStore.crlAttr=certificateRevocationList;binary
ocsp.store.ldapStore.notFoundAsGood=true
    Copy to Clipboard Toggle word wrap
    Note

    The default value of refreshInSec0 is 86400, we configured it to be 120 for the purpose of testing, so that CRL updates happen every 2 minutes.

  3. Optionally, for better observation, you can set the debug level to 0 in the OCSP’s CS.cfg configuration file to ensure the LDAPStore update displays in the debug log. Otherwise, it will only display the status when there is no update. 

    debug.level=0
    Copy to Clipboard Toggle word wrap

    However, be warned that doing so will quickly increase the size of the debug log, especially with the OCSP systems. It is therefore only recommended for a short testing period.

  4. Start the OCSP for the ldapStore configuration to take effect: 

    # pki-server start rhcs10-RSA-OCSP-rootca
    Copy to Clipboard Toggle word wrap

7.4.7.4. Testing CRL publishing
Copiar o link

In this section, we are going to test CRL publishing by creating two user certificates, one of which will then be revoked. We will then check both the valid certificate and the revoked certificate against the OCSP instance to verify if the responses are as expected.

Create CMC certificates

Create agent-signed CMC certificates for user1 and for user2, the CMC requests are signed by the bootstrap admin certificate. For example, for user1:

  1. List the certificates in the database: 

    # certutil -d /root/.dogtag/pki_rsa_bootstrap/certs_db -L

Certificate Nickname                          Trust Attributes
                                              SSL,S/MIME,JAR/XPI

PKI Bootstrap Administrator for RSA-RootCA    u,u,u
CA Signing Cert - rhcs10-RSA-RootCA           CT,C,C

. . . Output omitted . . .
    Copy to Clipboard Toggle word wrap

  2. Use the PKCS10Client tool to generate a PKCS10 certificate request: 

    # PKCS10Client -d /root/.dogtag/pki_rsa_bootstrap/certs_db -p SECret.123 -n "cn=test user1, uid=user1" -o /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req

PKCS10Client: Certificate request written into /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req
PKCS10Client: PKCS#10 request key id written into /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req.keyId
    Copy to Clipboard Toggle word wrap

  3. Use cat on the .keyID file to display the key id. You will need it for the request.privKeyId= field in the next step: 

    # cat /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req.keyId; echo
    Copy to Clipboard Toggle word wrap

  4. Generate a CMC request:

    1. Create a CMCRequest configuration file, using the PKCS#10 request and private key id you obtained from the previous step. For example: 

      # vi cmcRequest_p10_user1.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req

### output: full path for the CMC request in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.req

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

### nickname: nickname for the certificate that will be used to sign the CMC full request.
### nickname=caaadmin
nickname=PKI Bootstrap Administrator for RSA-RootCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the user signing certificate and keys
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10

### 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=false
identityProofV2.hashAlg=SHA-512
identityProofV2.macAlg=SHA-256-HMAC
request.privKeyId=<key id output from the PKCS10Client|CRMFPopClient cert request>
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest cmcRequest_p10_user1.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-RootCA
createPKIData: begins
k=0
createPKIData:  format: pkcs10
PKCS10: PKCS10: begins
PKCS10: PKCS10: ends
selfSign 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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.req
      Copy to Clipboard Toggle word wrap

  5. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_user1.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db/

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-RootCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_user1.cfg

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

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  6. Process the response using the CMCResponse command: 

    # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.resp

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
   OID: {1 3 6 1 5 5 7 7 25}
   BodyList: 1
   Status: SUCCESS
    Copy to Clipboard Toggle word wrap
  7. Similarly, create a certificate for user2 by repeating the above procedure with the adequate values.

Set up revocation

Now, set up revocation in order to revoke the user2 certificate:

  1. Push the CRL and CA certificate to the LDAP directory:

    1. Login to the RootCA’s Agent UI in the browser.
    2. Select Update Revocation List and click Update.

    3. Click Update Directory Server and select:

      • Update the certificate revocation list to the directory
      • Update Certificate Manager certificate to the directory
    4. Click Update Directory.
    5. Wait for the OCSP’s ldapStore refresh to happen (observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/logs/debug).

  2. Check the certificate status by using the OCSPClient tool. For example, using the certificate serial number of user1 (in decimal): 

    # OCSPClient -v -d /root/.dogtag/pki_rsa_bootstrap/certs_db -h rhcs10.example.com -p 33080 -c "CA Signing Cert - rhcs10-RSA-RootCA" --serial 245832201

Initializing security database
Creating request for serial number 245832201
Submitting OCSP request
URL: http://rhcs10.example.com:33080/ocsp/ee/ocsp
Request Length: 71
Request: MEUwQzBBMD8wPTAJBgUrDgMCGgUABBRA+gjEGo4W0lUiC/Ve/oO8CrXQLQQUK4Bf
o2u6SW0p6q58dlNCXxOVw30CBA7kEiA=

Response Length: 3546
Response: <blob>
CertID.serialNumber=245832201
CertStatus=Good
    Copy to Clipboard Toggle word wrap

  3. Revoke the certificate of user2:

    1. Create a CMCRequest configuration file. For example: 

      # vi cmc-agent-signed-revoke.cfg
      Copy to Clipboard Toggle word wrap 
      ### numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

### output: full path for the CMC request in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.req

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

### nickname: nickname for the signing certificate which will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-RootCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db which stores the user signing certificate and keys
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10

### revocation parameters
revRequest.enable=true
revRequest.serial=245832201
revRequest.reason=unspecified
revRequest.comment=test user2 certificate revocation
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest cmc-agent-signed-revoke.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-RootCA
addRevRequestAttr: no sharedSecret found; request will be signed;
addRevRequestAttr: RevokeRequest control created.
selfSign 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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.req
      Copy to Clipboard Toggle word wrap

    3. Create a HttpClient configuration file. For example: 

      # vi HttpClient.revoke.agentSigned.cfg
      Copy to Clipboard Toggle word wrap 
      ### CA server host name.
host=rhcs10.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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-RootCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
      Copy to Clipboard Toggle word wrap

    4. Submit the request using the HttpClient command: 

      # HttpClient HttpClient.revoke.agentSigned.cfg

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

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.resp
      Copy to Clipboard Toggle word wrap

    5. Process the CMC Response: 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.resp

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
  OID: {1 3 6 1 5 5 7 7 25}
  BodyList: 1
  Status: SUCCESS
      Copy to Clipboard Toggle word wrap

Verification

  1. Verify in the CA signed audit log, for example /var/log/pki/rhcs10-RSA-RootCA/ca/signedAudit/ca_audit, that the user2 certificate indeed got revoked.

  2. Wait until the next CRL autoupdate (update interval in minutes configured by the ca.crl.MasterCRL.autoUpdateInterval of the RootCA’s CS.cfg file. By default, this is set to 240 minutes).

    Note

    Alternatively, if you want to manually update the CRL immediately, login to the RootCA’s Agent UI in the browser, and:

    1. Select Update Revocation List and click Update.

    2. Click Update Directory Server and select:

      • Update the certificate revocation list to the directory
      • Update Certificate Manager certificate to the directory
    3. Click Update Directory.

    Once the ldapStore refresh completes, observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/logs/debug.

  3. Verify with the OCSPCLient tool that the certificate of user2 has been revoked, using its serial number in decimal (with -c pointing to the nickname of the signing CA): 

    # OCSPClient -v -d /root/.dogtag/pki_rsa_bootstrap/certs_db -h rhcs10.example.com -p 33080 -c "CA Signing Cert - rhcs10-RSA-RootCA" --serial 245832201

Initializing security database
Creating request for serial number 245832201
Submitting OCSP request
URL: http://rhcs10.example.com:33080/ocsp/ee/ocsp
Request Length: 71
Request: MEUwQzBBMD8wPTAJBgUrDgMCGgUABBRA+gjEGo4W0lUiC/Ve/oO8CrXQLQQUK4Bf
o2u6SW0p6q58dlNCXxOVw30CBA7kEiA=

Response Length: 3563
Response: <blob>
CertID.serialNumber=245832201
CertStatus=Revoked
    Copy to Clipboard Toggle word wrap

Set ocsp.store.ldapStore.refreshInSec0 back to the desired value

Previously, we set ocsp.store.ldapStore.refreshInSec0=120 to allow for quicker CRL refresh (2 minutes) for testing purposes.

  • Please change the value in the OCSP’s CS.cfg to your desired value (in seconds), update the debug level back to 10 and restart the OCSP.

7.5. Create and configure the RootCA (Part II)
Copiar o link

This section continues the RootCA installation. It will walk you through the process of replacing the temporary DS TLS server certificate. If you have installed an OCSP instance, the role user certificates and the TLS server certificate of the RootCA will bear AIA extensions pointing to the OCSP instance.

7.5.1. Replace the temporary DS certificate (RootCA)
Copiar o link

Once the RootCA installation is complete, it can issue an official SSL server certificate for the Directory Server to replace the temporary one. Create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA using the RootCA bootstrap user credentials.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Verify the existence of the nssdb password file on this instance: 

    # ls /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt
    Copy to Clipboard Toggle word wrap

  2. Stop DS: 

    # dsctl slapd-CC-RSA-RootCA-LDAP stop
    Copy to Clipboard Toggle word wrap

  3. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/Server-Cert-rootca.csr -z /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-rootca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/Server-Cert-rootca.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

    1. Start DS: 

      # dsctl slapd-CC-RSA-RootCA-LDAP start
      Copy to Clipboard Toggle word wrap

    2. Remote copy the Server-Cert-rootca.csr file to the system where the CA resides. For example: 

      # scp /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/Server-Cert-rootca.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-rootca.csr
      Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-rootca.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-RootCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-RootCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-rootca.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-RootCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCertWithCRLDP
      Copy to Clipboard Toggle word wrap
      Note

      For EC certificates, use the ECC profiles by setting: 

      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECserverCertWithCRLDP
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-rootca.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response :

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.resp -v

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:
    Certificate:
        Data:
            Version:  v3
            Serial Number: 0xA383694
            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: Tuesday, April 5, 2022 8:41:36 AM EDT America/New_York
                Not  After: Monday, March 25, 2024 8:41:36 AM EDT America/New_York
            Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x5C8FAD4
            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: Tuesday, April 5, 2022 8:36:21 AM EDT America/New_York
                Not  After: Saturday, April 5, 2042 8:36:21 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x80296C3
            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: Tuesday, April 5, 2022 8:39:43 AM EDT America/New_York
                Not  After: Friday, April 5, 2041 8:39:43 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-rootca.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-rootca.pem is the new Server-Cert certificate of the Directory Server instance that serves as the internaldb of the RootCA.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-rootca.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-RootCA-LDAP stop
    Copy to Clipboard Toggle word wrap

  2. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-RootCA-LDAP/
    Copy to Clipboard Toggle word wrap

  3. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  4. Import the newly created DS certificate and its CA certificate in chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/Server-Cert-rootca.pem
    Copy to Clipboard Toggle word wrap

  5. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/

Certificate Nickname                        Trust Attributes
                                            SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA         CT,C,C
Server-Cert                                 u,u,u
    Copy to Clipboard Toggle word wrap

  6. On rhds11.example.com, start DS: 

    # dsctl slapd-CC-RSA-RootCA-LDAP start
    Copy to Clipboard Toggle word wrap

  7. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

Remove the trust for the temporary DS certificate for the RootCA instance

On rhcs10.example.com remove the temporary DS certificate from the RootCA instance database:

  1. Stop the CA: 

    # pki-server stop rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

  2. List the certificate: 

    # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/

Certificate Nickname                Trust Attributes
                                    SSL,S/MIME,JAR/XPI
DS temp CA certificate              CT,C,C
...
    Copy to Clipboard Toggle word wrap

  3. Remove the temporary certificate from the nssdb: 

    # certutil -D -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "DS temp CA certificate"
    Copy to Clipboard Toggle word wrap

Enable certificate revocation checks

Now that the Directory Server certificate has been replaced, we can see the CRL Distribution Point being detected during startup of the CA by enabling certificate revocation checks:

  1. To enable certificate revocation checks, in the respective /var/lib/pki/rhcs10-RSA-RootCA/conf/server.xml file:

    1. Set enableOCSP or enableRevocationCheck to true: 

      enableOCSP=true
or
enableRevocationCheck=true
      Copy to Clipboard Toggle word wrap

    2. Additionally, remove these two parameters and their assigned values: 

      ocspResponderURL
ocspResponderCertNickname
      Copy to Clipboard Toggle word wrap

  2. Disable the legacy revocation check method by editing the CA’s CS.cfg file and setting the following to false: 

    auths.revocationChecking.enabled=false
    Copy to Clipboard Toggle word wrap

  3. Start the RootCA instance: 

    # pki-server start rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap

Verifying the CRL Distribution Point

Now that we have replaced the server-cert of the root CA’s directory server using the profile caCMCserverCertWithCRLDP, this effectively triggers the CRL distribution point to be referenced by the CA during startup when initiating a connection with its internal directory server.

This section provides a rudimentary method to verify the CRL Distribution Point setup in the CA (see Section 7.3.8, “Configure support for CRL Distribution Point”):

  1. Check the publishing of the file-based CRL: 

    # ls -l /var/lib/pki/rhcs10-RSA-RootCA/crl
total 8
-rw-r--r--. 1 pkiuser pkiuser 574 Jun 20 18:08 ServerCertCRL-20240620-180859.der
-rw-r--r--. 1 pkiuser pkiuser 613 Jun 20 18:09 ServerCertCRL-20240620-180938.der
lrwxrwxrwx. 1 pkiuser pkiuser  68 Jun 20 18:09 ServerCertCRL.crl -> /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL-20240620-180938.der
    Copy to Clipboard Toggle word wrap

  2. Display and verify the content of the CRL 

    # BtoA /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL.crl /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL.bin
# PrettyPrintCrl /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL.bin
Certificate Revocation List:
        Data:
            Version:  v2
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
            This Update: Thursday, June 20, 2024 6:09:38 PM EDT America/New_York
            Next Update: Thursday, June 20, 2024 9:00:00 PM EDT America/New_York
            Revoked Certificates:
                Serial Number: 0xF6FDEF3
                Revocation Date: Thursday, June 20, 2024 6:09:38 PM EDT America/New_York
                Extensions:
                    Identifier: Revocation Reason - 2.5.29.21
                        Critical: no
                        Reason: Certificate_Hold
        Extensions:
            Identifier: CRL Number - 2.5.29.20
                Critical: no
                Number: 21
        Signature:
            Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Signature:
                69:38:47:5D:E4:50:17:C5:6C:60:3F:1B:D8:B4:62:4D:
                8B:11:FC:31:E4:26:6B:07:B6:BB:2C:7E:48:10:F4:DD:
                0A:67:17:CB:DF:4E:1A:50:BE:4F:8F:61:B4:91:AE:DA:
                E5:58:D5:FE:54:D9:94:B3:38:E1:B6:2C:19:C4:93:54:
                D5:5E:8B:61:4F:89:52:5A:F7:F5:1B:2F:59:19:AD:23:
                1F:6F:3C:93:17:F3:1A:1C:0B:9A:D2:8F:01:76:08:6E:
                DA:DD:6F:2D:75:54:D3:D4:40:9A:2B:5D:8B:D5:BB:8B:
                AF:89:E4:13:A7:F1:8A:AF:0A:72:26:E3:3D:FE:B3:90:
                2B:F7:88:57:E9:8B:E7:82:B6:D3:F3:80:CD:F7:87:77:
                69:AF:39:90:5E:46:9C:C2:C4:FA:44:01:77:6D:8F:2D:
                5A:BD:B9:39:3F:E4:99:E7:F9:FD:2D:CD:FA:87:C1:42:
                A4:D0:3B:87:0B:28:30:2D:2A:68:F2:68:7C:00:A8:4B:
                AC:38:49:5A:03:D1:B2:CE:45:D8:C1:6A:3F:42:F0:04:
                F6:CC:43:83:E8:19:41:6F:0A:64:95:C3:57:8F:54:53:
                31:40:58:D4:CD:29:0E:0A:D9:15:E9:08:0C:B8:74:F4:
                82:B4:4E:51:8F:1C:86:A3:2E:BF:BB:F8:4A:DD:17:07:
                37:27:0F:8B:5C:5E:75:28:B4:0C:DE:F2:38:B9:0E:AE:
                73:06:A1:3D:36:85:54:74:E6:C3:4B:78:80:9F:76:42:
                85:D2:94:FF:A0:0C:7D:23:61:AB:4E:7A:D0:5B:EC:CF:
                91:E9:CB:80:C4:A1:EB:86:FB:D8:E6:65:AC:48:D0:9F:
                8B:95:07:A9:CA:D7:34:A9:7B:32:25:1E:F4:21:A8:06:
                44:73:B4:99:79:B5:69:77:D1:18:3B:40:C5:20:AF:5C:
                8E:D0:65:AE:34:CF:1F:90:82:97:33:7F:90:E6:D9:BC:
                49:8F:BE:59:22:FE:09:E5:FA:F2:5F:31:77:6D:F8:99
    Copy to Clipboard Toggle word wrap
Important

Do not remove the CRL file (soft link file ServerCertCRL.crl, and its associated der file).

If you encounter a situation where the CRL file is missing or has been accidentally deleted from /var/lib/pki/rhcs10-RSA-RootCA/crl/, preventing the CA from starting, follow the steps below to regenerate the CRL file:

  1. Stop the CA service. 

    # pki-server stop rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap
  2. Set the enableRevocationCheck or enableOCSP parameter to false (if it is currently set to true) in CA’s server.xml.
  3. Set the ca.crl.ServerCertCRL.publishOnStart= parameter to true in CA’s CS.cfg.

  4. Start the CA service to regenerate the missing CRL file: 

    # pki-server start rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap
  5. After the CRL file has been recovered, stop the CA service once again.
  6. Revert the ca.crl.ServerCertCRL.publishOnStart= parameter to false in CA’s CS.cfg.
  7. Set the enableRevocationCheck or enableOCSP parameter to true in CA’s server.xml.
  8. Start the CA service again to apply the changes.

By following these steps, you will successfully recover the missing CRL file and ensure the CA can start correctly.

Verifying that the CA is functioning

  1. List the certificates in the CA: 

    # pki -p 8443 ca-cert-find
    Copy to Clipboard Toggle word wrap

  2. As the bootstrap admin user, list the users in the RootCA: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 8443 -n "PKI Bootstrap Administrator for RSA-RootCA" ca-user-find
    Copy to Clipboard Toggle word wrap

7.6. Create and configure the SubCA (Part I)
Copiar o link

To install and configure a SubCA instance, use either one of two pkispawn methods:

Note

In this installation example, since we intend to create an OCSP instance, we wish to create SubCA non-bootstrap role users certificates as well as the SubCA’s TLS server certificate, that bear the AIA extension pointing to the URL of the OCSP. To achieve this, we divide the SubCA creation and configuration, so that the setup happens in the following order:

  • Install the SubCA (this section)
  • Install the OCSP and set up the configuration for issuing certificates with the intended AIA
  • Complete the non-bootstrap user creation and replacement of the temporary TLS server certificate for the SubCA

7.6.1. Install the SubCA instance (single-step method)
Copiar o link

Configuring a SubCA instance using the single-step method requires creating a configuration file and running the pkispawn tool once. In this example, the SubCA is installed on rhcs10.example.com (as well as other instances), with its internal directory server on rhds11.example.com. The SubCA signing certificate is issued by the RootCA, and the SubCA creates its own security domain.

Prerequisites

Procedure

  1. Create a SubCA installation file at a chosen location (e.g. /root/pki_rsa): 

    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # vi subca_inst.cfg
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation.

    The values specified in the installation file below are examples. In addition to changing the HSM password, edit the values accordingly, for example ports, directories, nicknames, domains…​ 

    [DEFAULT]
pki_instance_name=rhcs10-RSA-SubCA
pki_https_port=31443
pki_http_port=31080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### CA cert chain concatenated in PEM format
pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-SubCA/ca_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-SubCA/certs_db
pki_client_database_password=SECret.123
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-SubCA
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=7389
pki_ds_ldaps_port=7636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/temp-dirsrv-subca-cert.pem
pki_ds_secure_connection_ca_nickname=DS temp CA certificate


[Tomcat]
pki_ajp_port=31009
pki_tomcat_server_port=31005


[CA]
pki_subordinate=True
pki_issuing_ca_https_port=8443
pki_issuing_ca_hostname=rhcs10.example.com
pki_issuing_ca=https://rhcs10.example.com:8443

### New Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_https_port=8443
pki_security_domain_password=SECret.123
pki_subordinate_create_new_security_domain=True
pki_subordinate_security_domain_name=Example-rhcs10-RSA-SubCA

pki_import_admin_cert=False
pki_admin_nickname=PKI Bootstrap Administrator for RSA-SubCA
pki_admin_name=caadmin
pki_admin_uid=caadmin
pki_admin_email=caadmin@example.com

pki_ca_signing_token=NHSM-CONN-XC
pki_ca_signing_key_algorithm=SHA256withRSA
pki_ca_signing_key_size=3072
pki_ca_signing_key_type=rsa
pki_ca_signing_nickname=CA Signing Cert - %(pki_instance_name)s
pki_ca_signing_signing_algorithm=SHA256withRSA

pki_ocsp_signing_token=NHSM-CONN-XC
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=3072
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-SubCA
pki_ds_database=CC-RSA-SubCA-LDAP
pki_share_db=False

### Enable random serial numbers
pki_random_serial_numbers_enable=True
    Copy to Clipboard Toggle word wrap

  2. Run the pkispawn tool to install the RHCS SubCA instance: 

    # pkispawn -s CA -f subca_inst.cfg --debug
    Copy to Clipboard Toggle word wrap

    This will create the SubCA instance in /var/lib/pki/rhcs10-RSA-SubCA.

Verification steps

  1. Show the status of the installed CA: 

    # pki-server status rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

    Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs.

  2. Verify the sanity of the CA by running the following command. It should display certificates: 

    # pki -p 31443 -h rhcs10.example.com ca-cert-find
    Copy to Clipboard Toggle word wrap
Note

An untrusted issuer warning for the CA signing certificate is displayed when connecting to the SubCA with a pki command for the first time, as seen below: 

WARNING: UNTRUSTED ISSUER encountered on 'CN=rhcs10.example.com,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA'
Trust this certificate (y/N)?
Copy to Clipboard Toggle word wrap

Select ‘y’ to trust the CA signing cert if the Subject DN matches the hostname as expected. The warning will not display again.

Note

Once you are done with this section (single-step method), skip directly to Section 7.6.3, “Update the CA certificate chain” to continue with the SubCA installation.

7.6.2. Installing the SubCA instance (two-step method)
Copiar o link

Configuring a SubCA instance using the two-step method requires creating a configuration file and running the pkispawn tool twice.
In this example, the SubCA is installed on rhcs10.example.com.

Prerequisites

First step of SubCA installation

  1. Create a CA installation file at a chosen location (e.g. /root/pki_rsa) on the machine that will host the RHCS instance (rhcs10.example.com). 

    # cd /root/pki_rsa

# vi subca_inst.cfg
    Copy to Clipboard Toggle word wrap 
    [DEFAULT]
pki_instance_name=rhcs10-RSA-SubCA
pki_https_port=31443
pki_http_port=31080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### CA cert chain concatenated in PEM format
pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-SubCA/ca_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-SubCA/certs_db
pki_client_database_password=SECret.123
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-SubCA
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=7389
pki_ds_ldaps_port=7636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/temp-dirsrv-subca-cert.pem
pki_ds_secure_connection_ca_nickname=DS temp CA certificate


[Tomcat]
pki_ajp_port=31009
pki_tomcat_server_port=31005


[CA]
pki_subordinate=True
pki_issuing_ca_https_port=8443
pki_issuing_ca_hostname=rhcs10.example.com
pki_issuing_ca=https://rhcs10.example.com:8443

### New Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_https_port=8443
pki_security_domain_password=SECret.123
pki_subordinate_create_new_security_domain=True
pki_subordinate_security_domain_name=Example-rhcs10-RSA-SubCA

pki_import_admin_cert=False
pki_admin_nickname=PKI Bootstrap Administrator for RSA-SubCA
pki_admin_name=caadmin
pki_admin_uid=caadmin
pki_admin_email=caadmin@example.com

pki_ca_signing_token=NHSM-CONN-XC
pki_ca_signing_key_algorithm=SHA256withRSA
pki_ca_signing_key_size=3072
pki_ca_signing_key_type=rsa
pki_ca_signing_nickname=CA Signing Cert - %(pki_instance_name)s
pki_ca_signing_signing_algorithm=SHA256withRSA

pki_ocsp_signing_token=NHSM-CONN-XC
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=3072
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-SubCA
pki_ds_database=CC-RSA-SubCA-LDAP
pki_share_db=False

### Enable random serial numbers
pki_random_serial_numbers_enable=True
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation. However, in a two-step installation, the pki_instance_name value of both files should match. The following values are just examples.

  2. Run the pkispawn tool to install the RHCS CA instance: 

    # pkispawn -s CA -f subca_inst.cfg --skip-configuration --debug
    Copy to Clipboard Toggle word wrap

Between-step configuration

As explained in Between step customization, you can customize certain things, such as the certificate profile of a system certificate.

  • Setting the Subject Key Identifier extension message digest algorithm for the CA signing certificate:

    1. Open the enrollment profile for this CA’s signing certificate: 

      # vi /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/caCert.profile
      Copy to Clipboard Toggle word wrap

    2. Add the following parameter: 

      7.default.params.messageDigest=SHA-256
      Copy to Clipboard Toggle word wrap
    3. Save the file.

    Likewise, do the same for the CA signing cert that this CA will be issuing in the future:

    1. Open the enrollment profile for the CA signing certificate: 

      # vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caInstallCACert.cfg
      Copy to Clipboard Toggle word wrap 
      # vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCcaCert.cfg
      Copy to Clipboard Toggle word wrap

    2. Add the following parameter: 

      policyset.caCertSet.8.default.params.messageDigest=SHA-256
      Copy to Clipboard Toggle word wrap
    3. Save the file.

  • Other between-step configuration changes can take place here too. For example, if you wish to extend the validity period of the audit signing certificate of this subsystem:

    1. Open the corresponding configuration file: 

      # vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caInternalAuthAuditSigningCert.cfg
      Copy to Clipboard Toggle word wrap

    2. Change the following range parameters to the desired values: 

      policyset.auditSigningCertSet.2.constraint.params.range=720
policyset.auditSigningCertSet.2.default.params.range=720
      Copy to Clipboard Toggle word wrap
    3. Save the file. Once you have done the second step of pkispawn in the next section, you should expect the validity of the audit signing certificate of this subsystem to match the values you have changed to.

Second step of SubCA installation

The second step of pkispawn in this case involves running the tool against the same file in a different manner to configure the RHCS CA instance.

  • Run the pkispawn tool to configure the CA: 

    # pkispawn -s CA -f subca_inst.cfg --skip-installation --debug
    Copy to Clipboard Toggle word wrap

Verification steps

  1. Show the status of the installed CA: 

    # pki-server status rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

    Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs.

  2. Verify the sanity of the CA by running the following command. It should display certificates: 

    # pki -p 8443 -h rhcs10.example.com ca-cert-find
    Copy to Clipboard Toggle word wrap
Note

An untrusted issuer warning for the CA signing certificate is displayed when connecting to the SubCA with a pki command for the first time, as seen below: 

WARNING: UNTRUSTED ISSUER encountered on 'CN=rhcs10.example.com,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA'
Trust this certificate (y/N)?
Copy to Clipboard Toggle word wrap

Select y to trust the CA signing cert if the Subject DN matches the hostname as expected. The warning will not display again.

7.6.3. Update the CA certificate chain
Copiar o link

Previously, we created the /opt/pki_rsa/ca-chain.pem file, that contains the RootCA certificate. We need to update this CA chain by adding the SubCA certificate.

  1. Retrieve the SubCA certificate into a .pem file 

    # certutil -L -d /var/lib/pki/rhcs10-RSA-SubCA/alias -n "CA Signing Cert - rhcs10-RSA-SubCA" -a > /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap

  2. Update the CA certificate chain. For example: 

    # cat /opt/pki_rsa/subCA.pem /opt/pki_rsa/rootCA.pem > /opt/pki_rsa/ca-chain.pem
    Copy to Clipboard Toggle word wrap
Note

In the context of this example installation, you need to order a certificate chain in the following way:

  • The chain starts with the leaf certificate placed at the top of the .pem file.
  • Its immediate signing certificate follows next.
  • The chain ends with the root certificate, at the bottom.

  1. Copy the files to rhds11.example.com (the machine that hosts the DS instances): 

    # scp /opt/pki_rsa/subCA.pem root@rhds11.example.com:/opt/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # scp /opt/pki_rsa/ca-chain.pem root@rhds11.example.com:/opt/pki_rsa
    Copy to Clipboard Toggle word wrap

  2. Restart the DS instance for the SubCA: 

    # dsctl slapd-CC-RSA-SubCA-LDAP restart
    Copy to Clipboard Toggle word wrap

7.6.4. Set up the SubCA bootstrap admin certificate
Copiar o link

This procedure consists in importing the SubCA bootstrap certificate/key into the nssdb (in our example, /root/.dogtag/pki_rsa_bootstrap/certs_db), in preparation for signing the CMC full request for role user certificates.

  1. Optional: If you have not done this previously, import the RootCA signing certificate into the nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-RootCA" --ca-cert /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap

  2. Import the SubCA signing certificate into the nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-SubCA" --ca-cert /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap

  3. Import the SubCA bootstrap certificate into the nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-import --pkcs12 /opt/pki_rsa/rhcs10-RSA-SubCA/ca_admin_cert.p12 --pkcs12-password SECret.123

----------------------------------------
Imported certificates from PKCS #12 file
----------------------------------------
    Copy to Clipboard Toggle word wrap

Verification:

  • List the contents of the nssdb: 

    # certutil -d /root/.dogtag/pki_rsa_bootstrap/certs_db -L

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI

CA Signing Cert - rhcs10-RSA-RootCA             CT,C,C
PKI Bootstrap Administrator for RSA-RootCA      u,u,u
CA Signing Cert - rhcs10-RSA-SubCA              CT,C,C
PKI Bootstrap Administrator for RSA-SubCA       u,u,u
    Copy to Clipboard Toggle word wrap

7.6.5. Disable non-CMC and non-installation profiles
Copiar o link

The profiles are stored in /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/. CMC profiles contain "CMC" in their profile ID. This section provides procedures to disable non-CMC and non-installation profiles.

Procedure

  1. Generate a list of non-CMC profiles to be edited: 

    # ls /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca | grep -v CMC | grep -v Install | grep -v caInternal | grep -v caECInternal | grep -v caAdminCert | grep -v caECAdminCert | tee /root/pki_rsa/subca-profile-deletelist.txt
    Copy to Clipboard Toggle word wrap

  2. Stop the SubCA instance: 

    pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

  3. For every profile in the list, change the visible and enable parameters from true to false. For example, use the following command to set visible=false and enable=false: 

    # cat /root/pki_rsa/subca-profile-deletelist.txt | while read line; do sed -i 's/^visible=true/visible=false/g' /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/$line; sed -i 's/^enable=true/enable=false/g' /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/$line; done
    Copy to Clipboard Toggle word wrap

  4. In addition, also change the visible parameter for the caCMCUserCert profile to false: 

    # sed -i 's/^visible=true/visible=false/' /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCUserCert.cfg /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCECUserCert.cfg
    Copy to Clipboard Toggle word wrap

  5. Start the SubCA instance: 

    pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap
Note

To allow for the SubCA role user certificates to contain AIA extensions pointing to the OCSP instance (yet to be created in the following section), relevant sections are placed in (Section 7.8, “Create and configure the SubCA (Part II)”), AFTER the OCSP instance creation.

7.6.6. Configure support for CRL Distribution Point
Copiar o link

Note

For more information on CRL Distribution Points, why they are needed and where they are best suited, see Section 9.4.1.2, “Enabling automatic revocation checking on the CA”.

To configure support for CRL Distribution Points, as an example, we describe how to set up a file-based CRL publisher as well as the partitioning of the CRL. You will also learn how to enable a certificate enrollment profile to issue certificates with the CRL Distribution Point extension. Finally, we describe how to replace the temporary Server-Cert of the CA’s LDAP server with a certificate issued from the CRL Distribution Point profiles.

Before proceeding with the following changes, stop the SubCA instance: 

# pki-server stop rhcs10-RSA-SubCA
Copy to Clipboard Toggle word wrap

7.6.6.1. CA Setup to support Server Cert CRL File Publishing
Copiar o link

Note

Before proceeding, save a copy of the configuration file before editing: 

# cp /var/lib/pki/rhcs10-RSA-SubCA/conf/CS.cfg  /var/lib/pki/rhcs10-RSA-SubCA/conf/CS.cfg.bak.<date>
Copy to Clipboard Toggle word wrap
7.6.6.1.1. Set up the file-based publisher: crlFilePublisher
Copiar o link

The configuration in this section creates a file-based CRL publisher called crlFilePublisher. When set up correctly, the CRL is stored under directory /var/lib/pki/rhcs10-RSA-SubCA/crl in DER format.

  1. Create the CRL directory for publishing the file-based partitioned CRL: 

    # mkdir /var/lib/pki/rhcs10-RSA-SubCA/crl
# chown pkiuser.pkiuser /var/lib/pki/rhcs10-RSA-SubCA/crl
    Copy to Clipboard Toggle word wrap

  2. Add the following to the CA’s CS.cfg: 

    ca.publish.publisher.instance.crlFilePublisher.Filename.b64=false
ca.publish.publisher.instance.crlFilePublisher.Filename.der=true
ca.publish.publisher.instance.crlFilePublisher.crlLinkExt=crl
ca.publish.publisher.instance.crlFilePublisher.directory=/var/lib/pki/rhcs10-RSA-SubCA/crl
ca.publish.publisher.instance.crlFilePublisher.latestCrlLink=true
ca.publish.publisher.instance.crlFilePublisher.maxAge=0
ca.publish.publisher.instance.crlFilePublisher.maxFullCRLs=0
ca.publish.publisher.instance.crlFilePublisher.pluginName=FileBasedPublisher
ca.publish.publisher.instance.crlFilePublisher.timeStamp=LocalTime
ca.publish.publisher.instance.crlFilePublisher.zipCRLs=false
ca.publish.publisher.instance.crlFilePublisher.zipLevel=9
    Copy to Clipboard Toggle word wrap
7.6.6.1.2. Set up the file-based publishing rule: FileCrlRule
Copiar o link

The configuration in this section creates a file-based publishing rule called FileCrlRule. The predicate specifies the issuing point to a partitioned CRL called ServerCertCRL (defined in Section 7.6.6.1.4, “Set up the CRL-partitioning for certificates issued via a profile”).

  • Add the following to the CA’s CS.cfg: 

    ca.publish.rule.instance.FileCrlRule.enable=true
ca.publish.rule.instance.FileCrlRule.mapper=NoMap
ca.publish.rule.instance.FileCrlRule.pluginName=Rule
ca.publish.rule.instance.FileCrlRule.predicate=issuingPointId==ServerCertCRL
ca.publish.rule.instance.FileCrlRule.publisher=crlFilePublisher
ca.publish.rule.instance.FileCrlRule.type=crl
    Copy to Clipboard Toggle word wrap
7.6.6.1.3. Modify the LDAP-based publishing rule: LdapCrlRule
Copiar o link

This configuration explicitly sets the LdapCrlRule predicate to the master (full) CRL. The master CRL is continuously supplied to the OCSP responder for proper OCSP support.

  • Modify the following in the CA’s CS.cfg: 

    ca.publish.rule.instance.LdapCrlRule.predicate=issuingPointId==MasterCRL
    Copy to Clipboard Toggle word wrap
7.6.6.1.4. Set up the CRL-partitioning for certificates issued via a profile
Copiar o link

The configuration in this section demonstrates how to partition a CRL to a smaller subset that could be utilized in the FileCrlRule defined above. The CRL is partitioned by the certificate enrollment profile(s) specified in the profileList parameter. A comma-separated list can be used for multiple profiles (for example, caCMCserverCertWithCRLDP.cfg and caCMCECserverCertWithCRLDP.cfg).

  • Add the following to the CA’s CS.cfg: 

    ca.crl.ServerCertCRL.allowExtensions=true
ca.crl.ServerCertCRL.alwaysUpdate=false
ca.crl.ServerCertCRL.autoUpdateInterval=240
ca.crl.ServerCertCRL.caCertsOnly=false
ca.crl.ServerCertCRL.cacheUpdateInterval=15
ca.crl.ServerCertCRL.class=com.netscape.ca.CRLIssuingPoint
ca.crl.ServerCertCRL.dailyUpdates=1:00
ca.crl.ServerCertCRL.description=CA's Certificate Revocation List containing certificates issued via the caCMCserverCertWithCRLDP and caCMCECserverCertWithCRLDP enrollment profile
ca.crl.ServerCertCRL.enable=true
ca.crl.ServerCertCRL.enableCRLCache=false
ca.crl.ServerCertCRL.enableCRLUpdates=true
ca.crl.ServerCertCRL.enableCacheRecovery=true
ca.crl.ServerCertCRL.enableCacheTesting=false
ca.crl.ServerCertCRL.enableDailyUpdates=true
ca.crl.ServerCertCRL.enableUpdateInterval=true
ca.crl.ServerCertCRL.extendedNextUpdate=true
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessLocation0=""
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessLocationType0=URI
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessMethod0=caIssuers
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.class=com.netscape.cms.crl.CMSAuthInfoAccessExtension
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.critical=false
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.enable=false
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.numberOfAccessDescriptions=1
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.type=CRLExtension
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.class=com.netscape.cms.crl.CMSAuthorityKeyIdentifierExtension
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.critical=false
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.enable=false
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.type=CRLExtension
ca.crl.ServerCertCRL.extension.CRLNumber.class=com.netscape.cms.crl.CMSCRLNumberExtension
ca.crl.ServerCertCRL.extension.CRLNumber.critical=false
ca.crl.ServerCertCRL.extension.CRLNumber.enable=true
ca.crl.ServerCertCRL.extension.CRLNumber.type=CRLExtension
ca.crl.ServerCertCRL.extension.CRLReason.class=com.netscape.cms.crl.CMSCRLReasonExtension
ca.crl.ServerCertCRL.extension.CRLReason.critical=false
ca.crl.ServerCertCRL.extension.CRLReason.enable=true
ca.crl.ServerCertCRL.extension.CRLReason.type=CRLEntryExtension
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.class=com.netscape.cms.crl.CMSDeltaCRLIndicatorExtension
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.critical=true
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.enable=false
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.type=CRLExtension
ca.crl.ServerCertCRL.extension.FreshestCRL.class=com.netscape.cms.crl.CMSFreshestCRLExtension
ca.crl.ServerCertCRL.extension.FreshestCRL.critical=false
ca.crl.ServerCertCRL.extension.FreshestCRL.enable=false
ca.crl.ServerCertCRL.extension.FreshestCRL.numPoints=0
ca.crl.ServerCertCRL.extension.FreshestCRL.pointName0=""
ca.crl.ServerCertCRL.extension.FreshestCRL.pointType0=""
ca.crl.ServerCertCRL.extension.FreshestCRL.type=CRLExtension
ca.crl.ServerCertCRL.extension.InvalidityDate.class=com.netscape.cms.crl.CMSInvalidityDateExtension
ca.crl.ServerCertCRL.extension.InvalidityDate.critical=false
ca.crl.ServerCertCRL.extension.InvalidityDate.enable=true
ca.crl.ServerCertCRL.extension.InvalidityDate.type=CRLEntryExtension
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.class=com.netscape.cms.crl.CMSIssuerAlternativeNameExtension
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.critical=false
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.enable=false
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.name0=""
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.nameType0=""
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.numNames=0
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.type=CRLExtension
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.class=com.netscape.cms.crl.CMSIssuingDistributionPointExtension
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.critical=true
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.enable=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.indirectCRL=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlyContainsCACerts=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlyContainsUserCerts=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlySomeReasons=""
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.pointName=
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.pointType=
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.type=CRLExtension
ca.crl.ServerCertCRL.includeExpiredCerts=false
ca.crl.ServerCertCRL.includeExpiredCertsOneExtraTime=false
ca.crl.ServerCertCRL.minUpdateInterval=0
ca.crl.ServerCertCRL.nextAsThisUpdateExtension=0
ca.crl.ServerCertCRL.nextUpdateGracePeriod=0
ca.crl.ServerCertCRL.profileCertsOnly=true
ca.crl.ServerCertCRL.profileList=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP
ca.crl.ServerCertCRL.publishOnStart=false
ca.crl.ServerCertCRL.saveMemory=false
ca.crl.ServerCertCRL.signingAlgorithm=SHA256withRSA
ca.crl.ServerCertCRL.updateSchema=1
    Copy to Clipboard Toggle word wrap
Note

For an ECC CA, set the following to SHA512withEC: 

ca.crl.ServerCertCRL.signingAlgorithm=SHA512withEC
Copy to Clipboard Toggle word wrap

7.6.6.2. Set up CRL HTTP service in the CA
Copiar o link

The CRL served by the CRL Distribution Point is published to a file (see sections above). This file is served by a non-SSL Tomcat service that we are adding to the CA’s server.xml as shown below:

  1. Add the following CRL service before the Catalina service in the file /var/lib/pki/rhcs10-RSA-SubCA/conf/server.xml: 

    <Service name="CRL">
 <Connector port="31085" protocol="HTTP/1.1" connectionTimeout="80000"
  maxParameterCount="1000" name="Unsecure" maxHttpHeaderSize="8192"
  acceptCount="100" maxThreads="15" minSpareThreads="25"
  enableLookups="false" disableUploadTimeout="true"/>
 <Engine name="CRL" defaultHost="localhost">
	<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
   <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
    prefix="localhost_crl_access_log" suffix=".txt" pattern="common"/>
  </Host>
 </Engine>
</Service>
    Copy to Clipboard Toggle word wrap

  2. In the above CRL service, choose a connector port number that has not been used. For example, if the subordinate CA’s HTTP port is 31080, then pick 31085. Ensure that the port is added for SELinux, for example: 

    # semanage port -a -t http_port_t -p tcp 31085
# firewall-cmd --permanent --add-port=31085/tcp
# firewall-cmd --reload
    Copy to Clipboard Toggle word wrap
    Note

    If your selected port has been pre-assigned with another SELinux context, you will see an error message that looks like the following: 

    ValueError: Port tcp/31085 already defined
    Copy to Clipboard Toggle word wrap

    You can also search and find out whether the CRL HTTP port is pre-assigned by using the following command: 

    # semanage port -l | grep <port>
    Copy to Clipboard Toggle word wrap

    We recommend that you select another port. However, if you wish to use the same port, you could do the following: 

    # semanage port -m -t http_port_t -p tcp 31085
    Copy to Clipboard Toggle word wrap

  3. When the server is restarted, the directory CRL/localhost is created under the CA’s conf directory if it does not exist. However, to prepare for the addition of the crl.xml file, do the following: 

    # mkdir -p  /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost
# chown -R pkiuser:pkiuser /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost
    Copy to Clipboard Toggle word wrap

  4. Create a crl.xml file under /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost, and add the following content: 

    <Context docBase="/var/lib/pki/rhcs10-RSA-SubCA/crl">
 <Resources allowLinking="true" cachingAllowed="false" />
</Context>
    Copy to Clipboard Toggle word wrap

  5. Set the user:group ownership for the crl.xml file: 

    chown pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost/crl.xml
    Copy to Clipboard Toggle word wrap
Note

The CRL Distribution Point set in the enrollment profile looks like this (see next section for full example): http://rhcs10.example.com:31085/crl/ServerCertCRL.crl

Important

File-based CRL publisher is only recommended for smaller CRLs with less frequently issued or revoked certificates. It is only recommended if necessary, such as in the case of CA startup setup described in this section.

7.6.6.3. CA’s enrollment profile configuration with CRL Distribution Points
Copiar o link

Enable the desired profile(s) to include the CRL Distribution Points. These are the profiles corresponding to the configuration in the sections above.

  1. Open the caCMCserverCertWithCRLDP.cfg profile (for enrollments with RSA keys) in the /var/lib/pki/<ca instance directory/ca/profiles/ca/ directory and update as follows: 

    # vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:31085/crl/ServerCertCRL.crl
…
    Copy to Clipboard Toggle word wrap

  2. Open the caCMCECserverCertWithCRLDP.cfg (for enrollments with ECC keys) in the /var/lib/pki/<ca instance directory/ca/profiles/ca/ directory and update as follows: 

    # vi /var/lib/pki/rhcs10-ECC-SubCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:21085/crl/ServerCertCRL.crl
…
    Copy to Clipboard Toggle word wrap

  3. Set user:group ownership: 

    # chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
# chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
    Copy to Clipboard Toggle word wrap

  4. Register a new profile in the CA’s CS.cfg:

    1. Add the following lines for each profile: 

      profile.caCMCserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg

profile.caCMCECserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCECserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
      Copy to Clipboard Toggle word wrap

    2. Edit the profile.list entry to add the two new profiles. For example: 

      profile.list=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP,acmeServerCert,caCMCserverCert,caCMCECserverCert, …
      Copy to Clipboard Toggle word wrap

7.6.6.4. Set up for more immediate CRL update
Copiar o link

Since server certs do not often get revoked, it is reasonable to update the CRL as soon as there is a revocation. Edit the CA’s CS.cfg: 

ca.crl.ServerCertCRL.alwaysUpdate=true
Copy to Clipboard Toggle word wrap

7.6.6.5. Start up the CA once the CA’s configuration is updated
Copiar o link

Once configuration is complete, start up the CA: 

# pki-server start rhcs10-RSA-SubCA
Copy to Clipboard Toggle word wrap
Note

You will be instructed to verify the CRL Distribution Point setup at the end of Section 7.8.2, “Replace the temporary DS certificate (SubCA)” once the CA’s Directory Server Server-Cert has been replaced correctly.

7.7. Create and configure the OCSP instance (SubCA)
Copiar o link

This section describes installing and configuring an OCSP instance against the SubCA.
The OCSP system certificates will be issued by the SubCA, and the OCSP will join the SubCA security domain.
In this example, the SubCA’s OCSP is installed on rhcs10.example.com, with its internal directory server on rhds11.example.com.

Note

Make sure that the file /opt/pki_rsa/ca-chain.pem contains the complete CA certificate chain (SubCA and RootCA certificates): 

# ls -l /opt/pki_rsa/ca-chain.pem

# cat /opt/pki_rsa/ca-chain.pem
Copy to Clipboard Toggle word wrap

7.7.1. Replace the temporary DS certificate (OCSP-subca)
Copiar o link

Prior to installing the OCSP for the SubCA, we are issuing an official SSL server certificate for the OCSP’s Directory Server to replace the temporary bootstrap one. To do that, we first create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-OCSP-subca-LDAP stop
    Copy to Clipboard Toggle word wrap
    Note

    If you are not certain about the name of a DS instance, list all instances using: dsctl -l

  2. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/Server-Cert-ocsp-subca.csr -z /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-ocsp-subca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/Server-Cert-ocsp-subca.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

  3. Remote copy the Server-Cert-ocsp-subca.csr file to the system where the CA resides. For example: 

    # scp /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/Server-Cert-ocsp-subca.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-subca.csr
    Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-subca.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-ocsp-subca.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-ocsp-subca.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response:

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.resp -v

Cert:0
…
===
Cert:1
…
===
Cert:2
…
===
Certificates:
    Certificate:
        Data:
            Version:  v3
            Serial Number: 0xF4837FD
            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: Wednesday, September 13, 2023 10:29:00 AM EDT America/New_York
                Not  After: Tuesday, September 2, 2025 10:29:00 AM EDT America/New_York
            Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0xD0F4BEE
            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: Friday, September 1, 2023 1:26:46 AM EDT America/New_York
                Not  After: Tuesday, September 1, 2043 1:26:46 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x485588D
            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: Tuesday, September 12, 2023 5:18:54 PM EDT America/New_York
                Not  After: Friday, September 12, 2042 5:18:54 PM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-subca.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-ocsp-subca.pem is the new Server-Cert certificate of the Directory Server instance that serves as the internaldb of the OCSP for the SubCA.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-subca.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-OCSP-subca-LDAP/
    Copy to Clipboard Toggle word wrap

  2. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  3. Import the newly created DS certificate and the CA certificates in its chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-SubCA" -i /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/Server-Cert-ocsp-subca.pem
    Copy to Clipboard Toggle word wrap

  4. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/

Certificate Nickname                           Trust Attributes
                                               SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA            CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA             CT,C,C
Server-Cert                                    u,u,u
    Copy to Clipboard Toggle word wrap

  5. Start DS: 

    # dsctl slapd-CC-RSA-OCSP-subca-LDAP start
    Copy to Clipboard Toggle word wrap

  6. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:11636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:11636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

7.7.2. Install the OCSP instance for the SubCA
Copiar o link

To install the OCSP instance for the SubCA, use either the single-step method or the two-step method. The following procedure describes the single-step method. If you wish to install using the two-step method, please refer to Section 7.2.2, “Installation methods (single-step or two-step)” as well as Section 7.3.2, “Installing the RootCA instance (two-step method)”.

Prerequisites

Procedure

  1. Create an OCSP installation file at a chosen location (e.g. /root/pki_rsa) for generating certificate requests: 

    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # vi ocsp_subca_inst.cfg
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation.

    The values specified in the installation file below are examples. In addition to changing the HSM password, edit the values accordingly, for example ports, directories, nicknames, domains…​ 

    [DEFAULT]
pki_instance_name=rhcs10-RSA-OCSP-subca
pki_https_port=32443
pki_http_port=32080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### CA cert chain concatenated in PEM format
pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-OCSP-subca/ocsp_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-OCSP-subca/certs_db
pki_client_database_password=SECret.123
pki_client_database_purge=False
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-OCSP-subca
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=11389
pki_ds_ldaps_port=11636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/ca-chain.pem
pki_ds_secure_connection_ca_nickname=CA Signing Cert - rhcs10-RSA-SubCA

### Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_https_port=31443
pki_security_domain_password=SECret.123
pki_security_domain_user=caadmin


[Tomcat]
pki_ajp_port=32009
pki_tomcat_server_port=32005


[OCSP]
pki_import_admin_cert=False

pki_ocsp_signing_token=NHSM-CONN-XC
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=3072
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA

pki_admin_nickname=PKI Bootstrap Administrator for RSA-OCSP-subca
pki_admin_name=ocspadmin
pki_admin_uid=ocspadmin
pki_admin_email=ocspadmin@example.com

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-OCSP-subca
pki_ds_database=CC-RSA-OCSP-subca-LDAP
pki_share_db=False
    Copy to Clipboard Toggle word wrap

  2. Run the pkispawn tool to install the OCSP subsystem: 

    # pkispawn -s OCSP -f ocsp_subca_inst.cfg --debug
    Copy to Clipboard Toggle word wrap

    This will create the OCSP instance in /var/lib/pki/rhcs10-RSA-OCSP-subca.

Note

For ease of reference, if you wanted to install this OCSP using the two-step method:

  1. First run the pkispawn tool with the --skip-configuration option to install the SubCA’s OCSP instance: 

    # pkispawn -s OCSP -f ocsp_subca_inst.cfg --skip-configuration --debug
    Copy to Clipboard Toggle word wrap
  2. Customize the configuration files between the two installation steps

  3. Run the pkispawn tool to configure the OCSP: 

    # pkispawn -s OCSP -f ocsp_subca_inst.cfg --skip-installation --debug
    Copy to Clipboard Toggle word wrap

Verification

  • Show the status of the installed OCSP instance: 

    # pki-server status rhcs10-RSA-OCSP-subca
    Copy to Clipboard Toggle word wrap

7.7.3. Increase the SubCA’s OCSP pkiconsole timeout
Copiar o link

  1. Log in to rhcs10.example.com as root.

  2. Stop the SubCA’s OCSP service: 

    pki-server stop rhcs10-RSA-OCSP-subca
    Copy to Clipboard Toggle word wrap

  3. Edit /var/lib/pki/rhcs10-RSA-OCSP-subca/conf/server.xml to increase the timeout period: 

    <Connector name="Secure" port="32443" …
connectionTimeout="3000000"
    Copy to Clipboard Toggle word wrap

  4. Start the SubCA’s OCSP service: 

    # pki-server start rhcs10-RSA-OCSP-subca
    Copy to Clipboard Toggle word wrap

7.7.4. Set the default AIA extension to point to this OCSP
Copiar o link

By default, unless explicitly specified, the CA issues certificates with an AIA (Authority Information Access) extension pointing to the CA’s own internal OCSP. Now that you have set up an OCSP instance, you can configure the SubCA to start issuing certificates with an AIA extension that points to the OCSP instance instead.

On rhcs10.example.com as root:

  1. Stop the SubCA: 

    # pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

  2. Edit the SubCA’s CS.cfg and set the ca.defaultOcspUri variable to point to the OCSP. For example: 

    ca.defaultOcspUri=http://rhcs10.example.com:32080/ocsp/ee/ocsp
    Copy to Clipboard Toggle word wrap

  3. Start the SubCA: 

    # pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap
Note

The OCSP URL of each subsystem (e.g. KRA) is set in its server.xml file by default. When enabled, this directs the RHCS instance to use the static URL when looking up a certificate status, instead of the AIA extension embedded in the peer certificate. To use the AIA extension, you will be directed to follow Section 7.13.10.2, “Enabling OCSP for the CA / KRA / TKS / TPS” when installing the subsystem.

7.7.5. Create OCSP role users
Copiar o link

  • Follow the steps in Section 7.12, “Create PKI role users” to create single-role admin, agent, audit users in OCSP. In order to do so, you will need to import the SubCA’s OCSP bootstrap administrator certificate, ocsp_admin_cert.p12. E.g.: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-import --pkcs12 /opt/pki_rsa/rhcs10-RSA-OCSP-subca/ocsp_admin_cert.p12 --pkcs12-password SECret.123

----------------------------------------
Imported certificates from PKCS #12 file
----------------------------------------
    Copy to Clipboard Toggle word wrap

7.7.6. Login to the OCSP pkiconsole with client authentication
Copiar o link

  1. Configure OCSP with authType=sslclientauth and import the role user certificate by following Configure pkiconsole login with client authentication.

  2. Login to pkiconsole with the client authentication certificate of the role user: 

    # pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:32443/ocsp
    Copy to Clipboard Toggle word wrap

    And select the role user certificate nickname from the list, for example OCSP adminV. Login to the console should be successful.

7.7.7. Configuration for CRL publishing
Copiar o link

Red Hat Certificate System offers two methods of CRL publishing to be consumed by an OCSP instance external to the CA:

  • Direct CA→OCSP CRL publishing
  • Indirect publishing with CA→LDAP, then OCSP←LDAP

By default, once you set up an OCSP instance, the first CRL publishing method is automatically set up as well, which allows direct CA→OCSP CRL publishing.

This section details the second method, which is to have the CA publish its CRLs to an LDAP server, and the OCSP can then pull the CRLs from the LDAP server.

7.7.7.1. Setting up the LDAP server for CRL publishing
Copiar o link

On rhds11.example.com as root:

  1. Install a Directory Server instance, which the CA will use to publish the CRL. Red Hat Directory Server is listening over the LDAP/LDAPS ports, 5389 and 5636 respectively.

    1. Use the dscreate create-template command to create a template .cfg file at a chosen location (e.g. /root/pki_rsa): 

      # dscreate create-template /root/pki_rsa/subca-crl-publish-ldap.cfg
      Copy to Clipboard Toggle word wrap

    2. Edit the .cfg file created in the previous step. Uncomment the below parameters and set them to customize the installation: 

      full_machine_name = rhds11.example.com
port = 5389
secure_port = 5636
instance_name = CC-RSA-SubCA-CRL-PUBLISH
root_password = SECret.123
suffix = dc=example,dc=com
create_suffix_entry = True
      Copy to Clipboard Toggle word wrap

    3. Install the Directory Server instance: 

      # dscreate from-file /root/pki_rsa/subca-crl-publish-ldap.cfg

Starting installation...

Completed installation for CC-RSA-SubCA-CRL-PUBLISH
      Copy to Clipboard Toggle word wrap

  2. Add an ACI (Access Control Instruction) rule to allow anonymous bind access. By default, this is disabled.

    1. Create the ldapaci.ldif file at a chosen location (e.g. /root/pki_rsa/dirsrv/) with the following content: 

      dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
      Copy to Clipboard Toggle word wrap

    2. Run the ldapmodify command to add the ACI: 

      # ldapmodify -x -h rhds11.example.com -p 5389 -D 'cn=Directory Manager' -W -f /root/pki_rsa/dirsrv/ldapaci.ldif
      Copy to Clipboard Toggle word wrap

  3. Prepare the CRL publishing subtree:

    1. Create two files in the /root/pki_rsa/dirsrv directory with the following content:

      • For the subca_pki_subtree.ldif file: 

        dn: dc=pki,dc=example,dc=com
objectClass: domain
dc: pki
        Copy to Clipboard Toggle word wrap

      • For the subca_crl_subtree.ldif file: 

        dn: dc=crl,dc=pki,dc=example,dc=com
objectClass: domain
dc: crl
        Copy to Clipboard Toggle word wrap

    2. Add both entries to the CRL instance: 

      # ldapadd -x -H ldap://rhds11.example.com:5389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/subca_pki_subtree.ldif
      Copy to Clipboard Toggle word wrap 
      # ldapadd -x -H ldap://rhds11.example.com:5389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/subca_crl_subtree.ldif
      Copy to Clipboard Toggle word wrap

7.7.7.2. Configuring CRL publishing on the SubCA
Copiar o link

To configure CRL publishing:

  1. Add the ca.publish. properties:

    1. Stop the SubCA instance: 

      # pki-server stop rhcs10-RSA-SubCA
      Copy to Clipboard Toggle word wrap

    2. Configure the following properties in the SubCA’s CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg): 

      ca.publish.ldappublish.enable=true
ca.publish.ldappublish.ldap.ldapauth.authtype=BasicAuth
ca.publish.ldappublish.ldap.ldapauth.bindDN=cn=Directory Manager
ca.publish.ldappublish.ldap.ldapauth.bindPWPrompt=CA LDAP Publishing
ca.publish.ldappublish.ldap.ldapconn.host=rhds11.example.com
ca.publish.ldappublish.ldap.ldapconn.port=5389
ca.publish.ldappublish.ldap.ldapconn.secureConn=false
ca.publish.publisher.instance.LdapCaCertPublisher.caCertAttr=cACertificate;binary
ca.publish.publisher.instance.LdapCaCertPublisher.caObjectClass=pkiCA
ca.publish.publisher.instance.LdapCaCertPublisher.pluginName=LdapCaCertPublisher
ca.publish.mapper.instance.LdapCaCertMap.createCAEntry=true
ca.publish.mapper.instance.LdapCaCertMap.dnPattern=cn=$subj.cn,dc=crl,dc=pki,dc=example,dc=com
ca.publish.mapper.instance.LdapCaCertMap.pluginName=LdapCaSimpleMap
ca.publish.rule.instance.LdapCaCertRule.enable=true
ca.publish.rule.instance.LdapCaCertRule.mapper=LdapCaCertMap
ca.publish.rule.instance.LdapCaCertRule.pluginName=Rule
ca.publish.rule.instance.LdapCaCertRule.predicate=
ca.publish.rule.instance.LdapCaCertRule.publisher=LdapCaCertPublisher
ca.publish.rule.instance.LdapCaCertRule.type=cacert
ca.publish.publisher.instance.LdapCrlPublisher.crlAttr=certificateRevocationList;binary
ca.publish.publisher.instance.LdapCrlPublisher.crlObjectClass=pkiCA
ca.publish.publisher.instance.LdapCrlPublisher.pluginName=LdapCrlPublisher
ca.publish.mapper.instance.LdapCrlMap.createCAEntry=true
ca.publish.mapper.instance.LdapCrlMap.dnPattern=cn=$subj.cn,dc=crl,dc=pki,dc=example,dc=com
ca.publish.mapper.instance.LdapCrlMap.pluginName=LdapCaSimpleMap
ca.publish.rule.instance.LdapCrlRule.enable=true
ca.publish.rule.instance.LdapCrlRule.mapper=LdapCrlMap
ca.publish.rule.instance.LdapCrlRule.pluginName=Rule
ca.publish.rule.instance.LdapCrlRule.predicate=issuingPointId==MasterCRL
ca.publish.rule.instance.LdapCrlRule.publisher=LdapCrlPublisher
ca.publish.rule.instance.LdapCrlRule.type=crl
ca.publish.enable=true
      Copy to Clipboard Toggle word wrap
      NOTE

      Alternatively, you can use the ca-config-set command to update the properties. For example: 

      # pki-server ca-config-set -i rhcs10-RSA-SubCA ca.publish.ldappublish.ldap.ldapconn.host rhds11.example.com; pki-server ca-config-set -i rhcs10-RSA-SubCA ca.publish.ldappublish.ldap.ldapconn.port 5389; pki-server ca-config-set -i rhcs10-RSA-SubCA ca.publish.mapper.instance.LdapCaCertMap.dnPattern "cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com"; pki-server ca-config-set -i rhcs10-RSA-SubCA ca.publish.mapper.instance.LdapCrlMap.dnPattern cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com
      Copy to Clipboard Toggle word wrap

      And so on.

      You can check that the parameters were successfully updated by using the ca-config-show command. For example: 

      # pki-server ca-config-show -i rhcs10-RSA-SubCA ca.publish.ldappublish.ldap.ldapconn.host rhds11.example.com; pki-server ca-config-show -i rhcs10-RSA-SubCA ca.publish.ldappublish.ldap.ldapconn.port 5389; pki-server ca-config-show -i rhcs10-RSA-SubCA ca.publish.mapper.instance.LdapCaCertMap.dnPattern "cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com"; pki-server ca-config-show -i rhcs10-RSA-SubCA ca.publish.mapper.instance.LdapCrlMap.dnPattern cn=\$subj.cn,dc=crl,dc=pki,dc=example,dc=com
      Copy to Clipboard Toggle word wrap

    3. Start the SubCA instance: 

      pki-server start rhcs10-RSA-SubCA
      Copy to Clipboard Toggle word wrap

  2. Push the CRL and CA certificate to the LDAP directory via curl. For example: 

    # curl \
    -d "xml=true" \
    --cert-type P12 \
    --cert /opt/pki_rsa/rhcs10-RSA-SubCA/ca_admin_cert.p12:SECret.123 \
    -k \
    https://rhcs10.example.com:31443/ca/agent/ca/updateCRL \
    | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xml>
  <header>
    <crlIssuingPoint>MasterCRL</crlIssuingPoint>
    <crlUpdate>Scheduled</crlUpdate>
  </header>
  <fixed/>
  <records/>
</xml>
    Copy to Clipboard Toggle word wrap

  3. Disable the direct CA→OCSP CRL publishing method:

    1. Stop the SubCA: 

      # pki-server stop rhcs10-RSA-SubCA
      Copy to Clipboard Toggle word wrap

    2. Edit the CA’s CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg) and set the following to false: 

      ca.publish.rule.instance.ocsprule-<host/port info>.enable=false
      Copy to Clipboard Toggle word wrap

      For example: 

      ca.publish.rule.instance.ocsprule-rhcs10-example-com-32443.enable=false
      Copy to Clipboard Toggle word wrap

    3. Start the CA for the configuration change to take effect: 

      # pki-server start rhcs10-RSA-SubCA
      Copy to Clipboard Toggle word wrap

  4. Update the Directory Server using curl. For example: 

    # curl \
  -d "updateCRL=yes&updateCA=yes&xml=true" \
  --cert-type P12 --cert /opt/pki_rsa/rhcs10-RSA-SubCA/ca_admin_cert.p12:SECret.123 \
  -k https://rhcs10.example.com:31443/ca/agent/ca/updateDir | xmllint --format -
    Copy to Clipboard Toggle word wrap

  5. Display the CRL using curl: 

    # curl \
   -d "pageSize=50&crlIssuingPoint=MasterCRL&pageStart=1&crlDisplayType=entireCRL&xml=true" \
   --cert-type P12 \
   --cert /opt/pki_rsa/rhcs10-RSA-SubCA/ca_admin_cert.p12:SECret.123 \
   -k \
   https://rhcs10.example.com:31443/ca/agent/ca/displayCRL | xmllint --format -
    Copy to Clipboard Toggle word wrap

  6. Run ldapsearch to verify that the CRL and the CA certificate are pushed to the LDAP directory: 

    # ldapsearch -x -D "cn=Directory Manager" -h "rhds11.example.com" -p 5389 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap 
    . . . Output omitted . . .

# CA Signing Certificate, crl.pki.example.com
dn: cn=CA Signing Certificate,dc=crl,dc=pki,dc=example,dc=com
cn: CA Signing Certificate
sn: CA Signing Certificate
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: pkiCA


cACertificate;binary::
MIICBzCB8AIBATANBgkqhkiG9w0BAQ0FADBdMRYwFAYDVQQKEw1FeGFtcGxlLVN1YkNBMSIwIAYDVQQLExlyaGNzOTMtVE1TLVN1YkNBLWFha2tpYW5nMR8wHQYDVQQDExZDQSBTaWduaW5nIENlcnRpZmljYXRlFw0xODAzMDkxODA

. . . Output omitted . . .

certificateRevocationList;binary::
IID9DCCAtygAwIBAgIEBwa6XDANBgkqhkiG9w0BAQsFADBiMR4wHAYDVQQKDBVFeGFtcGxlLXJoY3M5My1UTVMtQ0ExHzAdBgNVBAsMFnJoY3M5My1UTVMtQ

. . . Output omitted . . .
    Copy to Clipboard Toggle word wrap
  7. Disable certificate publishing for the SubCA (optional):
Note

The following procedure is to prevent a WARNING message in the debug logs like the following: 

2024-01-29 00:04:10 [Thread-18] INFO: CAPublisherProcessor: No rules enabled
2024-01-29 00:04:10 [Thread-18] SEVERE: PublishProcessor::publishCert : Failed to publish using rule: No rules enabled
2024-01-29 00:04:10 [Thread-18] WARNING: Could not publish certificate serial number 0x9c2762c. Error Failed to publish using rule: No rules enabled
Failed to publish using rule: No rules enabled
Copy to Clipboard Toggle word wrap

  1. Stop the SubCA: 

    # pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

  2. Edit /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg and set the following: 

    ca.publish.cert.enable=false
    Copy to Clipboard Toggle word wrap

  3. Start the SubCA for the configuration change to take effect: 

    # pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

7.7.7.3. Configuring the OCSP to pull the CRLs from the LDAP server
Copiar o link

When you chose the alternative CRL publishing method, you need to set up the OCSP so that it knows where to pull the CRLs from. In order to do so, you need to configure the OCSP Revocation Info store information to point to the CRL publishing LDAP instance beforehand (that you have set up earlier in this chapter).

To configure the OCSP Revocation Info Store:

  1. Stop the OCSP: 

    # pki-server stop rhcs10-RSA-OCSP-subca
    Copy to Clipboard Toggle word wrap

  2. Set the ldapStore properties in the OCSP’s CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-OCSP-subca/ocsp/conf/CS.cfg). Make sure you change the ocsp.storeId parameter from defStore to ldapStore and add the following parameters: 

    ocsp.storeId=ldapStore
ocsp.store.ldapStore.numConns=1
ocsp.store.ldapStore.host0=rhds11.example.com
ocsp.store.ldapStore.port0=5389
ocsp.store.ldapStore.baseDN0=dc=crl,dc=pki,dc=example,dc=com
ocsp.store.ldapStore.refreshInSec0=120
ocsp.store.ldapStore.byName=true
ocsp.store.ldapStore.caCertAttr=cACertificate;binary
ocsp.store.ldapStore.crlAttr=certificateRevocationList;binary
ocsp.store.ldapStore.notFoundAsGood=true
    Copy to Clipboard Toggle word wrap
    Note

    The default value of refreshInSec0 is 86400, we configured it to be 120 for the purpose of testing, so that CRL updates happen every 2 minutes.

  3. Optionally, for better observation, you can set the debug level to 0 in the OCSP’s CS.cfg configuration file to ensure the LDAPStore update displays in the debug log. Otherwise, it will only display the status when there is no update. 

    debug.level=0
    Copy to Clipboard Toggle word wrap

    However, be warned that doing so will quickly increase the size of the debug log, especially with the OCSP systems. It is therefore only recommended for a short testing period.

  4. Start the OCSP for the ldapStore configuration to take effect: 

    # pki-server start rhcs10-RSA-OCSP-subca
    Copy to Clipboard Toggle word wrap

7.7.7.4. Testing CRL publishing
Copiar o link

In this section, we are going to test CRL publishing by creating two user certificates, one of which will then be revoked. We will then check both the valid certificate and the revoked certificate against the OCSP instance to verify if the responses are as expected.

Create CMC certificates

Create agent-signed CMC certificates for user1 and for user2, the CMC requests are signed by the bootstrap admin certificate. For example, for user1:

  1. List the certificates in the database: 

    # certutil -d /root/.dogtag/pki_rsa_bootstrap/certs_db -L

Certificate Nickname                          Trust Attributes
                                              SSL,S/MIME,JAR/XPI

PKI Bootstrap Administrator for RSA-SubCA     u,u,u
CA Signing Cert - rhcs10-RSA-SubCA            CT,C,C

. . . Output omitted . . .
    Copy to Clipboard Toggle word wrap

  2. Use the PKCS10Client tool to generate a PKCS10 certificate request: 

    # PKCS10Client -d /root/.dogtag/pki_rsa_bootstrap/certs_db -p SECret.123 -n "cn=test user1, uid=user1" -o /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req

PKCS10Client: Certificate request written into /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req
PKCS10Client: PKCS#10 request key id written into /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req.keyId
    Copy to Clipboard Toggle word wrap
    NOTE

    Use cat on the keyId file so it will be available for the next step: 

    # cat /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req.keyId; echo
    Copy to Clipboard Toggle word wrap

  3. Generate a CMC request:

    1. Create a CMCRequest configuration file, using the PKCS#10 request and private key id you obtained from the previous step. For example: 

      # vi cmcRequest_p10_user1.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req

### output: full path for the CMC request in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.req

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

### nickname: nickname for the certificate that will be used to sign the CMC full request.
### nickname=caaadmin
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the user signing certificate and keys
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10

### 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=false
identityProofV2.hashAlg=SHA-512
identityProofV2.macAlg=SHA-256-HMAC
request.privKeyId=<output from PKCS10Client|CRMFPopClient xxx.priv>
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest cmcRequest_p10_user1.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
createPKIData: begins
k=0
createPKIData:  format: pkcs10
PKCS10: PKCS10: begins
PKCS10: PKCS10: ends
selfSign 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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.req
      Copy to Clipboard Toggle word wrap

  4. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_user1.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db/

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_user1.cfg

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

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  5. Process the response using the CMCResponse command: 

    # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.user1_pkcs10.resp

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
   OID: {1 3 6 1 5 5 7 7 25}
   BodyList: 1
   Status: SUCCESS
    Copy to Clipboard Toggle word wrap
  6. Similarly, create a certificate for user2 by repeating the above procedure with the adequate values.

Set up revocation

Now, set up revocation in order to revoke the user2 certificate:

  1. Push the CRL and CA certificate to the LDAP directory:

    1. Login to the SubCA’s Agent UI in the browser.
    2. Select Update Revocation List and click Update.

    3. Click Update Directory Server and select:

      • Update the certificate revocation list to the directory
      • Update Certificate Manager certificate to the directory
    4. Click Update Directory.
    5. Wait for the OCSP’s ldapStore refresh to happen (observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-subca/ocsp/logs/debug).

  2. Check the certificate status by using the OCSPClient tool. For example, using the certificate serial number of user1 (in decimal): 

    # OCSPClient -v -d /root/.dogtag/pki_rsa_bootstrap/certs_db -h rhcs10.example.com -p 32080 -c "CA Signing Cert - rhcs10-RSA-SubCA" --serial 245832201

Initializing security database
Creating request for serial number 245832201
Submitting OCSP request
URL: http://rhcs10.example.com:32080/ocsp/ee/ocsp
Request Length: 71
Request: MEUwQzBBMD8wPTAJBgUrDgMCGgUABBRA+gjEGo4W0lUiC/Ve/oO8CrXQLQQUK4Bf
o2u6SW0p6q58dlNCXxOVw30CBA7kEiA=

Response Length: 3546
Response: <blob>
CertID.serialNumber=245832201
CertStatus=Good
    Copy to Clipboard Toggle word wrap

  3. Revoke the certificate of user2:

    1. Create a CMCRequest configuration file. For example: 

      # vi cmc-agent-signed-revoke.cfg
      Copy to Clipboard Toggle word wrap 
      ### numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

### output: full path for the CMC request in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.req

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

### nickname: nickname for the signing certificate which will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db which stores the user signing certificate and keys
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10

### revocation parameters
revRequest.enable=true
revRequest.serial=245832201
revRequest.reason=unspecified
revRequest.comment=test user2 certificate revocation
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest cmc-agent-signed-revoke.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
addRevRequestAttr: no sharedSecret found; request will be signed;
addRevRequestAttr: RevokeRequest control created.
selfSign 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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.req
      Copy to Clipboard Toggle word wrap

    3. Create a HttpClient configuration file. For example: 

      # vi HttpClient.revoke.agentSigned.cfg
      Copy to Clipboard Toggle word wrap 
      ### CA server host name.
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
      Copy to Clipboard Toggle word wrap

    4. Submit the request using the HttpClient command: 

      # HttpClient HttpClient.revoke.agentSigned.cfg

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

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.resp
      Copy to Clipboard Toggle word wrap

    5. Process the CMC Response: 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.revoke.agentSigned.resp

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
  OID: {1 3 6 1 5 5 7 7 25}
  BodyList: 1
  Status: SUCCESS
      Copy to Clipboard Toggle word wrap

Verification

  1. Verify in the CA signed audit log, for example /var/log/pki/rhcs10-RSA-SubCA/ca/signedAudit/ca_audit, that the user2 certificate indeed got revoked.

  2. Wait until the next CRL autoupdate (update interval in minutes configured by the ca.crl.MasterCRL.autoUpdateInterval of the SubCA’s CS.cfg file. By default, this is set to 240 minutes.)

    Note

    Alternatively, if you want to manually update the CRL immediately, login to the SubCA’s Agent UI in the browser, and:

    1. Select Update Revocation List and click Update.

    2. Click Update Directory Server and select:

      • Update the certificate revocation list to the directory
      • Update Certificate Manager certificate to the directory
    3. Click Update Directory.

    Once the ldapStore refresh completes, observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-subca/ocsp/logs/debug.

  3. Verify with the OCSPCLient tool that the certificate of user2 has been revoked, using its serial number in decimal (with -c pointing to the nickname of the signing CA): 

    # OCSPClient -v -d /root/.dogtag/pki_rsa_bootstrap/certs_db -h rhcs10.example.com -p 32080 -c "CA Signing Cert - rhcs10-RSA-SubCA" --serial 245832201

Initializing security database
Creating request for serial number 245832201
Submitting OCSP request
URL: http://rhcs10.example.com:32080/ocsp/ee/ocsp
Request Length: 71
Request: MEUwQzBBMD8wPTAJBgUrDgMCGgUABBRA+gjEGo4W0lUiC/Ve/oO8CrXQLQQUK4Bf
o2u6SW0p6q58dlNCXxOVw30CBA7kEiA=

Response Length: 3563
Response: <blob>
CertID.serialNumber=245832201
CertStatus=Revoked
    Copy to Clipboard Toggle word wrap

Set ocsp.store.ldapStore.refreshInSec0 back to the desired value

Previously, we set ocsp.store.ldapStore.refreshInSec0=120 to allow for quicker CRL refresh (2 minutes) for testing purposes.

  • Please change the value in the OCSP’s CS.cfg to your desired value (in seconds), update the debug level back to 10 and restart the OCSP.

7.8. Create and configure the SubCA (Part II)
Copiar o link

This section continues the SubCA installation, with the assumption that you have installed an OCSP instance. This is so that the role user certificates and the TLS server certificate of the SubCA will bear AIA extensions pointing to the OCSP instance.

7.8.1. Issue a non-bootstrap agent user certificate
Copiar o link

In this section, we are going to use the SubCA’s bootstrap admin certificate to issue a certificate, rsa_SubCA_AgentV (for agent user jsmith), that is limited to PKI agent role privileges. This certificate can then be used for approving any future CMC certificate requests.

Prerequisite

  • You are logged in to rhcs10.example.com as root user.

Create an agent certificate for a pki agent user

  1. Follow the procedure as described in Section 7.12.3, “Agent users” to get an agent certificate (in this example, rsa_SubCA_AgentV) issued for a pki agent user (e.g. jsmith). NOTE: As explained at the beginning of that part, if you are simply testing/evaluating the product, for convenience, instead of using a non-root user (e.g. jsmith), you could generate the CSR for rsa_SubCA_AgentV in the same certificate database as that of the bootstrap user (/root/.dogtag/pki_rsa_bootstrap/certs_db) as root, and further import the certificate into the same certdb to use. In case you select to do that, substitute the user/certs_db accordingly in the instructions that follow.

Verification:

  1. Show the status of the installed SubCA: 

    # pki-server status rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

    Note down the Secure Agent, Admin and pkiconsole URLs.

  2. Perform a sanity test to verify the new SubCA Admin certificate was added successfully:

    1. First, find the serial number of the user1 certificate created in Section 7.7.7.4, “Testing CRL publishing”: 

      # pki -p 31443 -h rhcs10.example.com ca-cert-find --uid user1
      Copy to Clipboard Toggle word wrap

    2. Place a hold on user1’s certificate using the SubCA Agent’s credentials: 

      # pki -d /home/jsmith/certs_db -n rsa_SubCA_AgentV -p 31443 -h rhcs10.example.com ca-cert-hold <user1 serial number>
      Copy to Clipboard Toggle word wrap
  3. Make sure the SubCA’s EE page is accessible on rhcs10.example.com.

7.8.2. Replace the temporary DS certificate (SubCA)
Copiar o link

Once the SubCA installation is complete, it can issue an official SSL server certificate for the Directory Server to replace the temporary one. Create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA using the SubCA agent user (rsa_SubCA_AgentV) credentials.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-SubCA-LDAP stop
    Copy to Clipboard Toggle word wrap

  2. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/Server-Cert-subca.csr -z /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-subca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/Server-Cert-subca.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

  3. Start DS: 

    # dsctl slapd-CC-RSA-SubCA-LDAP start
    Copy to Clipboard Toggle word wrap

  4. Remote copy the Server-Cert-subca.csr file to the system where the CA resides. For example: 

    # scp /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/Server-Cert-subca.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-subca.csr
    Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-subca.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-subca.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCertWithCRLDP
      Copy to Clipboard Toggle word wrap
      Note

      For EC certificates, use the ECC profiles by setting: 

      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECserverCertWithCRLDP
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-subca.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response:

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.resp -v

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:
    Certificate:
        Data:
            Version:  v3
            Serial Number: 0xA383694
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-SubCA
            Validity:
                Not Before: Tuesday, April 5, 2022 8:41:36 AM EDT America/New_York
                Not  After: Monday, March 25, 2024 8:41:36 AM EDT America/New_York
            Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x5C8FAD4
            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: Tuesday, April 5, 2022 8:36:21 AM EDT America/New_York
                Not  After: Saturday, April 5, 2042 8:36:21 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x80296C3
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-SubCA
            Validity:
                Not Before: Tuesday, April 5, 2022 8:39:43 AM EDT America/New_York
                Not  After: Friday, April 5, 2041 8:39:43 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-subca.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-subca.pem is the new Server-Cert certificate of the Directory Server instance that serves as the internaldb of the SubCA.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-subca.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Stop the SubCA’s LDAP instance: 

    # dsctl slapd-CC-RSA-SubCA-LDAP stop
    Copy to Clipboard Toggle word wrap

  2. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-SubCA-LDAP/
    Copy to Clipboard Toggle word wrap

  3. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  4. Import the newly created DS certificate and the CA certificates in its chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-SubCA" -i /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/Server-Cert-subca.pem
    Copy to Clipboard Toggle word wrap

  5. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/

Certificate Nickname                         Trust Attributes
                                             SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA          CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA           CT,C,C
Server-Cert                                  u,u,u
    Copy to Clipboard Toggle word wrap

  6. Start DS: 

    # dsctl slapd-CC-RSA-SubCA-LDAP start
    Copy to Clipboard Toggle word wrap

  7. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:7636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:7636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

Remove the trust for the temporary DS certificate for the SubCA instance

On rhcs10.example.com, remove the temporary DS certificate from the SubCA instance database:

  1. Stop the SubCA: 

    # pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

  2. List the certificate: 

    # certutil -L -d /var/lib/pki/rhcs10-RSA-SubCA/alias/

Certificate Nickname                    Trust Attributes
                                        SSL,S/MIME,JAR/XPI
DS temp CA certificate                  CT,C,C
...
    Copy to Clipboard Toggle word wrap

  3. Remove the temporary certificate from the nssdb: 

    # certutil -D -d /var/lib/pki/rhcs10-RSA-SubCA/alias/ -n "DS temp CA certificate"
    Copy to Clipboard Toggle word wrap

Enable certificate revocation checks

Now that the Directory Server certificate has been replaced, we can see the CRL Distribution Point being detected during startup of the CA by enabling certificate revocation checks:

  1. To enable certificate revocation checks, in the respective /var/lib/pki/rhcs10-RSA-SubCA/conf/server.xml file:

    1. Set enableOCSP or enableRevocationCheck to true: 

      enableOCSP=true
or
enableRevocationCheck=true
      Copy to Clipboard Toggle word wrap

    2. Additionally, remove these two parameters and their assigned values: 

      ocspResponderURL
ocspResponderCertNickname
      Copy to Clipboard Toggle word wrap

  2. Disable the legacy revocation check method by editing the CA’s CS.cfg file and setting the following to false: 

    auths.revocationChecking.enabled=false
    Copy to Clipboard Toggle word wrap

  3. Start the SubCA instance: 

    # pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

Verifying the CRL Distribution Point

Now that we have replaced the server-cert of the subordinate CA’s directory server using the profile caCMCserverCertWithCRLDP, this effectively triggers the CRL distribution point to be referenced by the CA during startup when initiating a connection with its internal directory server.

This section provides a rudimentary method to verify the CRL Distribution Point setup in the CA (see Section 7.6.6, “Configure support for CRL Distribution Point”):

  1. Check the publishing of the file-based CRL: 

    #  ls -l /var/lib/pki/rhcs10-RSA-SubCA/crl
total 4
-rw-r--r--. 1 pkiuser pkiuser 573 Jun 21 18:43 ServerCertCRL-20240621-175339.der
lrwxrwxrwx. 1 pkiuser pkiuser  67 Jun 21 18:43 ServerCertCRL.crl -> /var/lib/pki/rhcs10-RSA-SubCA/crl/ServerCertCRL-20240621-175339.der
    Copy to Clipboard Toggle word wrap

  2. Display and verify the content of the CRL 

    # BtoA /var/lib/pki/rhcs10-RSA-SubCA/crl/ServerCertCRL.crl /var/lib/pki/rhcs10-RSA-SubCA/crl/ServerCertCRL.bin
# PrettyPrintCrl /var/lib/pki/rhcs10-RSA-SubCA/crl/ServerCertCRL.bin
    Certificate Revocation List:
        Data:
            Version:  v2
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA
            This Update: Friday, June 21, 2024 5:53:39 PM EDT America/New_York
            Next Update: Friday, June 21, 2024 9:00:00 PM EDT America/New_York
            Revoked Certificates:
        Extensions:
            Identifier: CRL Number - 2.5.29.20
                Critical: no
                Number: 4
        Signature:
            Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Signature:
                9E:8A:E1:38:C4:B8:EF:E0:34:2A:92:2D:96:F2:7C:DF:
                71:F8:4E:8E:EF:AD:C1:CA:65:86:BD:27:45:1C:7E:DD:
                32:E6:16:94:83:E9:83:3F:24:1F:A1:89:74:7E:70:B6:
                04:20:36:7F:45:9C:A9:6C:7D:63:37:A3:9F:FD:F2:E1:
                CE:64:FA:D8:75:82:09:42:AB:B6:83:73:40:1A:C7:98:
                53:BC:65:81:3C:C3:71:D2:12:F9:A6:EA:00:80:B7:D8:
                A9:56:37:CD:CF:B9:59:64:B1:7F:31:39:16:11:1C:DC:
                93:64:87:F9:97:CC:EF:58:23:92:77:FC:2E:22:3A:57:
                AA:D7:7B:D1:1E:2B:3F:AE:FF:17:1A:62:C4:0C:A0:1E:
                0D:68:00:C4:68:4C:B5:27:4D:4B:DB:33:17:AC:8C:DF:
                8D:FE:77:EE:B9:B1:17:55:8F:42:A2:5C:84:1B:6F:B8:
                82:A6:F6:6E:E9:10:37:50:94:C4:33:D3:3C:18:22:7C:
                D6:6E:5E:89:34:E1:55:F5:80:F6:8F:B9:49:AE:A0:86:
                2E:B5:8A:B1:00:8C:B0:4C:81:37:A6:BA:D1:7D:77:81:
                F3:68:6C:16:D6:0A:BA:E7:F6:65:4F:44:A1:5B:31:0F:
                C2:F7:F9:FE:DC:55:BA:38:F2:AE:AA:34:9E:D0:7D:64:
                E1:90:68:E2:68:DE:C9:D0:90:26:56:6B:3A:74:AF:E8:
                CA:55:AE:E8:A1:DF:81:D1:E4:C8:46:DD:E3:12:6D:46:
                BE:A5:F2:C4:12:4E:15:D5:0F:30:10:3D:77:62:A2:41:
                F6:85:77:6F:EF:5C:78:0C:FE:F1:C5:4B:C5:C4:69:B5:
                84:0A:7B:4B:E3:D7:39:9A:66:43:AB:E9:DD:25:8E:EA:
                58:2F:AD:1D:D4:CD:1A:EE:50:73:B2:0C:F1:29:67:B3:
                2D:49:E1:54:95:51:9A:36:82:C3:D2:3F:32:7E:73:20:
                86:0F:28:6F:CC:89:9F:DF:4A:A9:64:CD:30:4A:80:EE
    Copy to Clipboard Toggle word wrap
Important

Do not remove the CRL file (soft link file ServerCertCRL.crl, and its associated der file).

If you encounter a situation where the CRL file is missing or has been accidentally deleted from /var/lib/pki/rhcs10-RSA-SubCA/crl/, preventing the CA from starting, follow the steps below to regenerate the CRL file:

  1. Stop the CA service. 

    # pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap
  2. Set the enableRevocationCheck or enableOCSP parameter to false (if it is currently set to true) in CA’s server.xml.
  3. Set the ca.crl.ServerCertCRL.publishOnStart= parameter to true in CA’s CS.cfg.

  4. Start the CA service to regenerate the missing CRL file: 

    # pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap
  5. After the CRL file has been recovered, stop the CA service once again.
  6. Revert the ca.crl.ServerCertCRL.publishOnStart= parameter to false in CA’s CS.cfg.
  7. Set the enableRevocationCheck or enableOCSP parameter to true in CA’s server.xml.
  8. Start the CA service again to apply the changes.

By following these steps, you will successfully recover the missing CRL file and ensure the CA can start correctly.

Verifying that the CA is functioning

  1. List the certificates in the CA: 

    # pki -p 31443 ca-cert-find
    Copy to Clipboard Toggle word wrap

  2. As the bootstrap admin user, list the users in the SubCA: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 -n "PKI Bootstrap Administrator for RSA-SubCA" ca-user-find
    Copy to Clipboard Toggle word wrap

7.8.3. Increase the SubCA pkiconsole timeout
Copiar o link

On rhcs10.example.com:

  1. Stop the SubCA: 

    # pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

  2. Edit /var/lib/pki/rhcs10-RSA-SubCA/conf/server.xml to increase the timeout period: 

    <Connector name="Secure" port="31443" …
connectionTimeout="3000000"
    Copy to Clipboard Toggle word wrap

  3. Start the SubCA: 

    # pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

7.8.4. Setting up CMC Shared Secret Authentication
Copiar o link

CMC Shared Secret Authentication allows to preauthorize users for certificate issuance without manual interaction from an agent. The configuration requires the following:

  • Information in the CA’s CS.cfg to specify which LDAP to use for such authentication
  • Enablement of the authentication method
  • Creation of the Issuance Protection Certificate which serves the mechanism to secure the shared secret
NOTE

The CMC SharedToken feature requires AES key wrapping/unwrapping on the CA side using OAEP. If the HSM that is used by the CA does not support the algorithm, and CMC Shared Token is a feature that you wish to employ, it is advised that you set up it up so that the key wrapping/unwrapping will take place in the internal crypto token (nssdb). In such a case, please note three differences in Section 7.8.4.2, “Add an issuance protection certificate”:

  • Generate a CSR for the Issuance Protection Certificate in the nssdb: 

    # PKCS10Client -d /var/lib/pki/rhcs10-RSA-SubCA/alias -a rsa -l 2048 -n "CN=IssuanceProtectionSystemCert" -w -o /root/.dogtag/pki_rsa_bootstrap/certs_db/IssuanceProtectionSystemCert.csr
    Copy to Clipboard Toggle word wrap

  • Import the Issuance Protection Certificate into the nssdb: 

    # certutil -A -d /var/lib/pki/rhcs10-RSA-SubCA/alias -i /root/.dogtag/pki_rsa_bootstrap/IssuanceProtectionSystemCert.pem -n "IssuanceProtectionSystemCert" -t ""
    Copy to Clipboard Toggle word wrap
  • When instructed to edit CS.cfg to set the nickname for the Issuance Protection Certificate: ca.cert.issuance_protection.nickname=IssuanceProtectionSystemCert

7.8.4.1. Setup the CMC Shared Token
Copiar o link

This section describes the configuration for CMC Shared Token authentication, specific to LDAP and profile enablement.

Procedure

On rhcs10.example.com:

  1. Stop the SubCA: 

    # pki-server stop rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

  2. Optional step: To add the shrTok attribute to LDAP, use the ldapmodify command and enter the required information at each interactive > prompt. For example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapmodify -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:7636 -w SECret.123 << EOF

> dn: cn=schema
> changetype: modify
> add: attributetypes
> attributetypes: ( 2.16.840.1.117370.3.1.123 NAME 'shrTok' DESC 'User Defined ObjectClass for SharedToken' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE X-ORIGIN 'custom for sharedToken')
> EOF

modifying entry "cn=schema"
    Copy to Clipboard Toggle word wrap

  3. Add the SharedToken authentication plugin by editing /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg to set the following properties: 

    auths.instance.SharedToken.ldap.basedn=dc=example,dc=com
auths.instance.SharedToken.ldap.ldapauth.authtype=BasicAuth
auths.instance.SharedToken.ldap.ldapauth.bindDN=cn=Directory Manager
auths.instance.SharedToken.ldap.ldapauth.bindPWPrompt=Rule SharedToken
auths.instance.SharedToken.ldap.ldapconn.host=rhds11.example.com
auths.instance.SharedToken.ldap.ldapconn.port=7636
auths.instance.SharedToken.ldap.ldapconn.secureConn=true
auths.instance.SharedToken.pluginName=SharedToken
auths.instance.SharedToken.shrTokAttr=shrTok
    Copy to Clipboard Toggle word wrap

  4. Configure the SubCA to use the HSM for CMC key wrapping:

    1. Edit /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg and set: cmc.token=NHSM-CONN-XC
    2. Also add the following entry: keyWrap.useOAEP=true

  5. Enable the CMC shared token enrollment profile for self-signed enrollment by configuring as follows:

    1. Make sure the enrollment profile caFullCMCSharedTokenCert.cfg is enabled (enable=true). For example: 

      # cat /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caFullCMCSharedTokenCert.cfg | grep enable=

enable=true
      Copy to Clipboard Toggle word wrap
    2. In case this shows enable=false, change to enable=true by editing caFullCMCSharedTokenCert.cfg.

  6. Start the SubCA to apply the changes: 

    # pki-server start rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

7.8.4.2. Add an issuance protection certificate
Copiar o link

CMC Shared Token Authentication requires additional setup, namely generating an Issuance Protection Certificate to import into the CA.

Note

The Issuance Protection Certificate must be an RSA certificate.

Generate a certificate request for the Issuance Protection certificate

  1. Login on rhcs10.example.com as root.

  2. Use the PKCS10Client tool to generate a PKCS10 certificate request: 

    # echo "<YourHSMpassword>" > /root/.dogtag/pki_rsa_bootstrap/certs_db/hsm_pass.txt
    Copy to Clipboard Toggle word wrap 
    # PKCS10Client -d /var/lib/pki/rhcs10-RSA-SubCA/alias -h NHSM-CONN-XC -P /root/.dogtag/pki_rsa_bootstrap/certs_db/hsm_pass.txt -a rsa -l 2048 -n "CN=IssuanceProtectionSystemCert" -w -o /root/.dogtag/pki_rsa_bootstrap/certs_db/IssuanceProtectionSystemCert.csr

CryptoUtil: generateRSAKeyPair: calling kg.setKeyPairUsages
PKCS10Client: Certificate request written into /root/.dogtag/pki_rsa_bootstrap/certs_db/IssuanceProtectionSystemCert.csr
PKCS10Client: PKCS#10 request key id written into /root/.dogtag/pki_rsa_bootstrap/certs_db/IssuanceProtectionSystemCert.csr.keyId
    Copy to Clipboard Toggle word wrap

  3. Send the resulting certificate request, /root/.dogtag/pki_rsa_bootstrap/certs_db/IssuanceProtectionSystemCert.csr, to a pki agent (e.g. jsmith).

    Note

    At the beginning of this section, in Section 7.8.1, “Issue a non-bootstrap agent user certificate”, in case you decided to import the SubCA Agent’s certificate into /root/.dogtag/pki_rsa_bootstrap/certs_db/ for convenience, instead of jsmith’s nssdb, you can skip this step and perform the below steps as the root user.

Issue the Issuance Protection Certificate

  1. Verify that rsa_SubCA_AgentV has the correct certificate. The following two commands should result in the same certificate: 

    # certutil -L -d /home/jsmith/certs_db -n "rsa_SubCA_AgentV" -a
    Copy to Clipboard Toggle word wrap 
    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-cert-show rsa_SubCA_AgentV <Cert ID> --encoded
    Copy to Clipboard Toggle word wrap
    NOTE

    You can obtain the Cert ID with the following command: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-cert-find rsa_SubCA_AgentV
    Copy to Clipboard Toggle word wrap
  2. Login on rhcs10.example.com as jsmith
  3. Place the certificate request file received, IssuanceProtectionSystemCert.csr, in the agent’s own directory, e.g. /home/jsmith/certs_db.

  4. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vi /home/jsmith/certs_db/cmc_IssuanceProtectionSystemCert_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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/jsmith/certs_db/IssuanceProtectionSystemCert.csr

### output: full path for the CMC request in binary format
output=/home/jsmith/certs_db/IssuanceProtectionSystemCert.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=rsa_SubCA_AgentV

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/jsmith/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /home/jsmith/certs_db/cmc_IssuanceProtectionSystemCert_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: CA agentV
createPKIData: begins
k=0
createPKIData:  format: pkcs10
PKCS10: PKCS10: begins
PKCS10: PKCS10: ends
selfSign is false...
signData: begins:
getPrivateKey: got signing cert
signData:  got signer privKey
createSignedData: begins
getSigningAlgFromPrivate: begins.
getSigningAlgFromPrivate: found signingKeyType=EC
getSigningAlgFromPrivate: using SignatureAlgorithm: ECSignatureWithSHA512Digest
createSignedData: digest created for pkidata
createSignedData: digest algorithm =ECSignatureWithSHA512Digest
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/jsmith/certs_db/IssuanceProtectionSystemCert.req
      Copy to Clipboard Toggle word wrap

  5. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vi /home/jsmith/certs_db/HttpClient_IssuanceProtectionSystemCert.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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/jsmith/certs_db/IssuanceProtectionSystemCert.req

### output: full path for the response in binary format
output=/home/jsmith/certs_db/IssuanceProtectionSystemCert.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/home/jsmith/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=rsa_SubCA_AgentV

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaIssuanceProtectionCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /home/jsmith/certs_db/HttpClient_IssuanceProtectionSystemCert.cfg

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

. . . Output omitted . . .

The response in binary format is stored in
/home/jsmith/certs_db/IssuanceProtectionSystemCert.resp
      Copy to Clipboard Toggle word wrap

  6. Get the CMC Response : 

    # CMCResponse -d /home/jsmith/certs_db -i /home/jsmith/certs_db/IssuanceProtectionSystemCert.resp -o /home/jsmith/certs_db/IssuanceProtectionSystemCert.crt

Certificates:
    Certificate:
    Data:
    Version:  v3
    Serial Number: 0x37C05EC
    Signature Algorithm: SHA512withRSA - 1.2.840.10045.4.3.2

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
   OID: {1 3 6 1 5 5 7 7 25}
   BodyList: 1
   Status: SUCCESS
PKCS#7 now stored in file: /home/jsmith/certs_db/IssuanceProtectionSystemCert.crt
    Copy to Clipboard Toggle word wrap

    Note down the serial number. It should match the same serial number shown when running the following command: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -p 31443 -n "PKI Bootstrap Administrator for RSA-SubCA" ca-cert-find --name "IssuanceProtectionSystemCert"
    Copy to Clipboard Toggle word wrap

  7. Import the Issuance Protection Certificate into the agent nssdb for handling passphrase wrapping in the case of CMC SharedSecret enrollment: 

    # pki -d /home/jsmith/certs_db -c SECret.123 -n "IssuanceProtectionSystemCert" client-cert-import --cert /home/jsmith/certs_db/IssuanceProtectionSystemCert.crt --trust ",,"
    Copy to Clipboard Toggle word wrap

Import the Issuance Protection Certificate into the CA

  1. Login on rhcs10.example.com as the root user that requested the certificate.

  2. Import the Issuance Protection Certificate: 

    # pki -p 31443 ca-cert-export <issuance protection cert ID> --output-file /root/.dogtag/pki_rsa_bootstrap/IssuanceProtectionSystemCert.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -A -d /var/lib/pki/rhcs10-RSA-SubCA/alias -h NHSM-CONN-XC -P NHSM-CONN-XC -i /root/.dogtag/pki_rsa_bootstrap/IssuanceProtectionSystemCert.pem -n "IssuanceProtectionSystemCert" -t "" -f /root/.dogtag/pki_rsa_bootstrap/certs_db/hsm_pass.txt

certutil: could not change trust on certificate: SEC_ERROR_TOKEN_NOT_LOGGED_IN: The operation failed because the PKCS#11 token is not logged in.
    Copy to Clipboard Toggle word wrap
    Note

    Ignore this error message (BZ#1393668). 

    #  certutil -L -d /var/lib/pki/rhcs10-RSA-SubCA/alias -h NHSM-CONN-XC f /root/.dogtag/pki_rsa_bootstrap/certs_db/hsm_pass.txt

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI

Enter Password or Pin for NHSM-CONN-XC":
NHSM-CONN-XC:IssuanceProtectionSystemCert       u,u,u
...
    Copy to Clipboard Toggle word wrap

  3. Configure the SubCA to use the newly created IssuanceProtectionSystemCert:

    1. Stop the SubCA: 

      # pki-server stop rhcs10-RSA-SubCA
      Copy to Clipboard Toggle word wrap
    2. Edit /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg to set
      ca.cert.issuance_protection.nickname=NHSM-CONN-XC:IssuanceProtectionSystemCert

    3. Start the SubCA: 

      # pki-server start rhcs10-RSA-SubCA
      Copy to Clipboard Toggle word wrap

7.8.4.3. Test the CMC Shared Token
Copiar o link

The following test procedure consists in issuing a user certificate using CMC Shared Token authentication with issuance protection.

Set up a Shared Secret for a user

As a Directory Manager, create a CMC Shared Token for an LDAP user.

  1. Create a regular OS user, e.g. FooUser123: 

    # /usr/sbin/useradd -d /home/FooUser123 -s /bin/bash -c "FooUser123" -m FooUser123
    Copy to Clipboard Toggle word wrap

  2. Add a user in LDAP. For example, for the FooUser123 user, create the /root/.dogtag/pki_rsa_bootstrap/certs_db/ldap_cc_rsa_user.ldif file to use with the ldapadd command: 

    dn: uid=FooUser123,dc=example,dc=com
objectClass: extensibleobject
objectclass: inetorgperson
objectclass: organizationalPerson
objectClass: person
objectClass: top
sn: FooUser123
uid: FooUser123
cn: CA FooUser123
mail: FooUser123@example.com
givenName: FooUser123
userPassword: secret
shrTok:
    Copy to Clipboard Toggle word wrap 
    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapadd -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:7636 -w SECret.123 -f /root/.dogtag/pki_rsa_bootstrap/certs_db/ldap_cc_rsa_user.ldif

adding new entry "uid=FooUser123,dc=example,dc=com"
    Copy to Clipboard Toggle word wrap

  3. Generate the shrTok entry for the user. In the following CMCSharedToken command:

    • The -s parameter specifies the shared secret (e.g. secretShrTokFooUser123), which is to be shared with the regular user that is going to perform the self-signed CMC enrollment.

    • The -n parameter specifies the nickname of the issuance protection certificate. 

      # CMCSharedToken -d /home/jsmith/certs_db -p SECret.123 -s secretShrTokFooUser123 -o /root/.dogtag/pki_rsa_bootstrap/cmcSharedTok_FooUser123.b64 -n "IssuanceProtectionSystemCert" --oaep

Encrypted Secret Data:
MIIBJgSCAQBRCvkCYlEm/6ntzKyQ+FUTbj6KrIfCPW8h9mehkmIDgAtp5vvEzkVNaOz2FZiESE6nXJlQbjODVGuN7XN5F+qORSWFVW1ifnumCw+czeO7OHIenEQ3C7XTwnX77RWoxZECv2tfn818TGR3+YLSJXl8LbSX5qDXv8ydpHAi+GJdtpllnbndA5d8XEKmwg0zRPGsMjJ9t40DA1WEqjVTxxShk4QgxgZxcOYutfj1dtEtMrwcyo9+FRO9MMg4iAWigvAVsMfZphBKCQNAoth+Cv7BZiI45Xtlt6RXQ+x6zgabBwrqn2LIvQ2FBwMhDr+IdDrZdZGAlpci9Q8TUN1Km4A+BCAyc0BksAUX9qX8ylyrrfxaijk3AZyfdnCi6nTXLE+N3A==

Storing Base64 secret data into /root/.dogtag/pki_rsa_bootstrap/cmcSharedTok_FooUser123.b64
      Copy to Clipboard Toggle word wrap

  4. Add the above CMCSharedToken encrypted passphrase secret data to the shrTok attribute of the LDAP user. For example, create the /root/.dogtag/pki_rsa_bootstrap/certs_db/ldap_cc_rsa_user_shrtok.ldif file as follows to use with the ldapmodify command: 

    dn: uid=FooUser123,dc=example,dc=com
changetype: modify
replace: shrTok
shrTok: MIIBJgSCAQBRCvkCYlEm/6ntzKyQ+FUTbj6KrIfCPW8h9mehkmIDgAtp5vvEzkVNaOz2FZiESE6nXJlQbjODVGuN7XN5F+qORSWFVW1ifnumCw+czeO7OHIenEQ3C7XTwnX7RWoxZECv2tfn818TGR3+YLSJXl8LbSX5qDXv8ydpHAi+GJdtpllnbndA5d8XEKmwg0zRGsMjJ9t40DA1WEqjVTxxShk4QgxgZxcOYutfj1dtEtMrwcyo9+FRO9MMg4iAWigvAVsMfZphBKCQNAoth+Cv7BZiI45Xtlt6RXQ+x6zgabBwrqn2LIvQ2FBwMhDr+IdDrZdZGAlpci9Q8UN1Km4A+BCAyc0BksAUX9qX8ylyrrfxaijk3AZyfdnCi6nTXLE+N3A==
    Copy to Clipboard Toggle word wrap 
    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapmodify -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:7636 -w SECret.123 -f /root/.dogtag/pki_rsa_bootstrap/certs_db/ldap_cc_rsa_user_shrtok.ldif
    Copy to Clipboard Toggle word wrap
    Note

    Make sure the shrTok value is on the same single line in the .ldif file, with a single space between "shrTok:" and the value itself.

Test procedure

As the test user FooUser123,

  1. Create a client nssdb if it does not already exist: 

    $ pki -d /home/FooUser123/certs_db -c SECret.123 client-init
    Copy to Clipboard Toggle word wrap

  2. Import the CA trust chain into the nssdb: 

    $ pki -d /home/FooUser123/certs_db -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-RootCA" --ca-cert /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    $ pki -d /home/FooUser123/certs_db -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-SubCA" --ca-cert /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap

  3. List the contents of the nssdb: 

    # certutil -d /home/FooUser123/certs_db/ -L
    Copy to Clipboard Toggle word wrap 
    Certificate Nickname                    Trust Attributes
                                        SSL,S/MIME,JAR/XPI

CA Signing Cert - rhcs10-RSA-RootCA     CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA      CT,C,C
    Copy to Clipboard Toggle word wrap

  4. Create a PKCS#10 request. The resulting request and private key id are to be used in the CMCRequest file in the next step: 

    $ PKCS10Client -d /home/FooUser123/certs_db -p SECret.123 -y true -n "cn=FooUser123, uid=FooUser123, ou=self-signed" -o /home/FooUser123/certs_db/pkcs10.self.req
    Copy to Clipboard Toggle word wrap

  5. Display the private key ID to have it available for the next step: 

    # cat /home/FooUser123/certs_db/pkcs10.self.req.keyId; echo
    Copy to Clipboard Toggle word wrap

  6. Generate a CMC request:

    1. Create a CMCRequest configuration file, using the PKCS#10 request and private key id you obtained from the previous step. For example: 

      $ vi /home/FooUser123/certs_db/cmc-p10-self.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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/FooUser123/certs_db/pkcs10.self.req

### output: full path for the CMC request in binary format
output=/home/FooUser123/certs_db/cmc.pkcs10.self.req

### 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.
#nickname=

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/FooUser123/certs_db

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

### format: request format, either pkcs10 or crmf
format=pkcs10

### 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
witness.sharedSecret=secretShrTokFooUser123

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=FooUser123
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      $ CMCRequest /home/FooUser123/certs_db/cmc-p10-self.cfg

cert/key prefix =
path = /home/FooUser123/certs_db
CryptoManger initialized
token internal logged in...
got request privKeyId: 2e560e1974669b79b0b71eb096cfe90a2b3db370
got private key

. . . Output omitted . . .

identification control: identification =FooUser123
Successfully create identification control. bpid = 1

CMCRequest: addIdentityProofV2Attr: hashAlg=SHA-512; macAlg=SHA-256-HMAC
Identity Proof V2 control:
 Value: 44 -108 -21 24 76 -10 59 -56 28 -110 -114 -100 -70 40 48 80 24 69 -104 -13 -124 79 75 -42 -92 -29 -89 -27 -37 -107 -91 -82
Successfully create identityProofV2 control. bpid = 2

selfSign is true...
signData for selfSign: begins:
createSignedData: begins
getSigningAlgFromPrivate: begins.
getSigningAlgFromPrivate: found signingKeyType=RSA
getSigningAlgFromPrivate: using SignatureAlgorithm: RSASignatureWithSHA256Digest
createSignedData: digest created for pkidata
createSignedData: digest algorithm =RSASignatureWithSHA256Digest
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/FooUser123/certs_db/cmc.pkcs10.self.req
      Copy to Clipboard Toggle word wrap

  7. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      $ vim /home/FooUser123/certs_db/HttpClient-cmc-p10.self.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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/FooUser123/certs_db/cmc.pkcs10.self.req

### output: full path for the response in binary format
output=/home/FooUser123/certs_db/cmc.p10.self.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/home/FooUser123/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=false

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCSharedTokenCert
      Copy to Clipboard Toggle word wrap
      Note

      In case you require TLS mutual authentication for connections to CS, see Section 7.13.12, “Requiring TLS mutual authentication for connections to CS”.

    2. Submit the request using the HttpClient command: 

      # HttpClient /home/FooUser123/certs_db/HttpClient-cmc-p10.self.cfg

Total number of bytes read = 2966
after SSLSocket created, thread token is NSS FIPS 140-2 User Private Key
handshake happened
writing to socket
handshake happened
Total number of bytes read = 1714

. . . Output omitted . . .

The response in binary format is stored in /home/FooUser123/certs_db/cmc.p10.self.resp
      Copy to Clipboard Toggle word wrap

  8. Process the CMCResponse call: 

    $ CMCResponse -d /home/FooUser123/certs_db -i /home/FooUser123/certs_db/cmc.p10.self.resp

Certificates:
   Certificate:
      Data:
          Version:  v3
          Serial Number: 0x3D58D34
          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: Sunday, February 11, 2018 6:38:08 PM EST America/New_York
              Not  After: Friday, August 10, 2018 6:38:08 PM EDT America/New_York
          Subject: CN=FooUser123,UID=FooUser123

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
 OID: {1 3 6 1 5 5 7 7 25}
 BodyList: 1
 Status: SUCCESS
    Copy to Clipboard Toggle word wrap

7.8.5. Check for random serial numbers
Copiar o link

Make sure all the subsystem certificates have random serial numbers:

  • Visit the SubCA’s EE page and list the certificates to confirm they have random serial numbers.

  • Alternatively, you can check for random serial numbers using the following command: 

    # pki -p 31443 ca-cert-find | grep -i serial
    Copy to Clipboard Toggle word wrap

7.8.6. Create other SubCA role users
Copiar o link

We have previously created an agent role user and a certificate for rsa_SubCA_AgentV.

Else, you could create other single-role users for the admin and audit roles by following the steps in Section 7.12, “Create PKI role users”.

7.8.7. Login to the SubCA pkiconsole with client authentication
Copiar o link

  1. Configure the SubCA with sslclientauth and import the role user certificate as described in Section 7.13.6, “Configure pkiconsole login with client authentication”.

  2. Login to pkiconsole with the client authentication certificate of the role user: 

    # pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:31443/ca
    Copy to Clipboard Toggle word wrap

    And select the role user certificate nickname from the list, for example rsa_SubCA_AdminV. Login to the console should be successful.

7.8.8. Post-installation
Copiar o link

If you wish to install additional RHCS instances, please continue with the next relevant section. Once you have completed the installation of all of the RHCS instances you need, please go to Section 7.13, “Post-installation” to complete additional setup.

7.9. Create and configure the KRA instance
Copiar o link

This section describes installing and configuring a KRA instance against the SubCA. In this example, the KRA is installed on rhcs10.example.com, with its internal directory server on rhds11.example.com.

Note

Make sure that the file /opt/pki_rsa/ca-chain.pem contains the contains the complete CA certificate chain (SubCA and RootCA certificates): 

# ls -l /opt/pki_rsa/ca-chain.pem

# cat /opt/pki_rsa/ca-chain.pem
Copy to Clipboard Toggle word wrap

7.9.1. Replace the temporary DS certificate (KRA)
Copiar o link

Prior to installing the KRA, we are issuing an official SSL server certificate for the KRA’s Directory Server to replace the temporary bootstrap one. To do that, we first create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-KRA-LDAP stop
    Copy to Clipboard Toggle word wrap

  2. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.csr -z /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-kra.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

  3. Remote copy the Server-Cert-kra.csr file to the system where the CA resides. For example: 

    # scp /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.csr
    Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-kra.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-kra.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response:

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.resp -v

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:

  Certificate:
      Data:
          Version:  v3
          Serial Number: 0x34F6548
          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: Monday, September 25, 2023 8:28:24 PM EDT America/New_York
              Not  After: Sunday, September 14, 2025 8:28:24 PM EDT America/New_York
          Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x66AA3D5
            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: Friday, September 15, 2023 3:22:33 PM EDT America/New_York
                Not  After: Tuesday, September 15, 2043 3:22:33 PM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA


. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0xABA9C22
            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: Tuesday, September 19, 2023 3:55:59 PM EDT America/New_York
                Not  After: Friday, September 19, 2042 3:55:59 PM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA


. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-kra.pem is the new Server-Cert certificate of the Directory Server instance that serves as the internaldb of the KRA.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-KRA-LDAP/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-KRA-LDAP/
    Copy to Clipboard Toggle word wrap

  2. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  3. Import the newly created DS certificate and the CA certificates in its chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-SubCA" -i /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.pem
    Copy to Clipboard Toggle word wrap

  4. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/

Certificate Nickname                           Trust Attributes
                                               SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA            CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA             CT,C,C
Server-Cert                                    u,u,u
    Copy to Clipboard Toggle word wrap

  5. Start DS: 

    # dsctl slapd-CC-RSA-KRA-LDAP start
    Copy to Clipboard Toggle word wrap

  6. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:22636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:22636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

7.9.2. Install the KRA instance
Copiar o link

To install the KRA, use either the single-step method or the two-step method. The following procedure describes the single-step method. If you wish to install using the two-step method, please refer to ] as well as xref:_rootca_two_step[.

Important

BEFORE you install the KRA, if you intend the AIA extension to point to the external OCSP instance instead of the CA’s internal OCSP, make sure you first follow the steps under Section 7.7.4, “Set the default AIA extension to point to this OCSP”.

Prerequisites

Procedure

  1. Create a KRA installation file at a chosen location (e.g. /root/pki_rsa): 

    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # vi kra_inst.cfg
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation.

    The values specified in the installation file below are examples. In addition to changing the HSM password, edit the values accordingly, for example ports, directories, nicknames, domains…​ 

    [DEFAULT]
pki_instance_name=rhcs10-RSA-KRA
pki_https_port=28443
pki_http_port=28080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### CA cert chain concatenated in PEM format
pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-KRA/kra_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-KRA/certs_db
pki_client_database_password=SECret.123
pki_client_database_purge=False
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-KRA
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=22389
pki_ds_ldaps_port=22636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/ca-chain.pem
pki_ds_secure_connection_ca_nickname=CA Signing Cert - rhcs10-RSA-SubCA

### Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_https_port=31443
pki_security_domain_password=SECret.123
pki_security_domain_user=caadmin


[Tomcat]
pki_ajp_port=28009
pki_tomcat_server_port=28005

[KRA]
pki_import_admin_cert=False

pki_storage_token=NHSM-CONN-XC
pki_storage_key_algorithm=SHA256withRSA
pki_storage_key_size=2048
pki_storage_key_type=rsa
pki_storage_signing_algorithm=SHA256withRSA

pki_transport_token=NHSM-CONN-XC
pki_transport_key_algorithm=SHA256withRSA
pki_transport_key_size=2048
pki_transport_key_type=rsa
pki_transport_signing_algorithm=SHA256withRSA

pki_admin_nickname=PKI Bootstrap Administrator for RSA-KRA
pki_admin_name=kraadmin
pki_admin_uid=kraadmin
pki_admin_email=kraadmin@example.com

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-KRA
pki_ds_database=CC-RSA-KRA-LDAP
pki_share_db=False
    Copy to Clipboard Toggle word wrap

  2. Run the pkispawn tool to install the KRA subsystem: 

    # pkispawn -s KRA -f kra_inst.cfg --debug
    Copy to Clipboard Toggle word wrap

    This will create the KRA instance in /var/lib/pki/rhcs10-RSA-KRA.

Note

For ease of reference, if you wanted to install the KRA using the two-step method:

  1. First run the pkispawn tool with the --skip-configuration option to install the RHCS KRA instance: 

    # pkispawn -s KRA -f kra_inst.cfg --skip-configuration --debug
    Copy to Clipboard Toggle word wrap
  2. Customize the configuration files between the two installation steps

  3. Run the pkispawn tool to configure the KRA: 

    # pkispawn -s KRA -f kra_inst.cfg --skip-installation --debug
    Copy to Clipboard Toggle word wrap

Verification

  1. Show the status of the installed KRA instance: 

    # pki-server status rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

    Note down the Secure Agent, Admin and pkiconsole URLs.

  2. Verify that the KRA agent web page is accessible.

  3. Import the KRA bootstrap administrator certificate into the nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db client-cert-import --pkcs12 /opt/pki_rsa/rhcs10-RSA-KRA/kra_admin_cert.p12 --pkcs12-password SECret.123
    Copy to Clipboard Toggle word wrap

  4. Verify the sanity of the KRA by running the kra-key-request-find command. It should display certificates: 

    # pki -p 28443 -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n “PKI Bootstrap Administrator for RSA-KRA” kra-key-request-find
    Copy to Clipboard Toggle word wrap
Note

You can only perform the actual key archival and recovery tests after you complete the setup procedures detailed in the next subsections.

7.9.3. Configure OAEP support for the KRA
Copiar o link

Configuring the KRA to use the OAEP (Optimal Asymmetric Encryption Padding) key transport algorithm is done by editing the KRA’s CS.cfg configuration file.

Note

This section is for a HSM that supports AES key wrapping/unwrapping, such as an Entrust nShield Connect XC unit with firmware v12.72.1.

Prerequisite

  • You are logged onto rhcs10.example.com as root user.

Procedure

  1. Stop the KRA: 

    # pki-server stop rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap
  2. Edit the /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg configuration file and add the following three lines:

keyWrap.useOAEP=true
kra.legacyPKCS12=false
kra.nonLegacyAlg=AES/None/PKCS5Padding/Kwp/256

  1. Start the KRA: 

    # pki-server start rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

  2. Restart the SubCA: 

    # pki-server restart rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

7.9.4. Create KRA role users
Copiar o link

7.9.5. Test key archival
Copiar o link

This example demonstrates how a regular user without any pki role privilege could create a certificate enrollment request and have it automatically issued (= self-signed CMC enrollment), while having the private key archived by the KRA.

Important

Please make sure the SubCA is configured to handle self-signed CMC enrollment by following the instructions in ] and xref:_install_add-issuance-protection-certificate[

Prerequisite configuration

In case you have not done this previously, please follow the steps under Section 7.8.4.3, “Test the CMC Shared Token” to set up a shared secret for your test user (in this example, FooUser123).

Procedure

This procedure provides steps that the regular (non-pki-role) user (e.g. FooUser123) is to perform in order to conduct self-signed CMC certificate enrollment for themselves. This can be done in any of FooUser123’s home directory, e.g. /home/FooUser123/certs_db.

  1. Create a client nssdb if it does not already exist: 

    $ pki -d /home/FooUser123/certs_db -c SECret.123 client-init
    Copy to Clipboard Toggle word wrap

  2. Create a CRMF request using the KRA transport certificate:

    1. Find the KRA transport certificate serial number in the SubCA’s EE page (in this example, 0x555251b).
      Alternatively, you can also find its serial number if you know the certificate’s common name, for example: 

      # pki -p 31443 ca-cert-find --name "DRM Transport Certificate"
---------------
1 entries found
---------------
 Serial Number: 0x555251b
 Subject DN: CN=DRM Transport Certificate,OU=rhcs10-RSA-KRA,O=Example-rhcs10-RSA-KRA
 Status: VALID
...
----------------------------
Number of entries returned 1
----------------------------
      Copy to Clipboard Toggle word wrap

    2. Export the KRA transport certificate using its serial number: 

      # pki -d /home/FooUser123/certs_db -c SECret.123 -p 31443 ca-cert-export 0x555251b --output-file /home/FooUser123/certs_db/kra_transport.txt
      Copy to Clipboard Toggle word wrap

    3. Create the CRMF request using the transport certificate: 

      # CRMFPopClient -d /home/FooUser123/certs_db -p SECret.123 -n "cn=FooUser123, uid=FooUser123" -q POP_SUCCESS -b /home/FooUser123/certs_db/kra_transport.txt -w "AES KeyWrap/Wrapped" -y -o /home/FooUser123/certs_db/crmf.req -oaep

CryptoUtil: generateRSAKeyPair: calling kg.setKeyPairUsages
Keypair private key id: 56906e65ef43a2e756908726758e9061d8d7ee9c
CRMFPopClient: use_shared_secret true. Generating SubjectKeyIdentifier extension.
Storing CRMF request into /home/FooUser123/certs_db/crmf.req
Storing CRMF request key id into /home/FooUser123/certs_db/crmf.req.keyId
      Copy to Clipboard Toggle word wrap

  3. Generate a CMC request:

    1. Create a CMCRequest configuration file, using the CRMF request and private key id you obtained from the previous step. For example: 

      # vi /home/FooUser123/certs_db/cmc-crmf-self.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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/FooUser123/certs_db/crmf.req

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

### 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.
#nickname=

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/FooUser123/certs_db

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

### format: request format, either pkcs10 or crmf
format=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
witness.sharedSecret=secretShrTokFooUser123

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=FooUser123
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /home/FooUser123/certs_db/cmc-crmf-self.cfg

cert/key prefix =
path = /home/FooUser123/certs_db
CryptoManger initialized
token internal logged in...
got request privKeyId: 56906e65ef43a2e756908726758e9061d8d7ee9c
got private key
createPKIData: begins
createPopLinkWitnessV2Attr: begins
createPopLinkWitnessV2Attr: keyGenAlg=SHA-256; macAlg=SHA-256-HMAC
createPopLinkWitnessV2Attr: Successfully created id_cmc_idPOPLinkRandom control. bpid = 1
createPopLinkWitnessV2Attr: Successfully created PopLinkWitnessV2 control.
createPopLinkWitnessV2Attr: returning...

k=0
createPKIData:  format: crmf
CryptoUtil: getSKIExtensionFromCertTemplate: SKIoid == jssOID
createPKIData:  SubjectKeyIdentifier extension found in use_shared_secret request
createPKIData: popLinkWitnessV2 enabled. reconstructing crmf
createNewPOP: begins
createNewPOP: about to create POPOSigningKey
createNewPOP: creating and returning newPopOfSigningKey
createPKIData: new CRMF b64encode completes.
-----BEGIN CERTIFICATE REQUEST-----
MIIIsDCCCKwwggeQAgEBMIIBfYABAqUzMDExGjAYBgoJkiaJk/IsZAEBEwpGb29Vc2VyMTIzMRMw

. . . Output omitted . . .

-----END CERTIFICATE REQUEST-----

identification control: identification =FooUser123
Successfully create identification control. bpid = 1

CMCRequest: addIdentityProofV2Attr: hashAlg=SHA-512; macAlg=SHA-256-HMAC
Identity Proof V2 control:
   Value: -50 -36 103 -38 70 85 70 91 -71 96 -121 100 -127 50 -63 -57 123 -30 115 58 -55 -34 -22 104 90 -20 48 46 80 -85 64 68
Successfully create identityProofV2 control. bpid = 2

useSharedSecret is true...
signData for useSharedSecret begins: begins:
createSignedData: begins
getSigningAlgFromPrivate: begins.
getSigningAlgFromPrivate: found signingKeyType=RSA
getSigningAlgFromPrivate: using SignatureAlgorithm: RSASignatureWithSHA256Digest
createSignedData: digest created for pkidata
createSignedData: digest algorithm =RSASignatureWithSHA256Digest
getCMCBlob: begins
getCMCBlob: generating signed data

The CMC enrollment request in base-64 encoded format:
MIILlAYJKoZIhvcNAQcCoIILhTCCC4ECAQMxDzANBglghkgBZQMEAgEFADCCCdgGCCsGAQUFBwwC

. . . Output omitted . . .

The CMC enrollment request in binary format is stored in /home/FooUser123/certs_db/cmc.self.req
      Copy to Clipboard Toggle word wrap

  4. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /home/FooUser123/certs_db/HttpClient-cmc-crmf.self.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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/FooUser123/certs_db/cmc.self.req

### output: full path for the response in binary format
output=/home/FooUser123/certs_db/cmc.self.Resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/home/FooUser123/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=false

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCSharedTokenCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /home/FooUser123/certs_db/HttpClient-cmc-crmf.self.cfg

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

#Response Headers begin
HTTP/1.1 200
Content-Type: application/pkcs7-mime
Content-Length: 4348
Date: Thu, 08 Sep 2022 20:51:44 GMT
Connection: close
#end

Total number of bytes read = 4348
MIIQ+AYJKoZIhvcNAQcCoIIQ6TCCEOUCAQMxDzANBglghkgBZQMEAgEFADAxBggrBgEFBQcMA6Al

. . . Output omitted . . .

The response in binary format is stored in /home/FooUser123/certs_db/cmc.self.Resp
      Copy to Clipboard Toggle word wrap

  5. Process the response using the CMCResponse command: 

    # CMCResponse -d /home/FooUser123/certs_db -i /home/FooUser123/certs_db/cmc.self.Resp

Certificates:
    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x98D0212
            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, September 8, 2022 4:51:44 PM EDT America/New_York
                Not  After: Tuesday, March 7, 2023 4:51:44 PM EST America/New_York
            Subject: UID=FooUser123,DC=example,DC=com
            Subject Public Key Info:
                Algorithm: RSA - 1.2.840.113549.1.1.1
                Public Key:
                    Exponent: 65537
                    Public Key Modulus: (2048 bits) :
                        BB:F3:C6:66:AC:9E:39:02:59:B8:E7:5A:6D:9E:29:8C:

. . . Output omitted . . .

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.
    Copy to Clipboard Toggle word wrap

Verification:

  • To verify the sanity of the KRA UI, access the KRA agent page and List the requests by selecting the request type Show key archival requests and the status Show completed requests. This should display the archived key information for CN=FooUser123, UID=FooUser123.

7.9.6. Test key recovery
Copiar o link

Test the key recovery process with the following steps:

  1. As a KRA agent, go to the KRA’s agent services page in the browser, and click the Recover Keys link.

  2. Tick the Certificate checkbox in order to search for the key by certificate:

    1. Parse the earlier response file to display the leaf certificate in base64 format, for example: 

      # CMCResponse -d /home/FooUser123/certs_db -i /home/FooUser123/certs_db/cmc.self.Resp -v
      Copy to Clipboard Toggle word wrap
    2. Copy and paste the base64-encoded leaf certificate into the text field (e.g. cert0: make sure that the "Subject" of the certificate has UID=FooUser123,DC=example,DC=com), validate with Show Key.

  3. Click Recover. Make sure that the Async Recovery checkbox is selected to allow the browser session to be closed while recovery is ongoing.

    Note

    Asynchronous recovery is the default way to perform a key recovery. Synchronous key recovery is no longer supported.

  4. Click Recover. Depending on the agent scheme, a specified number of agents must authorize this key recovery. Have the agents search for the key to recover and then to approve the initiated recovery.
  5. Once all the agents have authorized the recovery, select List Requests on the left side of the agent page, then select Request type show key recovery requests and Request status show all requests.
  6. Click the request number corresponding to the recovery request that was approved, enter the PKCS #12 password twice as requested, and click Retrieve PKCS#12.
  7. A dialog pops up. Click on Save File to download the PKCS #12 file for the owner of the private key certificate.

  8. After receiving the PKCS #12 file, the certificate/keys owner can then restore the key into their Firefox nssdb. For example: 

    # pk12util -d ~/.mozilla/firefox/’1234gggg.Default User’ -n "FooUser123 cert" -i getAsyncPk12
    Copy to Clipboard Toggle word wrap
  9. You can now use the certificate again.

7.9.7. Increase the KRA pkiconsole timeout
Copiar o link

  1. Stop the KRA: 

    # pki-server stop rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

  2. Increase the timeout period by editing the /var/lib/pki/rhcs10-RSA-KRA/conf/server.xml file: 

    <Connector name="Secure" port="28443" …
connectionTimeout="3000000"
    Copy to Clipboard Toggle word wrap

  3. Then restart the KRA: 

    # pki-server start rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

7.9.8. Login to the KRA pkiconsole with client authentication
Copiar o link

  1. Configure the KRA with authType=sslclientauth and import the role user certificate by following Section 7.13.6, “Configure pkiconsole login with client authentication”.

  2. Login to pkiconsole with the client auth certificate of the role user: 

    # pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:28443/kra
    Copy to Clipboard Toggle word wrap

    And select the role user certificate nickname from the list, for example KRA adminV. Login to the console should be successful.

7.9.9. Post-installation
Copiar o link

If you wish to install additional RHCS instances, please continue with the next relevant section. Once you have completed the installation of all of the RHCS instances you need, please go to Section 7.13, “Post-installation” to complete additional setup.

7.10. Create and configure the TKS instance
Copiar o link

This section describes installing and configuring a TKS instance against the SubCA .
The TKS system certificates will be issued by the SubCA, and the TKS will join the SubCA security domain.
In this example, the TKS is installed on rhcs10.example.com, with its internal directory server on rhds11.example.com.

Note

Make sure that the file /opt/pki_rsa/ca-chain.pem contains the complete CA certificate chain (SubCA and RootCA certificates): 

# ls -l /opt/pki_rsa/ca-chain.pem

# cat /opt/pki_rsa/ca-chain.pem
Copy to Clipboard Toggle word wrap

7.10.1. Replace the temporary DS certificate (TKS)
Copiar o link

Prior to installing the TKS, we are issuing an official SSL server certificate for the TKS' Directory Server to replace the temporary bootstrap one. To do that, we first create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-TKS-LDAP stop
    Copy to Clipboard Toggle word wrap

  2. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/Server-Cert-tks.csr -z /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-tks.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/Server-Cert-tks.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

  3. Remote copy the Server-Cert-tks.csr file to the system where the CA resides. For example: 

    # scp /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/Server-Cert-tks.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tks.csr
    Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tks.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tks.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tks.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response:

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.resp -v

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:

  Certificate:
      Data:
          Version:  v3
          Serial Number: 0xA383694
          Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
          Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-TKS,O=Example-rhcs10-RSA-TKS
          Validity:
              Not Before: Tuesday, April 5, 2022 8:41:36 AM EDT America/New_York
              Not  After: Monday, March 25, 2024 8:41:36 AM EDT America/New_York
          Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x5C8FAD4
            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: Tuesday, April 5, 2022 8:36:21 AM EDT America/New_York
                Not  After: Saturday, April 5, 2042 8:36:21 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x80296C3
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-TKS
            Validity:
                Not Before: Tuesday, April 5, 2022 8:39:43 AM EDT America/New_York
                Not  After: Friday, April 5, 2041 8:39:43 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-TKS,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tks.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-tks.pem is the new Server-Cert certificate of the Directory Server instance that serves as the internaldb of the TKS.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tks.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-TKS-LDAP/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-TKS-LDAP/
    Copy to Clipboard Toggle word wrap

  2. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  3. Import the newly created DS certificate and the CA certificates in its chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-SubCA" -i /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/Server-Cert-tks.pem
    Copy to Clipboard Toggle word wrap

  4. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/

Certificate Nickname                        Trust Attributes
                                            SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA         CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA          CT,C,C
Server-Cert                                 u,u,u
    Copy to Clipboard Toggle word wrap

  5. Start DS: 

    # dsctl slapd-CC-RSA-TKS-LDAP start
    Copy to Clipboard Toggle word wrap

  6. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:16636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:16636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

7.10.2. Install the TKS instance
Copiar o link

To install the TKS, use either the single-step method or the two-step method. The following procedure describes the single-step method. If you wish to install using the two-step method, please refer to ] as well as xref:_rootca_two_step[.

Important

BEFORE you install the TKS, if you intend the AIA extension to point to the external OCSP instance instead of the CA’s internal OCSP, make sure you first follow the steps under Section 7.7.4, “Set the default AIA extension to point to this OCSP”.

Prerequisites

Procedure

  1. Create a TKS installation file at a chosen location (e.g. /root/pki_rsa): 

    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # vi tks_inst.cfg
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation.

    The values specified in the installation file below are examples. In addition to changing the HSM password, edit the values accordingly, for example ports, directories, nicknames, domains…​ 

    [DEFAULT]
pki_instance_name=rhcs10-RSA-TKS
pki_https_port=24443
pki_http_port=24080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### CA cert chain concatenated in PEM format
pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-TKS/tks_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-TKS/certs_db
pki_client_database_password=SECret.123
pki_client_database_purge=False
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-TKS
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=16389
pki_ds_ldaps_port=16636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/ca-chain.pem
pki_ds_secure_connection_ca_nickname=CA Signing Cert - rhcs10-RSA-SubCA

### Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_https_port=31443
pki_security_domain_password=SECret.123
pki_security_domain_user=caadmin


[Tomcat]
pki_ajp_port=14009
pki_tomcat_server_port=14005


[TKS]
pki_import_admin_cert=False

pki_admin_nickname=PKI Bootstrap Administrator for RSA-TKS
pki_admin_name=tksadmin
pki_admin_uid=tksadmin
pki_admin_email=tksadmin@example.com

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-TKS
pki_ds_database=CC-RSA-TKS-LDAP
pki_share_db=False
    Copy to Clipboard Toggle word wrap

  2. Run the pkispawn tool to install the TKS subsystem: 

    # pkispawn -s TKS -f tks_inst.cfg --debug
    Copy to Clipboard Toggle word wrap

    This will create the TKS instance in /var/lib/pki/rhcs10-RSA-TKS.

Note

For ease of reference, if you wanted to install the TKS using the two-step method:

  1. First run the pkispawn tool with the --skip-configuration option to install the RHCS TKS instance: 

    # pkispawn -s TKS -f tks_inst.cfg --skip-configuration --debug
    Copy to Clipboard Toggle word wrap
  2. Customize the configuration files between the two installation steps

  3. Run the pkispawn tool to configure the KRA: 

    # pkispawn -s TKS -f tks_inst.cfg --skip-installation --debug
    Copy to Clipboard Toggle word wrap

Verification

  1. Show the status of the installed TKS instance: 

    # pki-server status rhcs10-RSA-TKS
    Copy to Clipboard Toggle word wrap

    Note down the Secure Agent, Admin and pkiconsole URLs.

7.10.3. Configure OAEP support for the TKS
Copiar o link

Configuring the TKS to use the OAEP (Optimal Asymmetric Encryption Padding) key transport algorithm is done by editing the TKS’s CS.cfg configuration file.

Note

This section is for a HSM that supports AES key wrapping/unwrapping, such as an Entrust nShield Connect XC unit with firmware v12.72.1.

Prerequisite

  • You are logged onto rhcs10.example.com as root user.

Procedure

  1. Stop the TKS: 

    # pki-server stop rhcs10-RSA-TKS
    Copy to Clipboard Toggle word wrap
  2. Edit the /var/lib/pki/rhcs10-RSA-TKS/tks/conf/CS.cfg configuration file and add the following line:

keyWrap.useOAEP=true

  1. Start the TKS: 

    # pki-server start rhcs10-RSA-TKS
    Copy to Clipboard Toggle word wrap

7.10.4. Create TKS Role users
Copiar o link

7.10.5. Post-installation
Copiar o link

If you wish to install additional RHCS instances, please continue with the next relevant section. Once you have completed the installation of all of the RHCS instances you need, please go to Section 7.13, “Post-installation” to complete additional setup.

7.11. Create and configure the TPS instance
Copiar o link

This section describes installing and configuring a TPS instance against the SubCA.
The TPS system certificates will be issued by the SubCA, and the TPS will join the SubCA security domain.
In this example, the TPS is installed on rhcs10.example.com, with its internal directory server on rhds11.example.com.

Note

Make sure that the file /opt/pki_rsa/ca-chain.pem contains the complete CA certificate chain (SubCA and RootCA certificates): 

# ls -l /opt/pki_rsa/ca-chain.pem

# cat /opt/pki_rsa/ca-chain.pem
Copy to Clipboard Toggle word wrap

7.11.1. Replace the temporary DS certificate (TPS)
Copiar o link

Prior to installing the TPS, we are issuing an official SSL server certificate for the TPS' Directory Server to replace the temporary bootstrap one. To do that, we first create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-TPS-LDAP stop
    Copy to Clipboard Toggle word wrap

  2. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/Server-Cert-tps.csr -z /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-tps.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/Server-Cert-tps.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

  3. Remote copy the Server-Cert-tps.csr file to the system where the CA resides. For example: 

    # scp /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/Server-Cert-tps.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps.csr
    Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tps.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tps.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response:

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.resp -v

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:

  Certificate:
      Data:
          Version:  v3
          Serial Number: 0xA383694
          Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
          Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-TPS,O=Example-rhcs10-RSA-TPS
          Validity:
              Not Before: Tuesday, April 5, 2022 8:41:36 AM EDT America/New_York
              Not  After: Monday, March 25, 2024 8:41:36 AM EDT America/New_York
          Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x5C8FAD4
            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: Tuesday, April 5, 2022 8:36:21 AM EDT America/New_York
                Not  After: Saturday, April 5, 2042 8:36:21 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x80296C3
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-TPS
            Validity:
                Not Before: Tuesday, April 5, 2022 8:39:43 AM EDT America/New_York
                Not  After: Friday, April 5, 2041 8:39:43 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-TPS,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-tps.pem is the new Server-Cert certificate of the Directory Server instance that serves as the internaldb of the TPS.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-TPS-LDAP/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-TPS-LDAP/
    Copy to Clipboard Toggle word wrap

  2. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  3. Import the newly created DS certificate and the CA certificates in its chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-SubCA" -i /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/Server-Cert-tps.pem
    Copy to Clipboard Toggle word wrap

  4. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/

Certificate Nickname                         Trust Attributes
                                             SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA          CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA           CT,C,C
Server-Cert                                  u,u,u
    Copy to Clipboard Toggle word wrap

  5. Start DS: 

    # dsctl slapd-CC-RSA-TPS-LDAP start
    Copy to Clipboard Toggle word wrap

  6. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:17636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:17636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

7.11.2. Configuring a TPS authentication database
Copiar o link

TPS relies on an authentication database to authenticate smartcard tokens.
For more information, please see Section 2.5.2.4, “Token database”.

7.11.2.1. Setting up a LDAP server for the TPS authentication database
Copiar o link

Prior to installing the TPS, we are installing a Directory Server instance that will host the TPS AuthDB.

Note

The TPS authentication database mentioned in this section is created with simplified steps for demonstration purposes only.

On rhds11.example.com as root:

  1. Install a Directory Server instance, which the CA will use to authenticate tokens. Red Hat Directory Server is listening over the LDAP/LDAPS ports, 9389 and 9636 respectively.

    1. Create the TPS AuthDB Directory Server installation file at a chosen location (e.g. /root/pki_rsa): 

      # vim /root/pki_rsa/tps-auth-db-ldap.cfg
      Copy to Clipboard Toggle word wrap

    2. Edit the .cfg file created in the previous step. Uncomment the below parameters and set them to customize the installation: 

      [general]
full_machine_name = rhds11.example.com

[slapd]
port = 9389
secure_port = 9636
instance_name = CC-RSA-TPS-AUTH-DB
root_password = SECret.123
self_sign_cert = True

[backend-userroot]
suffix = dc=example,dc=com
create_suffix_entry = True
      Copy to Clipboard Toggle word wrap

    3. Install the Directory Server instance: 

      # dscreate from-file /root/pki_rsa/tps-auth-db-ldap.cfg

Starting installation...

Completed installation for CC-RSA-TPS-AUTH-DB
      Copy to Clipboard Toggle word wrap

  2. Add an ACI (Access Control Instruction) rule to allow anonymous bind access. By default, this is disabled.

    1. Create the ldapaci.ldif file at a chosen location (e.g. /root/pki_rsa/dirsrv/) with the following content: 

      dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
      Copy to Clipboard Toggle word wrap

    2. Run the ldapmodify command to add the ACI: 

      # ldapmodify -x -h rhds11.example.com -p 9389 -D 'cn=Directory Manager' -W -f /root/pki_rsa/dirsrv/ldapaci.ldif
      Copy to Clipboard Toggle word wrap

7.11.2.2. Replace the temporary DS certificate (TPS AuthDB)
Copiar o link

Prior to installing the TPS, we are issuing an official SSL server certificate for the TPS Authentication Database to replace the temporary bootstrap certificate. To do that, we first create a certificate signing request (CSR) for the Directory Server certificate, then submit this request to the CA.

Note

Ensure that you use the FQDN of the DS server, e.g. cn=rhds11.example.com / host=rhds11.example.com.

Generate a CSR for the real DS certificate

On rhds11.example.com, generate a PKCS10 certificate signing request for the real DS certificate:

  1. Stop DS: 

    # dsctl slapd-CC-RSA-TPS-AUTH-DB stop
    Copy to Clipboard Toggle word wrap

  2. Use the certutil tool to generate the CSR: 

    # certutil -R -d /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB -s "CN=rhds11.example.com" -g 2048 -f /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/pwdfile.txt -a -o /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/Server-Cert-tps-auth.csr -z /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/noise.txt
    Copy to Clipboard Toggle word wrap
    Important

    Edit the Server-Cert-tps-auth.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example:

    # vi /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/Server-Cert-tps-auth.csr
    Copy to Clipboard Toggle word wrap

    The CSR file must start with the line "-----BEGIN CERTIFICATE REQUEST-----" and end with the line "-----END CERTIFICATE REQUEST-----".

  3. Remote copy the Server-Cert-tps-auth.csr file to the system where the CA resides. For example: 

    # scp /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/Server-Cert-tps-auth.csr root@rhcs10.example.com:/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps-auth.csr
    Copy to Clipboard Toggle word wrap

Issue the real DS certificate

On rhcs10.example.com, issue the actual SSL server certificate:

  1. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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.
### For input on a different host, specify where to find the CSR.
input=/root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps-auth.csr

### output: full path for the CMC request in binary format
### For output on a different host, specify the destination.
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.req

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

### nickname: nickname for the agent certificate that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for cert8.db that stores the agent certificate
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.req
      Copy to Clipboard Toggle word wrap

  2. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tps-auth.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tps-auth.cfg

Total number of bytes read = 3096
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: 2492
Date: Tue, 29 Sep 2020 15:20:21 GMT
Connection: close
##end##

. . . Output omitted . . .

The response in binary format is stored in
/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  3. Process the CMC Response:

    1. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

      Important

      Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

      # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.resp -v

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:

  Certificate:
      Data:
          Version:  v3
          Serial Number: 0xA383694
          Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
          Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-TPS,O=Example-rhcs10-RSA-TPS
          Validity:
              Not Before: Tuesday, April 5, 2022 8:41:36 AM EDT America/New_York
              Not  After: Monday, March 25, 2024 8:41:36 AM EDT America/New_York
          Subject: CN=rhds11.example.com

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x5C8FAD4
            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: Tuesday, April 5, 2022 8:36:21 AM EDT America/New_York
                Not  After: Saturday, April 5, 2042 8:36:21 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

    Certificate:
        Data:
            Version:  v3
            Serial Number: 0x80296C3
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-TPS
            Validity:
                Not Before: Tuesday, April 5, 2022 8:39:43 AM EDT America/New_York
                Not  After: Friday, April 5, 2041 8:39:43 AM EDT America/New_York
            Subject: CN=CA Signing Certificate,OU=rhcs10-RSA-TPS,O=Example-rhcs10-RSA-RootCA

. . . Output omitted . . .

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.
      Copy to Clipboard Toggle word wrap

    2. Save the new Server-Cert DS certificate into a file in the bootstrap certificate directory (e.g. /root/.dogtag/pki_rsa_bootstrap/certs_db/) named accordingly. The .pem file must start with the header -----BEGIN CERTIFICATE----- and end with the footer -----END CERTIFICATE-----. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps-auth.pem
      Copy to Clipboard Toggle word wrap

      Where Server-Cert-tps-auth.pem is the new Server-Cert certificate of the Directory Server instance that serves as the authentication db of the TPS.

      Note

      The RootCA’s signing certificate should match with the output from the following command: 

      # certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a
      Copy to Clipboard Toggle word wrap

  4. Remote copy the new Server-Cert certificate to rhds11.example.com. For example: 

    # scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps-auth.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/
    Copy to Clipboard Toggle word wrap

Replace the temporary DS certificate

On rhds11.example.com, replace the temporary DS certificate with the actual DS certificate:

  1. Save the contents of the dirsrv directory into a backup directory: 

    # cp -r /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/ /etc/dirsrv/save-rsa/slapd-CC-RSA-TPS-AUTH-DB/
    Copy to Clipboard Toggle word wrap

  2. Delete the old DS certificates: 

    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/ -f /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/pwdfile.txt -n "Server-Cert"
    Copy to Clipboard Toggle word wrap 
    # certutil -D -d /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/ -f /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/pwdfile.txt -n "Self-Signed-CA"
    Copy to Clipboard Toggle word wrap

  3. Import the newly created DS certificate and the CA certificates in its chain one by one. For example: 

    # certutil -d /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/ -f /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-RootCA" -i /opt/pki_rsa/rootCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/ -f /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/pwdfile.txt -A -t "CT,C,C" -n "CA Signing Cert - rhcs10-RSA-SubCA" -i /opt/pki_rsa/subCA.pem
    Copy to Clipboard Toggle word wrap 
    # certutil -d /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/ -f /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/pwdfile.txt -A -t "u,u,u" -n "Server-Cert" -i /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/Server-Cert-tps-auth.pem
    Copy to Clipboard Toggle word wrap

  4. List the certificates: 

    # certutil -L -d /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/

Certificate Nickname                        Trust Attributes
                                            SSL,S/MIME,JAR/XPI
CA Signing Cert - rhcs10-RSA-RootCA         CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA          CT,C,C
Server-Cert                                 u,u,u
    Copy to Clipboard Toggle word wrap

  5. Start DS: 

    # dsctl slapd-CC-RSA-TPS-AUTH-DB start
    Copy to Clipboard Toggle word wrap

  6. Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): 

    # ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:9636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

    If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 

    # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapsearch -x -D "cn=Directory Manager" -H ldaps://rhds11.example.com:9636 -b "dc=example,dc=com" -w SECret.123
    Copy to Clipboard Toggle word wrap

7.11.3. Install the TPS instance
Copiar o link

To install the TPS, use either the single-step method or the two-step method. The following procedure describes the single-step method. If you wish to install using the two-step method, please refer to ] as well as xref:_rootca_two_step[.

Important

BEFORE you install the TPS, if you intend the AIA extension to point to the external OCSP instance instead of the CA’s internal OCSP, make sure you first follow the steps under Section 7.7.4, “Set the default AIA extension to point to this OCSP”.

Prerequisites

Procedure

  1. Create a TPS installation file at a chosen location (e.g. /root/pki_rsa): 

    # cd /root/pki_rsa
    Copy to Clipboard Toggle word wrap 
    # vi tps_inst.cfg
    Copy to Clipboard Toggle word wrap
    Note

    Unless explicitly specified, system certificate nicknames are automatically named bearing the value specified for pki_instance_name. To avoid certificate nickname conflicts on a shared HSM, use a unique instance name for each instance creation.

    The values specified in the installation file below are examples. In addition to changing the HSM password, edit the values accordingly, for example ports, directories, nicknames, domains…​ 

    [DEFAULT]
pki_instance_name=rhcs10-RSA-TPS
pki_https_port=25443
pki_http_port=25080

### Crypto Token
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM-CONN-XC
pki_token_password=<YourHSMpassword>

pki_audit_signing_token=NHSM-CONN-XC
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=2048
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA

pki_subsystem_token=NHSM-CONN-XC
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_signing_algorithm=SHA256withRSA
pki_subsystem_key_size=2048
pki_subsystem_key_type=rsa

pki_sslserver_token=NHSM-CONN-XC
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_signing_algorithm=SHA256withRSA
pki_sslserver_key_size=2048
pki_sslserver_key_type=rsa

### CA cert chain concatenated in PEM format
pki_cert_chain_path=/opt/pki_rsa/ca-chain.pem

### Bootstrap Admin
pki_admin_password=SECret.123
pki_admin_key_type=rsa
pki_admin_key_size=2048
pki_admin_key_algorithm=SHA256withRSA

### Bootstrap Admin client dir
pki_client_admin_cert_p12=/opt/pki_rsa/rhcs10-RSA-TPS/tps_admin_cert.p12
pki_client_database_dir=/opt/pki_rsa/rhcs10-RSA-TPS/certs_db
pki_client_database_password=SECret.123
pki_client_database_purge=False
pki_client_dir=/opt/pki_rsa/rhcs10-RSA-TPS
pki_client_pkcs12_password=SECret.123

### Internal LDAP
pki_ds_bind_dn=cn=Directory Manager
pki_ds_ldap_port=17389
pki_ds_ldaps_port=17636
pki_ds_password=SECret.123
pki_ds_remove_data=True
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=/opt/pki_rsa/ca-chain.pem
pki_ds_secure_connection_ca_nickname=CA Signing Cert - rhcs10-RSA-SubCA

### Security Domain
pki_security_domain_hostname=rhcs10.example.com
pki_security_domain_https_port=31443
pki_security_domain_password=SECret.123
pki_security_domain_user=caadmin


[Tomcat]
pki_ajp_port=14019
pki_tomcat_server_port=14015

[TPS]
pki_import_admin_cert=False

pki_admin_nickname=PKI Bootstrap Administrator for RSA-TPS
pki_admin_name=tpsadmin
pki_admin_uid=tpsadmin
pki_admin_email=tpsadmin@example.com

pki_ds_hostname=rhds11.example.com
pki_ds_base_dn=dc=RSA-TPS
pki_ds_database=CC-RSA-TPS-LDAP
pki_share_db=False

### basedn of the TPS token authentication database
pki_authdb_basedn = dc=example,dc=com
pki_authdb_hostname=rhds11.example.com
pki_authdb_port=9636
pki_authdb_secure_conn=True
pki_ca_uri=https://rhcs10.example.com:31443
pki_tks_uri=https://rhcs10.example.com:24443
pki_kra_uri=https://rhcs10.example.com:28443
pki_enable_server_side_keygen=True

pki_import_shared_secret=True
    Copy to Clipboard Toggle word wrap

  2. Run the pkispawn tool to install the TPS subsystem: 

    # pkispawn -s TPS -f tps_inst.cfg --debug
    Copy to Clipboard Toggle word wrap

    This will create the TPS instance in /var/lib/pki/rhcs10-RSA-TPS.

Note

For ease of reference, if you wanted to install the TPS using the two-step method:

  1. First run the pkispawn tool with the --skip-configuration option to install the RHCS TPS instance: 

    # pkispawn -s TPS -f tps_inst.cfg --skip-configuration --debug
    Copy to Clipboard Toggle word wrap
  2. Customize the configuration files between the two installation steps

  3. Run the pkispawn tool to configure the TPS: 

    # pkispawn -s TPS -f tps_inst.cfg --skip-installation --debug
    Copy to Clipboard Toggle word wrap

Verification

  1. Show the status of the installed TPS instance: 

    # pki-server status rhcs10-RSA-TPS
    Copy to Clipboard Toggle word wrap

    Note down the Secure Agent, Admin and pkiconsole URLs.

  2. Verify that the TPS agent web page is accessible.

  3. Import the TPS bootstrap administrator certificate into the nssdb: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db client-cert-import --pkcs12 /opt/pki_rsa/rhcs10-RSA-TPS/tps_admin_cert.p12 --pkcs12-password SECret.123

----------------------------------------
Imported certificates from PKCS #12 file
----------------------------------------
    Copy to Clipboard Toggle word wrap
Note

You can only perform the actual smartcard token enrollment tests after you complete the setup procedures detailed in the next subsections.

7.11.4. Testing token-side key generation
Copiar o link

This section presents a simple demonstration of a token key enrollment using token-side key generation (as opposed to server-side key generation). In order to test token-side key generation, we are going to create a new test user, then format and enroll a token for this user via the tpsclient tool.

Prepare for testing token-side key generation

  1. Temporarily update the userKey profile to only generate signing certificates:

    1. Stop the TPS: 

      # pki-server stop rhcs10-RSA-TPS
      Copy to Clipboard Toggle word wrap

    2. Edit the /var/lib/pki/rhcs10-RSA-TPS/tps/conf/CS.cfg configuration file and change the op.enroll.userKey.keyGen.keyType.num parameter from 2 to 1. E.g: 

      op.enroll.userKey.keyGen.keyType.num=1
      Copy to Clipboard Toggle word wrap

    3. Start the TPS: 

      # pki-server start rhcs10-RSA-TPS
      Copy to Clipboard Toggle word wrap

  2. Create a new user for testing token enrollment, e.g. jdoe:

    1. First check if the TPS WebUI is up: 

      # pki -U https://rhcs10.example.com:25443 -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -n "PKI Bootstrap Administrator for RSA-TPS" -c SECret.123 tps-user-show tpsadmin

---------------
User "tpsadmin"
---------------
  User ID: tpsadmin
  Full name: tpsadmin
  Email: tpsadmin@example.com
  Type: adminType
  State: 1
  TPS Profiles:
	All Profiles
      Copy to Clipboard Toggle word wrap

    2. Create a .cfg file for a POSIX user as follows: 

      # vi ldap_user1_add.cfg
      Copy to Clipboard Toggle word wrap

      • Add the following content to the file and save: 

        dn: uid=jdoe,dc=example,dc=com
objectClass: extensibleobject
objectclass: inetorgperson
objectclass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: top
homeDirectory: /var/empty
gidNumber: 99997
uidNumber: 99996
sn: jdoe
uid: jdoe
cn: TPS jdoe
mail: user3@redhat.com
givenName: jdoe
userPassword: SECret.123
shrTok:
        Copy to Clipboard Toggle word wrap

    3. Configure anonymous bind access:

      1. Create an ldif file containing the following: 

        dn: ou=People,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyon
e";)
        Copy to Clipboard Toggle word wrap

      2. Run the following to enable anonymous bind access: 

        ldapadd -h rhds11-5.example.com -p 389 -c -D "cn=Directory Manager" -w SECret.123 -f ldapci.ldif
        Copy to Clipboard Toggle word wrap

    4. Run the ldapadd command with the previously created .cfg file to add the jdoe user: 

      # LDAPTLS_CACERT=/opt/pki_rsa/ca-chain.pem ldapadd -x -D 'cn=directory manager' -H ldaps://rhds11.example.com:9636 -w SECret.123 -f ldap_user1_add.cfg
      Copy to Clipboard Toggle word wrap

Test token-side key generation

Test token-side key generation using the tpsclient tool to format and enroll a token.

  1. On a separate non-FIPS-enabled system, install the tpsclient package. For example: 

    # dnf install -y redhat-pki-tps
    Copy to Clipboard Toggle word wrap
    Note

    If you are testing on a Fedora system, the corresponding package providing the tpsclient tool would be dogtag-pki-tools.

  2. Add the TPS server hostname and IP address to the /etc/hosts file: 

    # echo "<TPS server IP> rhcs10.example.com" >> /etc/hosts
    Copy to Clipboard Toggle word wrap

  3. Test the format and enrollment for the newly created user:

    1. Prepare to format a token for jdoe. Create a .txt file: 

      # vi token_format.txt
      Copy to Clipboard Toggle word wrap

      Add the following content. The host and port values should match your own; the port should be a non-SSL port. 

      op=var_set name=ra_host value=rhcs10.example.com
op=var_set name=ra_port value=25080
op=var_set name=ra_uri value=/tps/tps
op=token_set cuid=40906145C76224192D2B msn=01020304 app_ver=6FBBC105 key_info=0101 major_ver=0 minor_ver=0
op=token_set auth_key=404142434445464748494a4b4c4d4e4f
op=token_set mac_key=404142434445464748494a4b4c4d4e4f
op=token_set kek_key=404142434445464748494a4b4c4d4e4f
op=ra_format uid=jdoe pwd=SECret.123 num_threads=1 extensions=tokenType=userKey
      Copy to Clipboard Toggle word wrap

    2. Prepare to enroll a token for jdoe. Create a .txt file: 

      # vi token_enroll.txt
      Copy to Clipboard Toggle word wrap

      Add the following content. The host and port values should match your own; the port should be a non-SSL port. 

      op=var_set name=ra_host value=rhcs10.example.com
op=var_set name=ra_port value=25080
op=var_set name=ra_uri value=/tps/tps
op=token_set cuid=40906145C76224192D2B msn=01020304 app_ver=6FBBC105 key_info=0101 major_ver=0 minor_ver=0
op=token_set auth_key=404142434445464748494a4b4c4d4e4f
op=token_set mac_key=404142434445464748494a4b4c4d4e4f
op=token_set kek_key=404142434445464748494a4b4c4d4e4f
op=ra_enroll uid=jdoe pwd=SECret.123 num_threads=1 extensions=tokenType=userKey
op=exit
      Copy to Clipboard Toggle word wrap

    3. Format jdoe’s token. The operation should succeed.: 

      # tpsclient < token_format.txt
      Copy to Clipboard Toggle word wrap

    4. Enroll jdoe’s token. The operation should succeed: 

      # tpsclient < token_enroll.txt
      Copy to Clipboard Toggle word wrap

Revert the changes after testing

  1. To delete the added test token after verification:

    1. Log in to the TPS WebUI at https://rhcs10.example.com:25443/tps/ui/
    2. Click Tokens and select the token in check box.
    3. Click Remove, then confirm.

  2. Alternatively, you can use CLI commands to delete the test token. For example: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -n "PKI Bootstrap Administrator for RSA-TPS" -c SECret.123 -p 25443 tps-token-find
-----------------
1 entries matched
-----------------
  Token ID: 40906145C76224192D2B
  User ID: jdoe
  Type: userKey
  Status: ACTIVE
  Next States: DAMAGED, PERM_LOST, SUSPENDED, TERMINATED
  Applet ID: 1.4.58768072
  Key Info: 0101
  Policy: RE_ENROLL=YES;RENEW=NO;FORCE_FORMAT=NO;PIN_RESET=NO;RESET_PIN_RESET_TO_NO=NO
  Date Created: Tue Dec 19 13:17:46 EST 2023
  Date Modified: Tue Dec 19 13:17:50 EST 2023
----------------------------
Number of entries returned 1
----------------------------
    Copy to Clipboard Toggle word wrap 
    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -n "PKI Bootstrap Administrator for RSA-TPS" -c SECret.123 -p 25443 tps-token-del 40906145C76224192D2B
------------------------------------
Deleted token "40906145C76224192D2B"
------------------------------------
    Copy to Clipboard Toggle word wrap

  3. Revert op.enroll.userKey.keyGen.keyType.num back to 2:

    1. Stop the TPS: 

      # pki-server stop rhcs10-RSA-TPS
      Copy to Clipboard Toggle word wrap

    2. Edit the /var/lib/pki/rhcs10-RSA-TPS/tps/conf/CS.cfg configuration file and change back the op.enroll.userKey.keyGen.keyType.num parameter from 1 to 2. E.g.: 

      op.enroll.userKey.keyGen.keyType.num=2
      Copy to Clipboard Toggle word wrap

    3. Start the TPS: 

      # pki-server start rhcs10-RSA-TPS
      Copy to Clipboard Toggle word wrap

7.11.5. Configure OAEP support for the TPS
Copiar o link

Configuring the TPS to use the OAEP (Optimal Asymmetric Encryption Padding) key transport algorithm is done by editing the TPS’s CS.cfg configuration file.

Note

This section is for a HSM that supports AES key wrapping/unwrapping, such as an Entrust nShield Connect XC unit with firmware v12.72.1.

Prerequisite

  • You are logged onto rhcs10.example.com as root user.

Procedure

  1. Stop the TPS: 

    # pki-server stop rhcs10-RSA-TPS
    Copy to Clipboard Toggle word wrap
  2. Edit the /var/lib/pki/rhcs10-RSA-TPS/tps/conf/CS.cfg configuration file and add the following line:

keyWrap.useOAEP=true

  1. Start the TPS: 

    # pki-server start rhcs10-RSA-TPS
    Copy to Clipboard Toggle word wrap

7.11.6. Configuring AES support for TMS Server-Side-Keygen
Copiar o link

This version of Red Hat Certificate System, specifically the Token Management System and the JAVA applet, is enhanced to support the latest HSM to work with the Global Platform Secure Channel Protocol 3 (SCP03) smart card tokens. This is done thanks to the addition of the AES Key Wrap With Padding (KWP) mode to handle key injection, which is predominantly used in the TMS Server-Side-Keygen feature.

Note

You can find the new JAVA applet at: /usr/share/pki/tps/applets/1.5.64260792.ijc

TPS CS.cfg

To use this applet, you must configure the TPS CS.cfg configuration file, as follows:

  • For enrollment: 

    op.enroll.<tps profile>.update.applet.requiredVersion.prot.3=1.5.64260792op.enroll.<tps profile>.update.applet.requiredVersion.prot.3=1.5.64260792op.enroll.<tps profile>.update.applet.requiredVersion.prot.3=1.5.64260792
    Copy to Clipboard Toggle word wrap

  • For format: 

    op.format.<tps profile>.update.applet.requiredVersion.prot.3=1.5.64260792op.format.<tps profile>.update.applet.requiredVersion.prot.3=1.5.64260792op.format.<tps profile>.update.applet.requiredVersion.prot.3=1.5.64260792
    Copy to Clipboard Toggle word wrap

Note that you must then configure any other profiles (including external registration) to use this applet.

For example: 

op.enroll.userKey.update.applet.directory=/usr/share/pki/tps/applets
op.enroll.userKey.update.applet.emptyToken.enable=true
op.enroll.userKey.update.applet.enable=true
op.enroll.userKey.update.applet.encryption=true
op.enroll.userKey.update.applet.requiredVersion=1.4.58768072
op.enroll.userKey.update.applet.requiredVersion.prot.3=1.5.64260792
Copy to Clipboard Toggle word wrap

TPS server.xml

The KWP implementation takes a bit longer to unwrap the private keys(s) onto the token than previously. It is therefore necessary to increase the connection timeout value in the server.xml file. For example, set the following connectionTimeout value for the Secure Connector in /var/lib/pki/rhcs10-RSA-TPS/conf/server.xml: 

connectionTimeout="300000”
Copy to Clipboard Toggle word wrap

The recommendation for the value to try would depend on the size of the private key being injected. A good starting point would be twice that value to make sure a wide variety of key sizes will be supported.

In case a successful enrollment is more important than the wait time, you can bypass the timeout by assigning “-1” to connectionTimeout: 

connectionTimeout="-1”
Copy to Clipboard Toggle word wrap

TKS CS.cfg

tks.defKeySet.prot3.devKeyType=AES
tks.defKeySet.prot3.divers=gpkmc
tks.defKeySet.prot3.diversVer1Keys=none
tks.defKeySet.prot3.masterKeyType=AES
Copy to Clipboard Toggle word wrap

7.11.7. Setting key sizes
Copiar o link

It is important to set all keysizes to be greater or equal to 2048. E.g: 

op.enroll.userKey.keyGen.encryption.keySize=2048
op.enroll.userKey.keyGen.signing.keySize=2048
Copy to Clipboard Toggle word wrap

7.11.8. Setup TPS phoneHome
Copiar o link

  1. Edit the phoneHome.xml configuration file. For example: 

    # vi /var/lib/pki/rhcs10-RSA-TPS/tps/conf/phoneHome.xml
    Copy to Clipboard Toggle word wrap

  2. Set the correct http port for the TPS. For example: 

    <Operation>http://rhcs10.example.com:25080/tps/tps</Operation>
    Copy to Clipboard Toggle word wrap

    It will now look like the following: 

    # cat phoneHome.xml

<ServiceInfo>
<IssuerName>Example Corp</IssuerName>
<Services>
<Operation>http://rhcs10.example.com:25080/tps/tps</Operation>
<UI></UI>
<EnrolledTokenBrowserURL>http://fedoraproject.org</EnrolledTokenBrowserURL>
<EnrolledTokenURL></EnrolledTokenURL>
<TokenType>userKey</TokenType>
</Services>
</ServiceInfo>
    Copy to Clipboard Toggle word wrap
  3. Save and restart the TPS.

7.11.9. Create TPS Role users
Copiar o link

7.11.10. Post-installation
Copiar o link

If you wish to install additional RHCS instances, please continue with the next relevant section. Once you have completed the installation of all of the RHCS instances you need, please go to Section 7.13, “Post-installation” to complete additional setup.

7.12. Create PKI role users
Copiar o link

This section describes the user configuration that takes place after the subsystems installation.

Important

Some of the examples in the previous chapters assume that some of the example non-OS-root pki role users (e.g. PKI agent jsmith) are already created and ready to perform their duty with their pki role privileges. Those example users are therefore proposed to be used for operations such as processing certificate requests.

However, the PKI bootstrap admin certificate, having been granted the privileges of all PKI roles, could be used for evaluation/testing purposes. In which case, one could simply use the bootstrap user’s certificate database directory to generate CSRs (and import certificates when issued) as root for the single-role user certificates.

For real world operations, it is highly advisable to follow the instructions in the present chapter to create roles with restricted privileges for day to day operations, once you have completed the installation. Once the real role users are created and tested to function correctly, You can then remove/disable the bootstrap certificate as described in Section 7.12.6, “Removing the bootstrap admin users from the authentication databases (optional)”.

The setup process only creates some role user accounts for demonstration purposes (specifically, setup for the SubCA role users). To manage a PKI environment in real life, a larger number of administrators, agents, and auditors are often created after the instance is set up.

Create Admin, Agent, and Audit users as appropriate for testing relevant RHCS subsystems, including CA, OCSP, and KRA. And if TMS is of interest, create Admin and Audit users for TKS and TPS, and Operator users for TPS.

Note

The following procedures only demonstrates how to set up PKI role users (users jgenie, jsmith, and aguru created in Section 7.1.1, “Creating OS users and groups” for the subordinate CA. In these examples, the certificate requests (CSRs) are approved by using the SubCA’s bootstrap admin certificate.

7.12.1. Prerequisites
Copiar o link

Prior to performing the recommended procedure to issue any certificate, make sure your SubCA bootstrap admin certificate/key is ready to perform the tasks.

  1. Login to rhcs10.example.com as root user.

  2. Check the existence of an admin/agent certificate (in this case, the SubCA’s bootstrap admin certificate) in the nssdb (this was set up in Section 7.8.1, “Issue a non-bootstrap agent user certificate”: 

    # certutil -d /root/.dogtag/pki_rsa_bootstrap/certs_db -L

Certificate Nickname                            Trust Attributes
                                                SSL,S/MIME,JAR/XPI
PKI Bootstrap Administrator for RSA-SubCA       u,u,u
CA Signing Cert - rhcs10-RSA-RootCA             CT,C,C
CA Signing Cert - rhcs10-RSA-SubCA              CT,C,C
PKI Bootstrap Administrator for RSA-RootCA      u,u,u
    Copy to Clipboard Toggle word wrap

7.12.2. Admin users
Copiar o link

  • adminV (this user will have a valid certificate throughout testing)
  • adminR (this user will have a revoked certificate)
  • adminE (this user will have an expired certificate)
  • adminTCA (this user’s certificate will be signed by a trusted CA)
  • adminC (initially this user will be assigned to the administrator group; during the testing process this user will be assigned to a different group)

  • adminUTCA (this user’s certificate will be issued by an untrusted CA)

    Note

    This last one requires a second CA setup!

7.12.2.1. Setting up certificate and role for a pki administrator
Copiar o link

The following example procedure will create a CMC signed user certificate, rsa_SubCA_AdminV, for the OS user jgenie. This CMC request will be signed using the SubCA bootstrap administrator certificate in the next section.

7.12.2.1.1. Generating a CSR for a pki administrator
Copiar o link

This procedure, to be performed by the would-be pki administrator (e.g. Jane Genie, jgenie), aims to create a CSR for this admin user.

  1. Login to rhcs10.example.com as an 'Administrator' (a non-root user), in this example jgenie.

  2. Create a client nssdb in case it does not already exist: 

    $ pki -d /home/jgenie/certs_db -c SECret.123 client-init
    Copy to Clipboard Toggle word wrap

  3. Use the PKCS10Client tool to generate a PKCS #10 certificate request:

    Note

    Change the subjectDN and the .req file name as appropriate for each subsystem, example: OCSP_AdminV, KRA_AdminV etc. 

    $ PKCS10Client -d /home/jgenie/certs_db -p SECret.123 -n "cn=rsa_SubCA_AdminV, uid=rsa_SubCA_AdminV" -o /home/jgenie/certs_db/rsa_SubCA_AdminV.req

PKCS10Client: Certificate request written into /home/jgenie/certs_db/rsa_SubCA_AdminV.req
PKCS10Client: PKCS#10 request key id written into /home/jgenie/certs_db/rsa_SubCA_AdminV.req.keyId
    Copy to Clipboard Toggle word wrap

    The jgenie user should send the certificate request (CSR) /home/jgenie/certs_db/rsa_SubCA_AdminV.req to the user who holds the SubCA’s bootstrap admin certificate, e.g. the root user, to CMC sign and approve the request.

7.12.2.1.2. Approving the CSR for a pki administrator user
Copiar o link

This section describes the procedure to be performed by the user who holds the SubCA’s bootstrap admin certificate, e.g. the root user. It demonstrates how to process the CSR (e.g. created in the previous section by jgenie) to issue the pki admin certificate.

Prerequisites

  • You are logged-in to the RHCS machine as root user.
  • An admin/agent certificate (in this example the SubCA bootstrap certificate) is present in the nssdb.

Issuing the certificate via CMC

The user holding the bootstrap admin certificate/keys can now process the CSR sent from jgenie as follows:

  1. Place the CSR file (rsa_SubCA_AdminV.req) received from jgenie to the /root/.dogtag/pki_rsa_bootstrap/certs_db directory.

  2. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AdminV.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AdminV.req

### output: full path for the CMC request in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AdminV_pkcs10.req

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

### nickname: nickname for the user cert that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for the cert8.db that stores the user signing cert and keys
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10

### 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=false
identityProofV2.hashAlg=SHA-512
identityProofV2.macAlg=SHA-256-HMAC
request.privKeyId= _<private key id>_
      Copy to Clipboard Toggle word wrap
      NOTE

      For request.privKeyId= <private key id>: the private key id to use here is the one generated from the previous step. See the output message : 

      PKCS10Client: PKCS#10 request key id written into /home/jgenie/certs_db/rsa_SubCA_AdminV.req.keyId
      Copy to Clipboard Toggle word wrap

      A quick way to do this would be something like: key_id=cat /home/jgenie/certs_db/rsa_SubCA_AdminV.req.keyId;sed -i 's/request.privKeyId= <private key id>/request.privKeyId='$key_id'/g' /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AdminV.cfg

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AdminV.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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 /root/.dogtag/pki_rsa_bootstrap/cmc.rsa_SubCA_AdminV_pkcs10.req
      Copy to Clipboard Toggle word wrap

  3. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AdminV_signed.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AdminV_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AdminV_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AdminV_signed.cfg

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

. . . Output omitted . . .

The response in binary format is stored in /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AdminV_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  4. Process the response using CMCResponse to display all certificates in chain individually in PEM format: 

    # CMCResponse -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AdminV_pkcs10.resp -o /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AdminV_pkcs7.crt

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:
    Certificate:
       Data:
           Version:  v3
           Serial Number: 0xF64CE29
           Signature Algorithm: SHA512withRSA - 1.2.840.113549.1.1.13
           Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
           Validity:
               Not Before: Friday, January 5, 2018 8:09:48 PM EST America/New_York
               Not  After: Wednesday, July 4, 2018 8:09:48 PM EDT America/New_York
           Subject: CN=rsa_SubCA_AdminV,UID=rsa_SubCA_AdminV

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
  OID: {1 3 6 1 5 5 7 7 25}
  BodyList: 1
  Status: SUCCESS
    Copy to Clipboard Toggle word wrap

  5. Copy the agent certificate to /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AdminV_b64.crt: 

    # pki -p 31443 ca-cert-export <rsa_SubCA_AdminV_serial_number> --output-file /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AdminV_b64.crt
    Copy to Clipboard Toggle word wrap
7.12.2.1.3. Creating the pki admin user and associating the new certificate
Copiar o link

This procedure is to be performed by an existing pki admin user, in this case, the root user that holds the SubCA bootstrap certificate.

To create a pki administrator user and associate the new certificate with this user:

  1. Create a user, in this example rsa_SubCA_AdminV: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-add --fullName="rsa_SubCA_AdminV" rsa_SubCA_AdminV
---------------------
Added user "rsa_SubCA_AdminV"
---------------------
 User ID: rsa_SubCA_AdminV
 Full name: rsa_SubCA_AdminV
    Copy to Clipboard Toggle word wrap

    Similarly:

    • For the KRA, use the kra-user-add command with the KRA’s admin nick, hostname and port to create the new user, e.g. KRA_AdminV.
    • For the OCSP, use the ocsp-user-add command with the OCSP’s admin nick, hostname and port to create the new user, e.g. OCSP_AdminV.

    And if TMS is of interest:

    • For the TKS, use the tks-user-add command with the TKS’s admin nick, hostname and port to create the new user, e.g. TKS_AdminV.
    • For the TPS, use the tps-user-add command with the TPS’s admin nick, hostname and port to create the new user, e.g. TPS_AdminV.

  2. Add the new user to the Administrators group: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-group-member-add Administrators rsa_SubCA_AdminV
-----------------------------
Added group member "rsa_SubCA_AdminV"
-----------------------------
 User: rsa_SubCA_AdminV
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To add newly created users (e.g. KRA_AdminV) to the KRA’s administrators group, use the kra-group-member-add command with the KRA’s admin nick, hostname, and port.
    • To add newly created users (e.g. OCSP_AdminV) to the OCSP’s administrators group, use the ocsp-group-member-add command with the OCSP’s admin nick, hostname, and port.

    And if TMS is of interest:

    • To add newly created users (e.g. TKS_AdminV) to the TKS’s administrators group, use the tks-group-member-add command with the TKs’s admin nick, hostname, and port.
    • To add newly created users (e.g. TPS_AdminV) to the TPS’s administrators group, use the tps-group-member-add command with the TPS’s admin nick, hostname, and port.

  3. Verify that the user got added to the Administrators group: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-group-member-find Administrators
-----------------
2 entries matched
-----------------
 User: caadmin

 User: rsa_SubCA_AdminV
----------------------------
Number of entries returned 2
----------------------------
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To verify membership in the KRA’s administrators group, use the kra-group-member-find command with the KRA’s hostname and port.
    • To verify membership in the OCSP’s administrators group, use the ocsp-group-member-find command with the OCSP’s hostname and port.

    And if TMS is of interest:

    • To verify membership in the TKS’s administrators group, use the tks-group-member-find command with the TKS’s hostname and port.
    • To verify membership in the TPS’s administrators group, use the tps-group-member-find command with the TPS’s hostname and port.

  4. Add the rsa_SubCA_AdminV certificate to the pki role user: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-cert-add rsa_SubCA_AdminV --input /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AdminV_b64.crt

-------------------------------------------------------------------------------------------------------------------------------------
Added certificate "2;258264617;CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA;CN=rsa_SubCA_AdminV,UID=rsa_SubCA_AdminV"
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To add certificates to users in the KRA and the OCSP, use respectively the kra-user-cert-add and the ocsp-user-cert-add commands with the corresponding subsystem’s hostname and port.

    And if TMS is of interest:

    • To add certificates to users in the TKS and the TPS, use respectively the tks-user-cert-add and the tps-user-cert-add commands with the corresponding subsystem’s hostname and port.
  5. Send the certificate file, /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AdminV_pkcs7.crt, to the user (e.g. jgenie). The file can then be copied to the user location /home/jgenie/certs_db/rsa_SubCA_AdminV_pkcs7.crt to import in a later step.
7.12.2.1.4. Importing the pki admin certificate to the client nssdb
Copiar o link

This procedure is to be performed by the new pki admin user (e.g. jgenie) who has previously received the newly issued certificate file (e.g. /home/jgenie/certs_db/rsa_SubCA_AdminV_pkcs7.crt) from the bootstrap user, in this case, the root user.

  1. Login to rhcs10.example.com as the pki administrator whose certificate was issued in the previous section, e.g. jgenie.

  2. Install the certificate, e.g. rsa_SubCA_AdminV: 

    $ pki -d /home/jgenie/certs_db -c SECret.123 pkcs7-import "rsa_SubCA_AdminV" --pkcs7 /home/jgenie/certs_db/rsa_SubCA_AdminV_pkcs7.crt
    Copy to Clipboard Toggle word wrap 
    $ certutil -d /home/jgenie/certs_db -L

Certificate Nickname                Trust Attributes
                                    SSL,S/MIME,JAR/XPI

. . . Output omitted . . .

rsa_SubCA_AdminV                    u,u,u
    Copy to Clipboard Toggle word wrap

  3. Back up the role user rsa_SubCA_AdminV certificate by creating a .p12 file, here for example with the password SECret.123: 

    $ pki -d /home/jgenie/certs_db -c SECret.123 client-cert-show "rsa_SubCA_AdminV" --pkcs12 /home/jgenie/certs_db/rsa_SubCA_AdminV.p12 --pkcs12-password SECret.123
    Copy to Clipboard Toggle word wrap
    Note

    You can use the .p12 file later for admin tests, for example: by importing the file to ~/.redhat-idm-console for console client authentication.

Verification:

  • To test the admin operation: 

    $ pki -v -d /home/jgenie/certs_db -c SECret.123 -n "rsa_SubCA_AdminV" -p 31443 ca-user-find
    Copy to Clipboard Toggle word wrap

7.12.3. Agent users
Copiar o link

  • agentV (this user will have a valid certificate throughout testing)
  • agentR (this user will have a revoked certificate)
  • agentE (this user will have an expired certificate)
  • agentTCA (this user’s certificate will be signed by a trusted CA)

  • agentUTCA (this user’s certificate will be issued by an untrusted CA)

    Note

    This last one requires a second CA setup!

7.12.3.1. Setting up certificate and role for a pki agent
Copiar o link

The following example procedure will create a CMC signed user certificate, rsa_SubCA_AgentV, for the user agent jsmith. This CMC request will be signed using the SubCA bootstrap administrator certificate in the next section.

7.12.3.1.1. Generating a CSR for a pki agent
Copiar o link

This section, to be performed by a pki agent (e.g. jsmith), aims to create a CSR for this user.

  • Login to rhcs10.example.com as an 'Agent' (a non-root user, e.g. John Smith, jsmith).

    1. Create a client nssdb if it does not already exist: 

      $ pki -d /home/jsmith/certs_db -c SECret.123 client-init
      Copy to Clipboard Toggle word wrap

    2. Use the PKCS10Client tool to generate a PKCS#10 certificate request:

      Note

      Change the subjectDN and the .req file name as appropriate for each subsystem, example: OCSP_AgentV, KRA_AgentV etc. 

      $ PKCS10Client -d /home/jsmith/certs_db -p SECret.123 -n "cn=rsa_SubCA_AgentV, uid=rsa_SubCA_AgentV" -o /home/jsmith/certs_db/rsa_SubCA_AgentV.req

PKCS10Client: Certificate request written into /home/jsmith/certs_db/rsa_SubCA_AgentV.req
PKCS10Client: PKCS#10 request key id written into /home/jsmith/certs_db/rsa_SubCA_AgentV.req.keyId
      Copy to Clipboard Toggle word wrap

      The jsmith user should send the certificate request (CSR) /home/jsmith/certs_db/rsa_SubCA_AgentV.req to the user who holds the SubCA’s bootstrap admin certificate, e.g. the root user, to CMC sign and approve the request.

7.12.3.1.2. Approving the CSR for a pki agent user
Copiar o link

This section describes the procedure to be performed by the user who holds the SubCA’s bootstrap admin certificate, e.g. the root user. It demonstrates how to process the CSR (created by jsmith in the previous section) to issue the pki agent certificate.

Prerequisites

  • You are logged-in to the RHCS machine as root user.
  • An admin/agent certificate (in this example the SubCA bootstrap certificate) is present in the nssdb.

Issuing the certificate via CMC

The user holding the bootstrap admin certificate/keys can now process the CSR sent from jsmith as follows:

  1. Place the CSR file (rsa_SubCA_AgentV.req) received from jsmith to the /root/.dogtag/pki_rsa_bootstrap/certs_db directory.

  2. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AgentV.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AgentV.req

### output: full path for the CMC request in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AgentV_pkcs10.req

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

### nickname: nickname for the user cert that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for the cert8.db that stores the user signing cert and keys
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10

### 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=false
identityProofV2.hashAlg=SHA-512
identityProofV2.macAlg=SHA-256-HMAC
request.privKeyId= _<private key id>_
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AgentV.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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 /root/.dogtag/pki_rsa_bootstrap/cmc.rsa_SubCA_AgentV_pkcs10.req
      Copy to Clipboard Toggle word wrap

  3. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AgentV_signed.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AgentV_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AgentV_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AgentV_signed.cfg

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

. . . Output omitted . . .

The response in binary format is stored in /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AgentV_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  4. Process the response using CMCResponse:

    Important

    Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

    # CMCResponse -v -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AgentV_pkcs10.resp -o /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AgentV_pkcs7.crt

Cert:0
...
===
Cert:1
...
===
Cert:2
...
===
Certificates:
    Certificate:
       Data:
           Version:  v3
           Serial Number: 0xE1E0F54

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
  OID: {1 3 6 1 5 5 7 7 25}
  BodyList: 1
  Status: SUCCESS
    Copy to Clipboard Toggle word wrap

  5. Copy the agent certificate to /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AgentV_b64.crt. 

    # pki -p 31443 ca-cert-export <rsa_SubCA_AgentV_serial_number> --output-file /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AgentV_b64.crt
    Copy to Clipboard Toggle word wrap
7.12.3.1.3. Creating the pki agent user and associating the new certificate
Copiar o link

  1. Create the rsa_SubCA_AgentV user: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-add --fullName="rsa_SubCA_AgentV" rsa_SubCA_AgentV
---------------------
Added user "rsa_SubCA_AgentV"
---------------------
 User ID: rsa_SubCA_AgentV
 Full name: rsa_SubCA_AgentV
    Copy to Clipboard Toggle word wrap

    Similarly:

    • For the KRA, use the kra-user-add command with the KRA’s admin nick, hostname and port to create the new user, e.g. KRA_AgentV.
    • For the OCSP, use the ocsp-user-add command with the OCSP’s admin nick, hostname and port to create the new user, e.g. OCSP_AgentV.

    If TMS is of interest,

    • For the TKS, use the tks-user-add command with the TKS’s admin nick, hostname and port to create the new user, e.g. TKS_AgentV.
    • For the TPS, use the tps-user-add command with the TPS’s admin nick, hostname and port to create the new user, e.g. TPS_AgentV.

  2. Add rsa_SubCA_AgentV to the Certificate Manager Agents group: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-group-member-add "Certificate Manager Agents" rsa_SubCA_AgentV
-----------------------------
Added group member "rsa_SubCA_AgentV"
-----------------------------
 User: rsa_SubCA_AgentV
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To add newly created users (e.g. KRA_AgentV) to the KRA’s agents group, use the kra-group-member-add command with the KRA’s admin nick, hostname, port and the group "Data Recovery Manager Agents".
    • To add newly created users (e.g. OCSP_AgentV) to the OCSP’s agents group, use the ocsp-group-member-add command with the OCSP’s admin nick, hostname, port and the group "Online Certificate Status Manager Agents".

    If TMS is of interest:

    • To add newly created users (e.g. TKS_AgentV) to the TKS’s agents group, use the tks-group-member-add command with the TKS’s admin nick, hostname, port and the group "Token Key Service Manager Agents".
    • To add newly created users (e.g. TPS_AgentV) to the TPS’s agents group, use the tps-group-member-add command with the TPS’s admin nick, hostname, port and the group "TPS Agents".

  3. Verify that the user rsa_SubCA_AgentV got added to the Certificate Manager Agents group. 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-group-member-find "Certificate Manager Agents"
-----------------
3 entries matched
-----------------
 User: caadmin

 User: pkidbuser

 User: rsa_SubCA_AgentV
----------------------------
Number of entries returned 3
----------------------------
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To verify membership in the KRA’s agents group, use the kra-group-member-find command with the KRA’s hostname, port, and the group "Data Recovery Manager Agents".
    • To verify membership in the OCSP’s agents group, use the ocsp-group-member-find command with the OCSP’s hostname, port, and the group "Online Certificate Status Manager Agents".

    If TMS is of interest:

    • To verify membership in the TKS’s agents group, use the tks-group-member-find command with the KRA’s hostname and port, and the group "Token Key Service Manager Agents".
    • To verify membership in the TPS’s agents group, use the tps-group-member-find command with the TPS’s hostname and port, and the group "TPS Agents".

  4. Add the rsa_SubCA_AgentV certificate to the pki role user: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-cert-add rsa_SubCA_AgentV --input /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AgentV_b64.crt

-------------------------------------------------------------------------------------------------------------------------------------
Added certificate "2;236851028;CN=CA Signing Certificate,OU=rhcs10-RSA-SubCA,O=Example-rhcs10-RSA-RootCA;CN=rsa_SubCA_AgentV,UID=rsa_SubCA_AgentV"
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To add certificates to users in the KRA and the OCSP, use respectively the kra-user-cert-add and the ocsp-user-cert-add commands with the corresponding subsystem’s hostname and port.

    If TMS is of interest:

    • To add certificates to users in the TKS and the TPS, use respectively the tks-user-cert-add and the tps-user-cert-add commands with the corresponding subsystem’s hostname and port.
  5. Send the certificate file, /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AgentV_pkcs7.crt, to the user (e.g. jsmith). The file can then be copied to the user location /home/jsmith/certs_db/rsa_SubCA_AgentV_pkcs7.crt to import in a later step.
7.12.3.1.4. Importing the pki agent certificate to the client nssdb
Copiar o link

This procedure is to be performed by the new pki agent user (e.g. jsmith) who has received the newly issued certificate file (e.g. /home/jsmith/certs_db/rsa_SubCA_AgentV_pkcs7.crt) from the bootstrap user, in this case, the root user.

  1. Login to rhcs10.example.com as an 'Agent' (a non-root user, for example jsmith).

  2. Install the rsa_SubCA_AgentV certificate: 

    $ pki -d /home/jsmith/certs_db -c SECret.123 pkcs7-import "rsa_SubCA_AgentV" --pkcs7 /home/jsmith/certs_db/rsa_SubCA_AgentV_pkcs7.crt
    Copy to Clipboard Toggle word wrap 
    $ certutil -d /home/jsmith/certs_db -L

Certificate Nickname              Trust Attributes
                                  SSL,S/MIME,JAR/XPI

. . . Output omitted . . .

rsa_SubCA_AgentV                  u,u,u
    Copy to Clipboard Toggle word wrap

  3. Backup the role user rsa_SubCA_AgentV certificate by creating a .p12 file, here for example with the password SECret.123: 

    $ pki -d /home/jsmith/certs_db -c SECret.123 client-cert-show "rsa_SubCA_AgentV" --pkcs12 /home/jsmith/certs_db/rsa_SubCA_AgentV.p12 --pkcs12-password SECret.123
    Copy to Clipboard Toggle word wrap
7.12.3.1.5. Initializing Browser for TLS mutual authentication
Copiar o link

Refer to section 2.4.1 "Browser Initialization" of the Administration Guide for importing the PKCS#12 file in order to initialize a Firefox browser for doing TLS mutual authentication.

7.12.4. Audit users
Copiar o link

  • auditV (this user will have a valid certificate throughout testing)

7.12.4.1. Setting up certificate and role for a pki auditor
Copiar o link

The following example procedure will create a CMC signed user certificate, rsa_SubCA_AuditV, for the auditor user aguru. This CMC request will be signed using the SubCA bootstrap administrator certificate in the next section.

7.12.4.1.1. Generating a CSR for a pki auditor
Copiar o link

This procedure, to be performed by a pki auditor, (e.g. Astrid Guru, aguru), aims to create a CSR for this user.

  • Login to rhcs10.example.com as an 'Auditor' (a non-root user, for example aguru).

    1. Create a client nssdb if it does not already exist: 

      $ pki -d /home/aguru/certs_db -c SECret.123 client-init
      Copy to Clipboard Toggle word wrap

    2. Use the PKCS10Client tool to generate a PKCS#10 Certificate Request:

      Note

      Change the subjectDN and the .req file name as appropriate for each subsystem, example: OCSP_AuditV, KRA_AuditV etc. 

      $ PKCS10Client -d /home/aguru/certs_db -p SECret.123 -n "cn=rsa_SubCA_AuditV, uid=rsa_SubCA_AuditV" -o /home/aguru/certs_db/rsa_SubCA_AuditV.req

PKCS10Client: Certificate request written into /home/aguru/certs_db/rsa_SubCA_AuditV.req
PKCS10Client: PKCS#10 request key id written into /home/aguru/certs_db/rsa_SubCA_AuditV.req.keyId
      Copy to Clipboard Toggle word wrap

      The aguru user should send the certificate request (CSR) /home/aguru/certs_db/rsa_SubCA_AuditV.req to a pki agent user to CMC sign and approve the request. You could use the newly appointed example pki agent jsmith or the root user that holds the bootstrap certificate/keys; in this example we will just use the root user.

7.12.4.1.2. Approving the CSR for a pki audit user
Copiar o link

This section describes the procedure to be performed by the user who holds the SubCA’s bootstrap admin certificate, e.g. the root user. It demonstrates how to process the CSR (created by aguru in the previous section) to issue the pki auditor certificate.

Prerequisites

  • You are logged-in to the RHCS machine as root user.
  • An admin/agent certificate (in this example the SubCA bootstrap certificate) is present in the nssdb.

Issuing the certificate via CMC

  1. Place the CSR file (rsa_SubCA_AuditV.req) received from aguru to the /root/.dogtag/pki_rsa_bootstrap/certs_db directory.

  2. Generate a CMC request:

    1. Create a CMCRequest configuration file. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AuditV.cfg
      Copy to Clipboard Toggle word wrap 
      ### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AuditV.req

### output: full path for the CMC request in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AuditV_pkcs10.req

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

### nickname: nickname for the user cert that will be used to sign the CMC full request.
nickname=PKI Bootstrap Administrator for RSA-SubCA

### dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### password: password for the cert8.db that stores the user signing cert and keys
password=SECret.123

### format: request format, either pkcs10 or crmf
format=pkcs10

### 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=false
identityProofV2.hashAlg=SHA-512
identityProofV2.macAlg=SHA-256-HMAC
request.privKeyId= _<private key id>_
      Copy to Clipboard Toggle word wrap

    2. Generate the request using the CMCRequest command: 

      # CMCRequest /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AuditV.cfg

cert/key prefix =
path = /root/.dogtag/pki_rsa_bootstrap/certs_db
CryptoManger initialized
token internal logged in...
got signerCert: PKI Bootstrap Administrator for RSA-SubCA
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 /root/.dogtag/pki_rsa_bootstrap/cmc.rsa_SubCA_AuditV_pkcs10.req
      Copy to Clipboard Toggle word wrap

  3. Submit the CMC request:

    1. Create a HttpClient configuration file. For example: 

      # vi /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AuditV_signed.cfg
      Copy to Clipboard Toggle word wrap 
      ### host: host name for the http server
host=rhcs10.example.com

### port: port number
port=31443

### 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=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AuditV_pkcs10.req

### output: full path for the response in binary format
output=/root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AuditV_pkcs10.resp

### tokenname: name of the token where the SSL client authentication cert can be found (default is internal)
### This parameter will be ignored if secure=false
tokenname=internal

### dbdir: directory for cert8.db, key3.db and secmod.db
### This parameter will be ignored if secure=false
dbdir=/root/.dogtag/pki_rsa_bootstrap/certs_db

### clientmode: true for client authentication, false for no client authentication
### This parameter will be ignored if secure=false
clientmode=true

### password: password for cert8.db
### This parameter will be ignored if secure=false and clientauth=false
password=SECret.123

### nickname: nickname for client certificate
### This parameter will be ignored if clientmode=false
nickname=PKI Bootstrap Administrator for RSA-SubCA

### servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
      Copy to Clipboard Toggle word wrap

    2. Submit the request using the HttpClient command: 

      # HttpClient /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AuditV_signed.cfg

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

. . . Output omitted . . .

The response in binary format is stored in /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AuditV_pkcs10.resp
      Copy to Clipboard Toggle word wrap

  4. Process the response using CMCResponse to display all certificates in chain individually in PEM format:

    Important

    Running CMCResponse with the "-v" option returns the PEM of each certificate in the chain as Cert:0, Cert:1 etc. Below all the PEMs, the output also displays each certificate in the chain in pretty print format. Since the certificates are not displayed in a fixed order, in order to determine their position in the chain, you must examine the "Subject:" under each "Certificate". The corresponding PEM is displayed in the same position above. 

    # CMCResponse -v -d /root/.dogtag/pki_rsa_bootstrap/certs_db -i /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.rsa_SubCA_AuditV_pkcs10.resp -o /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AuditV_pkcs7.crt

Certificates:
    Certificate:
       Data:
           Version:  v3
           Serial Number: 0xD107903
           Signature Algorithm: SHA512withRSA - 1.2.840.113549.1.1.13
           Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
           Validity:
               Not Before: Sunday, January 7, 2018 1:12:52 PM EST America/New_York
               Not  After: Friday, July 6, 2018 1:12:52 PM EDT America/New_York
           Subject: CN=rsa_SubCA_AuditV,UID=rsa_SubCA_AuditV

. . . Output omitted . . .

Number of controls is 1
Control #0: CMCStatusInfoV2
  OID: {1 3 6 1 5 5 7 7 25}
  BodyList: 1
  Status: SUCCESS
    Copy to Clipboard Toggle word wrap

  5. Copy the auditor certificate to /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AuditV_b64.crt: 

    # pki -p 31443 ca-cert-export <rsa_SubCA_AuditV_serial_number> --output-file /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AuditV_b64.crt
    Copy to Clipboard Toggle word wrap
7.12.4.1.3. Creating the pki auditor user and associating the new certificate
Copiar o link

This procedure is to be performed by an existing pki admin user, in this case, the root user that holds the SubCA bootstrap certificate.

  1. Create the rsa_SubCA_AuditV user: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-add --fullName="rsa_SubCA_AuditV" rsa_SubCA_AuditV
---------------------
Added user "rsa_SubCA_AuditV"
---------------------
 User ID: rsa_SubCA_AuditV
 Full name: rsa_SubCA_AuditV
    Copy to Clipboard Toggle word wrap

    Similarly:

    • For the KRA, use the kra-user-add command with the KRA’s admin nick, hostname and port to create the new user, e.g. KRA_AuditV.
    • For the OCSP, use the ocsp-user-add command with the OCSP’s admin nick, hostname and port to create the new user, e.g. OCSP_AuditV.

    If TMS is of interest:

    • For the TKS, use the tks-user-add command with the TKS’s admin nick, hostname and port to create the new user, e.g. TKS_AuditV.
    • For the TPS, use the tps-user-add command with the TPS’s admin nick, hostname and port to create the new user, e.g. TPS_AuditV.

  2. Add rsa_SubCA_AuditV to the Auditors group: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-group-member-add "Auditors" rsa_SubCA_AuditV
-----------------------------
Added group member "rsa_SubCA_AuditV"
-----------------------------
 User: rsa_SubCA_AuditV
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To add newly created users (e.g. KRA_AuditV) to the KRA’s auditors group, use the kra-group-member-add command with the KRA’s admin nick, hostname, and port.
    • To add newly created users (e.g. OCSP_AuditV) to the OCSP’s auditors group, use the ocsp-group-member-add command with the OCSP’s admin nick, hostname, and port.

    If TMS is of interest:

    • To add newly created users (e.g. TKS_AuditV) to the TKS’s auditors group, use the tks-group-member-add command with the TKS’s admin nick, hostname, and port.
    • To add newly created users (e.g. TPS_AuditV) to the TPS’s auditors group, use the tps-group-member-add command with the TPS’s admin nick, hostname, and port.

  3. Verify that the user rsa_SubCA_AuditV got added to the Auditors group. 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-group-member-find "Auditors"
-----------------
1 entries matched
-----------------
 User: rsa_SubCA_AuditV
----------------------------
Number of entries returned 1
----------------------------
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To verify membership in the KRA’s auditors group, use the kra-group-member-find command with the KRA’s hostname and port.
    • To verify membership in the OCSP’s auditors group, use the ocsp-group-member-find command with the OCSP’s hostname and port.

    If TMS is of interest:

    • To verify membership in the TKS’s auditors group, use the tks-group-member-find command with the TKS’s hostname and port.
    • To verify membership in the TPS’s auditors group, use the tps-group-member-find command with the TPS’s hostname and port.

  4. Add the rsa_SubCA_AuditV certificate to the pki role user: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-SubCA" -c SECret.123 -h "rhcs10.example.com" -p 31443 ca-user-cert-add rsa_SubCA_AuditV --input /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AuditV_b64.crt

-------------------------------------------------------------------------------------------------------------------------------------
Added certificate "2;236851028;CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA;CN=rsa_SubCA_AuditV,UID=rsa_SubCA_AuditV"
    Copy to Clipboard Toggle word wrap

    Similarly:

    • To add certificates to users in the KRA and the OCSP, use respectively the kra-user-cert-add and the ocsp-user-cert-add commands with the corresponding subsystem’s hostname and port.

    If TMS is of interest:

    • To add certificates to users in the TKS and the TPS, use respectively the tks-user-cert-add and the tps-user-cert-add commands with the corresponding subsystem’s hostname and port.
  5. Send the certificate file /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AuditV_pkcs7.crt, to the user (e.g. aguru). The file can then be copied to the user location /home/aguru/certs_db/rsa_SubCA_AuditV_pkcs7.crt to import in a later step.
7.12.4.1.4. Importing the pki audit certificate to the client nssdb
Copiar o link

This section is to be performed by the new pki auditor user (e.g. aguru) who has received the newly issued certificate file (e.g. /home/aguru/certs_db/rsa_SubCA_AuditV_pkcs7.crt) from the bootstrap user, in this case, the root user.

  1. Login to rhcs10.example.com as an 'Auditor' (a non-root user, for example aguru).

  2. Install the rsa_SubCA_AuditV certificate: 

    $ pki -d /home/aguru/certs_db -c SECret.123 pkcs7-import "rsa_SubCA_AuditV" --pkcs7 /home/aguru/certs_db/rsa_SubCA_AuditV_pkcs7.crt
    Copy to Clipboard Toggle word wrap 
    $ certutil -d /home/aguru/certs_db -L

Certificate Nickname              Trust Attributes
                                  SSL,S/MIME,JAR/XPI

. . . Output omitted . . .

rsa_SubCA_AuditV                  u,u,u
    Copy to Clipboard Toggle word wrap

  3. Backup the role user rsa_SubCA_AuditV certificate by creating a .p12 file, here for example with the password SECret.123: 

    $ pki -d /home/aguru/certs_db -c SECret.123 client-cert-show "rsa_SubCA_AuditV" --pkcs12 /home/aguru/certs_db/rsa_SubCA_AuditV.p12 --pkcs12-password SECret.123
    Copy to Clipboard Toggle word wrap

7.12.5. TPS operators
Copiar o link

The process for TPS operators is similar to the process for Auditors.

Note

Follow the instructions in this section only when you are certain that for each RHCS subsystem, at least one admin user has been created and successfully tested to be able to perform administrator functions.

  1. List the certificates in the authentication nssdb to determine the installed bootstrap admin certificates for the SubCA, KRA and OCSP. For example: 

    # certutil -d /root/.dogtag/pki_rsa_bootstrap/certs_db -L

Certificate Nickname                             Trust Attributes
                                                 SSL,S/MIME,JAR/XPI

PKI Bootstrap Administrator for RSA-RootCA       u,u,u
PKI Bootstrap Administrator for RSA-SubCA        u,u,u
PKI Bootstrap Administrator for RSA-OCSP-rootca  u,u,u
PKI Bootstrap Administrator for RSA-OCSP-subca   u,u,u
PKI Bootstrap Administrator for RSA-KRA          u,u,u
    Copy to Clipboard Toggle word wrap

  2. Delete the SubCA, OCSP and KRA bootstrap admin user certificates: 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-SubCA"
    Copy to Clipboard Toggle word wrap 
    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-OCSP-rootca"
    Copy to Clipboard Toggle word wrap 
    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-OCSP-subca"
    Copy to Clipboard Toggle word wrap 
    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-KRA"
    Copy to Clipboard Toggle word wrap

  3. Optional: If TMS is of interest, you can remove the TKS and TPS bootstrap admin users in the same manner. 

    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-TKS"
    Copy to Clipboard Toggle word wrap 
    # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-TPS"
    Copy to Clipboard Toggle word wrap

Disabling multi-role support

The bootstrap user came with multiple roles (admin, agent, and auditor). Now that you have replaced the bootstrap user with single-role privileged users, you can safely disable the multi-roles ability by following Section 15.1, “Disabling multi-roles support”.

7.13. Post-installation
Copiar o link

This chapter describes the post-installation tasks that take place after the subsystems installation.

Once you have completed the installation using the pkispawn utility, certain actions are then either required or strongly recommended. In addition, some optional actions would also be helpful, depending on the site’s preferences.

For optional procedures, see Part III, “Part III: Configuring Red Hat Certificate System”. Useful post-installation-step procedures include:

For required or strongly recommended procedures, perform the actions described below.

Important

The configuration changes will not take effect until the you start or restart the instance. In general, you should make sure all CS instances are stopped before performing all the OS file system level post-installation configuration. Once done, you can then restart the instances.

7.13.1. Setting date and time for RHCS
Copiar o link

It is important to have the time set up correctly for running RHCS. The system time is always kept in Coordinated Universal Time (UTC) and converted in applications to local time as needed. Local time is the actual time in your current time zone, taking into account daylight saving time (DST).

The timedatectl utility is distributed as part of the systemd system and service manager and allows you to review and change the configuration of the system clock.

  • To change the current time: 

    # timedatectl set-time HH:MM:SS
    Copy to Clipboard Toggle word wrap

    Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form.

  • To change the current date: 

    # timedatectl set-time YYYY-MM-DD
    Copy to Clipboard Toggle word wrap

    Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month.

  • To set the time zone:

    1. First, display the list of available time zones: 

      # timedatectl list-timezones
      Copy to Clipboard Toggle word wrap

    2. Based on the above list, set your desired time zone with this command: 

      # timedatectl set-timezone <your_preferred_timezone>
      Copy to Clipboard Toggle word wrap

The time change is audited by the operating system. For more information see Section 13.2.1.3, “Auditing time change events”.

7.13.2. Configuring session timeout
Copiar o link

Various timeout configurations exist on the system that could affect how long a TLS session is allowed to remain idle before termination. For details, see Section 9.4.2, “Session timeout”.

By default, the SubjectKeyIdentifier extension, when set in the enrollment profile, is computed by using SHA-1. To set it to another algorithm, you will need to edit the enrollment profile. For example:

  1. Open the enrollment profile for the certificate: 

    # vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCcaCert.cfg
    Copy to Clipboard Toggle word wrap

  2. Add the following parameter: 

    policyset.caCertSet.8.default.params.messageDigest=SHA-256
    Copy to Clipboard Toggle word wrap
  3. Save the file and restart the CA.
Note

Make sure the SubjectKeyIdentifierExtension comes before the AuthorityKeyIdentifierExtension. If not, just adjust the position in the list parameter, e.g. if 8 is the SubjectKeyIdentifierExtension, and 4 is the AuthorityKeyIdentifierExtension, then the following would place 8 before 4 in the list: 

policyset.caCertSet.list=1,2,3,8,4,5,6,9,10
Copy to Clipboard Toggle word wrap

7.13.4. Configuration for CMC enrollment and revocation (CA)
Copiar o link

You can do certificate enrollments and revocation via CMC. The configuration is described in Section 9.6, “Configuration for CMC”. Specifically:

7.13.5. Enable Nuxwdog (watchdog service)
Copiar o link

The watchdog (nuxwdog) service provides secure system password management. For more details, see Section 9.3.2.1, “Enabling the watchdog service”. This section describes how to enable the Nuxwdog watchdog for each instance.

7.13.5.1. Enable Nuxwdog for the RootCA
Copiar o link

The following procedure provides the steps required to enable Nuxwdog on the RootCA instance.

Prerequisites

  • You are logged in to rhcs10.example.com as root.
  • Make sure the instance is stopped. If not, stop it using the systemctl stop pki-tomcatd@rhcs10-RSA-RootCA.service command.

Procedure

  1. Add the cms.tokenList=<HSM_TOKEN_NAME> parameter to CS.cfg, for example: 

    # cat /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg | grep cms.tokenList

cms.tokenList=NHSM-CONN-XC
    Copy to Clipboard Toggle word wrap

  2. Move the password file to another directory: 

    # mv /var/lib/pki/rhcs10-RSA-RootCA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
    Copy to Clipboard Toggle word wrap

  3. Enable the Nuxwdog service: 

    # pki-server instance-nuxwdog-enable rhcs10-RSA-RootCA
---------------------------
Nuxwdog enabled for instance rhcs10-RSA-RootCA.
---------------------------
    Copy to Clipboard Toggle word wrap

  4. Start the instance using the Nuxwdog service. You will be prompted for passwords, which can be found in the password.conf file that you were instructed to save (~/<YOUR_PREFERRED_DIR>/) in an earlier step. Note that once you have successfully enabled Nuxwdog, the CS instance start/stop/restart/status command differs: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service

[rhcs10-RSA-RootCA] Please provide the password for internal: *****
[rhcs10-RSA-RootCA] Please provide the password for hardware-NHSM-CONN-XC: *****
    Copy to Clipboard Toggle word wrap

Verification steps:

  • Check the status of the RootCA instance using Nuxwdog: 

    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service

● pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service - PKI Tomcat Server rhcs10-RSA-RootCA
Started by Nuxwdog
  Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
  Active: active (running) since …
    Copy to Clipboard Toggle word wrap

7.13.5.2. Enable Nuxwdog for the SubCA
Copiar o link

The following procedure provides the steps required to enable Nuxwdog on the SubCA instance.

Prerequisites

  • You are logged in to rhcs10.example.com as root.
  • Make sure the instance is stopped. If not, stop it using the systemctl stop pki-tomcatd@rhcs10-RSA-SubCA.service command.

Procedure

  1. Add the cms.tokenList=<HSM_TOKEN_NAME> parameter to CS.cfg, for example: 

    # cat /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg | grep cms.tokenList

cms.tokenList=NHSM-CONN-XC
    Copy to Clipboard Toggle word wrap

  2. Move the password file to another directory: 

    # mv /var/lib/pki/rhcs10-RSA-SubCA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
    Copy to Clipboard Toggle word wrap

  3. Enable the Nuxwdog service: 

    # pki-server instance-nuxwdog-enable rhcs10-RSA-SubCA
---------------------------
Nuxwdog enabled for instance rhcs10-RSA-SubCA.
---------------------------
    Copy to Clipboard Toggle word wrap

  4. Start the instance using the Nuxwdog service. Note that once you have successfully enabled Nuxwdog, the CS instance start/stop/restart/status command differs: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service

[rhcs10-RSA-SubCA] Please provide the password for internal: *****
[rhcs10-RSA-SubCA] Please provide the password for hardware-NHSM-CONN-XC: *****
[rhcs10-RSA-SubCA] Please provide the password for Rule SharedToken: ******
    Copy to Clipboard Toggle word wrap

Verification steps:

  • Check the status of the SubCA instance using Nuxwdog: 

    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service

● pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service - PKI Tomcat Server rhcs10-RSA-SubCA
Started by Nuxwdog
  Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
  Active: active (running) since …
    Copy to Clipboard Toggle word wrap

7.13.5.3. Enable Nuxwdog for the OCSPs
Copiar o link

The following procedure provides the steps required to enable Nuxwdog on the OCSP instances.

Prerequisites

  • You are logged in to rhcs10.example.com as root.
  • Make sure the instance is stopped. If not, stop it, for example using systemctl stop pki-tomcatd@rhcs10-RSA-OCSP-rootca.service or systemctl stop pki-tomcatd@rhcs10-RSA-OCSP-subca.service for the relevant instance.

Procedure

For example, for the RootCA’s OCSP:

  1. Add the cms.tokenList=<TOKEN_NAME> parameter to CS.cfg, for example: 

    # cat /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/conf/CS.cfg | grep cms.tokenList

cms.tokenList=NHSM-CONN-XC
    Copy to Clipboard Toggle word wrap

  2. Move the password file to another directory: 

    # mv /var/lib/pki/rhcs10-RSA-OCSP-rootca/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
    Copy to Clipboard Toggle word wrap

  3. Enable the Nuxwdog service: 

    # pki-server instance-nuxwdog-enable rhcs10-RSA-OCSP-rootca/
---------------------------
Nuxwdog enabled for instance rhcs10-RSA-OCSP-rootca/.
---------------------------
    Copy to Clipboard Toggle word wrap

  4. Start the instance using the Nuxwdog service: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service

[rhcs10-RSA-OCSP-rootca/] Please provide the password for internal: *****
[rhcs10-RSA-OCSP-rootca/] Please provide the password for hardware-NHSM-CONN-XC: *****
    Copy to Clipboard Toggle word wrap
  5. Repeat the above procedure for the SubCA’s OCSP by adapting the instance’s name, e.g. using rhcs10-RSA-OCSP-subca.

Verification

  • Check the status of the OCSP instances using Nuxwdog: 

    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service

● pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service - PKI Tomcat Server rhcs10-RSA-OCSP-rootca/
Started by Nuxwdog
  Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
  Active: active (running) since …
    Copy to Clipboard Toggle word wrap 
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service

● pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca/.service - PKI Tomcat Server rhcs10-RSA-OCSP-subca/
Started by Nuxwdog
  Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
  Active: active (running) since …
    Copy to Clipboard Toggle word wrap

7.13.5.4. Enable Nuxwdog for the KRA
Copiar o link

The following procedure provides the steps required to enable Nuxwdog on the KRA instance.

Prerequisites

  • You are logged in to rhcs10.example.com as root.
  • Make sure the instance is stopped. If not, stop it using the systemctl stop pki-tomcatd@rhcs10-RSA-KRA.service command.

Procedure

  1. Add the cms.tokenList=<TOKEN_NAME> parameter to the CS.cfg file, for example: 

    # cat /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg | grep cms.tokenList

cms.tokenList=NHSM-CONN-XC
    Copy to Clipboard Toggle word wrap

  2. Move the password file to another directory: 

    # mv /var/lib/pki/rhcs10-RSA-KRA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
    Copy to Clipboard Toggle word wrap

  3. Enable the Nuxwdog service: 

    # pki-server instance-nuxwdog-enable rhcs10-RSA-KRA
---------------------------
Nuxwdog enabled for instance rhcs10-RSA-KRA.
---------------------------
    Copy to Clipboard Toggle word wrap

  4. Start the instance using the Nuxwdog service: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service

[rhcs10-RSA-KRA] Please provide the password for internal: *****
[rhcs10-RSA-KRA] Please provide the password for hardware-NHSM-CONN-XC: *****
    Copy to Clipboard Toggle word wrap

Verification steps:

  • Check the status of the KRA instance using Nuxwdog: 

    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service

● pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service - PKI Tomcat Server rhcs10-RSA-KRA
Started by Nuxwdog
  Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
  Active: active (running) since …
    Copy to Clipboard Toggle word wrap

7.13.5.5. Enable Nuxwdog for the TKS
Copiar o link

The following procedure provides the steps required to enable Nuxwdog on the TKS instance.

Prerequisites

  • You are logged in to rhcs10.example.com as root.
  • Make sure the instance is stopped. If not, stop it using the systemctl stop pki-tomcatd@rhcs10-RSA-TKS.service command.

Procedure

  1. Add the cms.tokenList=<TOKEN_NAME> parameter to the CS.cfg file, for example: 

    # cat /var/lib/pki/rhcs10-RSA-TKS/TKS/conf/CS.cfg | grep cms.tokenList

cms.tokenList=NHSM-CONN-XC
    Copy to Clipboard Toggle word wrap

  2. Move the password file to another directory: 

    # mv /var/lib/pki/rhcs10-RSA-TKS/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
    Copy to Clipboard Toggle word wrap

  3. Enable the Nuxwdog service: 

    # pki-server instance-nuxwdog-enable rhcs10-RSA-TKS
---------------------------
Nuxwdog enabled for instance rhcs10-RSA-TKS.
---------------------------
    Copy to Clipboard Toggle word wrap

  4. Start the instance using the Nuxwdog service: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-TKS.service

[rhcs10-RSA-TKS] Please provide the password for internal: *****
[rhcs10-RSA-TKS] Please provide the password for hardware-NHSM-CONN-XC: *****
    Copy to Clipboard Toggle word wrap

Verification steps:

  • Check the status of the TKS instance using Nuxwdog: 

    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-TKS.service

● pki-tomcatd-nuxwdog@rhcs10-RSA-TKS.service - PKI Tomcat Server rhcs10-RSA-TKS
Started by Nuxwdog
  Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
  Active: active (running) since …
    Copy to Clipboard Toggle word wrap

7.13.5.6. Enable Nuxwdog for the TPS
Copiar o link

The following procedure provides the steps required to enable Nuxwdog on the TPS instance.

Prerequisites

  • You are logged in to rhcs10.example.com as root.
  • Make sure the instance is stopped. If not, stop it using the systemctl stop pki-tomcatd@rhcs10-RSA-TPS.service command.

Procedure

  1. Add the cms.tokenList=<TOKEN_NAME> parameter to the CS.cfg file, for example: 

    # cat /var/lib/pki/rhcs10-RSA-TPS/TPS/conf/CS.cfg | grep cms.tokenList

cms.tokenList=NHSM-CONN-XC
    Copy to Clipboard Toggle word wrap

  2. Move the password file to another directory: 

    # mv /var/lib/pki/rhcs10-RSA-TPS/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
    Copy to Clipboard Toggle word wrap

  3. Enable the Nuxwdog service: 

    # pki-server instance-nuxwdog-enable rhcs10-RSA-TPS
---------------------------
Nuxwdog enabled for instance rhcs10-RSA-TPS.
---------------------------
    Copy to Clipboard Toggle word wrap

  4. Start the instance using the Nuxwdog service: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-TPS.service

[rhcs10-RSA-TPS] Please provide the password for internal: *****
[rhcs10-RSA-TPS] Please provide the password for hardware-NHSM-CONN-XC: *****
    Copy to Clipboard Toggle word wrap

Verification steps:

  • Check the status of the TPS instance using Nuxwdog: 

    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-TPS.service

● pki-tomcatd-nuxwdog@rhcs10-RSA-TPS.service - PKI Tomcat Server rhcs10-RSA-TPS
Started by Nuxwdog
  Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
  Active: active (running) since …
    Copy to Clipboard Toggle word wrap

7.13.6. Configure pkiconsole login with client authentication
Copiar o link

This section describes configuring pkiconsole login with client authentication. In the following configuration, the instance can be either CA, OCSP, KRA or TKS.

Prerequisite configuration

You must configure each CS instance to allow for pkiconsole TLS connections.

  1. Login to rhcs10.example.com as root.

  2. Stop the server that needs a console login with client authentication. 

    # pki-server stop rhcs10-<INSTANCE>
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
    Copy to Clipboard Toggle word wrap

  3. Change directory at /var/lib/pki/<instance name>/<subsystem>/conf. For example, if changing to the RootCA conf directory: 

    # cd /var/lib/pki/rhcs10-RSA-RootCA/ca/conf
    Copy to Clipboard Toggle word wrap

  4. Modify the CS.cfg file to change the authType from pwd to sslclientauth, e.g.: 

    authType=sslclientauth
    Copy to Clipboard Toggle word wrap
    NOTE

    Alternatively, you can add the line authType=sslclientauth to the CS.cfg using the config-set commands. For example, use ca-config-set to add to the RootCA: 

    # pki-server ca-config-set -i rhcs10-RSA-RootCA authType sslclientauth
    Copy to Clipboard Toggle word wrap

  5. Start the server: 

    # pki-server start rhcs10-<INSTANCE>
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
    Copy to Clipboard Toggle word wrap

Procedure

Each RHCS administrator needs to perform some setup prior to using pkiconsole with TLS connections.

  1. Login to rhcs10.example.com as a non-root admin user (for example: jgenie).
  2. The bootstrap admin user should provide the SubCA and RootCA signing certificates to jgenie. After receiving the contents of /opt/pki_rsa/subCA.pem and /opt/pki_rsa/rootCA.pem on rhcs10.example.com, jgenie should copy them into /home/jgenie/certs_db/rsa_subCA.pem and /home/jgenie/certs_db/rsa_rootCA.pem respectively.

  3. Create a nssdb, if it does not already exist: 

    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-init
    Copy to Clipboard Toggle word wrap

  4. Import the role user certificate (e.g. /home/jgenie/certs_db/rsa_SubCA_AdminV.p12): 

    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-cert-import --pkcs12 /home/jgenie/certs_db/rsa_SubCA_AdminV.p12 --pkcs12-password SECret.123
    Copy to Clipboard Toggle word wrap

  5. Import the CA certificates: 

    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-SubCA" --ca-cert /home/jgenie/certs_db/rsa_subCA.pem
-------------------------------------
Imported certificate "CA Signing Cert - rhcs10-RSA-SubCA"
-------------------------------------
    Copy to Clipboard Toggle word wrap 
    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-RootCA" --ca-cert /home/jgenie/certs_db/rsa_rootCA.pem
-------------------------------------
Imported certificate "CA Signing Cert - rhcs10-RSA-RootCA"
-------------------------------------
    Copy to Clipboard Toggle word wrap

Verification:

  • Verify the admin user certificate for authentication against the server. For example: 

    $ pki -U https://rhcs10.example.com:31443 -d /home/jgenie/.redhat-idm-console -c SECret.123 -n rsa_SubCA_AdminV ca-user-find
    Copy to Clipboard Toggle word wrap

    1. Verify that pkiconsole can connect to the ca using client authentication:

      1. Login as a pki admin user (e.g. jgenie), for example: 

        $ ssh -X jgenie@rhcs10.example.com
        Copy to Clipboard Toggle word wrap

      2. Run pkiconsole. For example: 

        $ pkiconsole -d /home/jgenie/.redhat-idm-console -n rsa_SubCA_AdminV https://rhcs10.example.com:31443/ca
        Copy to Clipboard Toggle word wrap
Note

If you see the error No X11 DISPLAY variable was set, but this program performed an operation which requires it upon launching pkiconsole, try the following steps:

  1. Install xauth as a root user on rhcs10.example.com: 

    # dnf install xauth
    Copy to Clipboard Toggle word wrap

  2. Login again as a RHCS admin user to run pkiconsole. For example: 

    # ssh -X jgenie@rhcs10.example.com
    Copy to Clipboard Toggle word wrap 
    # pkiconsole -d /home/jgenie/.redhat-idm-console -n rsa_SubCA_AdminV https://rhcs10.example.com:31443/ca
    Copy to Clipboard Toggle word wrap

7.13.7. Enable signed audit Logging
Copiar o link

Prerequisite

  • You are logged onto rhcs10.example.com as root user.

Procedure

  1. Stop the instance. For example, for the KRA: 

    # pki-server stop rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-KRA.service
    Copy to Clipboard Toggle word wrap

  2. Set the log.instance.SignedAudit.logSigning attribute to true in the CS.cfg file (false by default). For example: 

    # vi /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg
    Copy to Clipboard Toggle word wrap 
    log.instance.SignedAudit.logSigning=true
    Copy to Clipboard Toggle word wrap

  3. Start the instance. For example: 

    # pki-server start rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-KRA.service
    Copy to Clipboard Toggle word wrap
Note

You can also do audit log signing via CLI. See "Enabling signed audit logging" in the Installation Guide.

7.13.8. Retrieve the audit log file (Auditors)
Copiar o link

Auditors (e.g - rsa_SubCA_AuditV) can access the signed audit logs using the following procedure.

Procedure

  1. Login to rhcs10.example.com as an Auditor (a non-root user, e.g. - aguru). 

    $ certutil -d /home/aguru/certs_db -L

Certificate Nickname                      Trust Attributes
                                          SSL,S/MIME,JAR/XPI

. . . Output omitted . . .

rsa_SubCA_AuditV                          u,u,u
CA Signing Cert - rhcs10-RSA-RootCA       CT,C,C
    Copy to Clipboard Toggle word wrap

  2. List the available audit log files: 

    $ pki -d /home/aguru/certs_db -n "rsa_SubCA_AuditV" -c SECret.123 -p 31443 -h `hostname` ca-audit-file-find
-----------------
1 entries matched
-----------------
  File name: ca_audit
  Size: 1184345
----------------------------
Number of entries returned 1
----------------------------
    Copy to Clipboard Toggle word wrap

    In this example, there is only one file, ca_audit, but you can have multiple audit log files.

  3. As an Auditor, retrieve the audit log file and store it locally: 

    $ pki -d /home/aguru/certs_db -n "rsa_SubCA_AuditV" -c SECret.123 -p 31443 -h `hostname` ca-audit-file-retrieve ca_audit --output /home/aguru/certs_db/ca_audit
    Copy to Clipboard Toggle word wrap

    If you have multiple log files, retrieve them one by one.

  4. Verify the signed audit logs using the AuditVerify tool:

    1. Import the SubCA audit signing certificate to the nssdb: 

      $ pki -p 31443 -h `hostname` ca-cert-find --name "CA Audit Signing Certificate"
---------------
1 entries found
---------------
  Serial Number: 0xe8e47bf

. . . Output omitted . . .
      Copy to Clipboard Toggle word wrap 
      $ pki -d /home/aguru/certs_db -c SECret.123 -p 31443 -h hostname client-cert-import "SubCA Audit Signing Certificate" --serial 0xe8e47bf --trust ",,P"
---------------------------------------------------
Imported certificate "SubCA Audit Signing Certificate"
---------------------------------------------------
      Copy to Clipboard Toggle word wrap

    2. Create a file containing a list of audit log files in chronological order: 

      $ cat > /home/aguru/certs_db/audit.txt << EOF
ca_audit
EOF
      Copy to Clipboard Toggle word wrap

    3. Run the AuditVerify tool: 

      $ cd /home/aguru/certs_db/
      Copy to Clipboard Toggle word wrap 
      $ AuditVerify -d /home/aguru/certs_db -n "SubCA Audit Signing Certificate" -a audit.txt
      Copy to Clipboard Toggle word wrap

7.13.9. Enable OS-level (Operational Environment) audit logs
Copiar o link

The auditd logging framework provides many additional audit capabilities. These OS-level (Operational Environment) audit logs complement functionality provided by Certificate System directly.

Prerequisites

  • Before performing any of the steps in this section, make sure the audit package is installed: 

    # dnf install audit
    Copy to Clipboard Toggle word wrap
Important

Make sure the file /etc/audit/rules.d/audit.rules remains present on the system with the following content: 

# cat /etc/audit/rules.d/audit.rules
## First rule - delete all
-D
## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192
## This determine how long to wait in burst of events
--backlog_wait_time 60000
## Set failure mode to syslog
-f 1
Copy to Clipboard Toggle word wrap

Auditing Certificate System audit log deletion

To receive audit events for when audit logs are deleted, you need to audit system calls whose targets are Certificate System logs.

  1. Create the file /etc/audit/rules.d/rhcs-audit-log-deletion.rules with the following contents: 

    -a always,exit -F arch=b32 -S unlink -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b32 -S rename -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b32 -S rmdir -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b32 -S unlinkat -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b32 -S renameat -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b64 -S unlink -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b64 -S rename -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b64 -S rmdir -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b64 -S unlinkat -F dir=/var/log/pki -F key=rhcs_audit_deletion
-a always,exit -F arch=b64 -S renameat -F dir=/var/log/pki -F key=rhcs_audit_deletion
    Copy to Clipboard Toggle word wrap

  2. Then restart the auditd service: 

    # service auditd restart
    Copy to Clipboard Toggle word wrap

Auditing unauthorized Certificate System use of secret keys

To receive audit events for all access to Certificate System Secret or Private keys, you need to audit the file system access to the nssdb.

  1. Create the /etc/audit/rules.d/rhcs-audit-nssdb-access.rules file with the following contents, replacing <instance name> with the current instance: 

    -w /etc/pki/<instance name>/alias -p warx -k rhcs_audit_nssdb
    Copy to Clipboard Toggle word wrap

  2. For each file (<file>) in /etc/pki/<instance name>/alias, add the following line to /etc/audit/rules.d/rhcs-audit-nssdb-access.rules: 

    -w /etc/pki/<instance name>/alias/<file> -p warx -k rhcs_audit_nssdb
    Copy to Clipboard Toggle word wrap

    For example, if files on the rhcs10-RSA-SubCA instance are cert8.db, key3.db, NHSM-CONN-XCcert8.db, NHSM-CONN-XCkey3.db, and secmod.db, then the configuration file would contain: 

    -w /etc/pki/rhcs10-RSA-SubCA/alias/ -p warx -k rhcs_audit_nssdb
-w /etc/pki/rhcs10-RSA-SubCA/alias/ca.crt -p warx -k rhcs_audit_nssdb
-w /etc/pki/rhcs10-RSA-SubCA/alias/cert9.db -p warx -k rhcs_audit_nssdb
-w /etc/pki/rhcs10-RSA-SubCA/alias/key4.db -p warx -k rhcs_audit_nssdb
-w /etc/pki/rhcs10-RSA-SubCA/alias/NHSM-CONN-XCcert9.db -p warx -k rhcs_audit_nssdb
-w /etc/pki/rhcs10-RSA-SubCA/alias/NHSM-CONN-XCkey4.db -p warx -k rhcs_audit_nssdb
-w /etc/pki/rhcs10-RSA-SubCA/alias/pkcs11.txt -p warx -k rhcs_audit_nssdb
    Copy to Clipboard Toggle word wrap

  3. Then restart auditd: 

    # service auditd restart
    Copy to Clipboard Toggle word wrap
Note

Whenever adding new instances to the same system, expand /etc/audit/rules.d/rhcs-audit-nssdb-access.rules to include the new instance files in the same manner.

Auditing time change events

To receive audit events for time changes, you need to audit a system call access which could modify the system time.

  1. Create the /etc/audit/rules.d/rhcs-audit-rhcs_audit_time_change.rules file with the following contents: 

    -a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F key=rhcs_audit_time_change
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=rhcs_audit_time_change
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=rhcs_audit_time_change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=rhcs_audit_time_change
-a always,exit -F arch=b32 -S clock_adjtime -F key=rhcs_audit_time_change
-a always,exit -F arch=b64 -S clock_adjtime -F key=rhcs_audit_time_change
-w /etc/localtime -p wa -k rhcs_audit_time_change
    Copy to Clipboard Toggle word wrap

  2. Then restart auditd: 

    # service auditd restart
    Copy to Clipboard Toggle word wrap

Auditing access to Certificate System configuration

To receive audit events for all modifications to the Certificate System instance configuration files, audit the file system access for these files.

  1. Create the /etc/audit/rules.d/rhcs-audit-config-access.rules file with the following contents: 

    -w /etc/pki/instance_name/server.xml -p wax -k rhcs_audit_config
    Copy to Clipboard Toggle word wrap

  2. Additionally, add for each subsystem in the /etc/pki/instance_name/ directory the following contents: 

    -w /etc/pki/instance name/subsystem/CS.cfg -p wax -k rhcs_audit_config
    Copy to Clipboard Toggle word wrap

    For example, if only a CA is installed on the rhcs10-RSA-SubCA instance, the /etc/audit/rules.d/rhcs-audit-config-access.rules file would contain: 

    -w /etc/pki/rhcs10-RSA-SubCA/server.xml -p wax -k rhcs_audit_config
-w /etc/pki/rhcs10-RSA-SubCA/ca/CS.cfg -p wax -k rhcs_audit_config
    Copy to Clipboard Toggle word wrap

    Note that access to the RHCS NSS database is already audited under rhcs_audit_nssdb.

Note

Whenever adding new instances to the same system, expand /etc/audit/rules.d/rhcs-audit-nssdb-access.rules to include the new instance files in the same manner.

Verifying audit rules

  1. After adding each audit rule and restarting the auditd service, you can validate that the new rules were added: 

    # auditctl -l
    Copy to Clipboard Toggle word wrap

    The contents of the new rules should be visible in the output.

Verifying auditing

You can verify that the rule for rhcs_audit_nssdb works with a simple test, for example:

  1. Access the SubCA alias directory: 

    # cd /etc/pki/rhcs10-RSA-SubCA/alias/
    Copy to Clipboard Toggle word wrap

  2. Check for the audit event: 

    # ausearch -k rhcs_audit_nssdb
    Copy to Clipboard Toggle word wrap

7.13.10. Verifying peer certificate for RHCS subsystems
Copiar o link

RHCS 10.4 provides different mechanisms for RHCS subsystems to verify their peer certificates, whether it is acting as a client or as a server in establishing a TLS session. The mechanisms employed are either OCSP or CRL.

The following provides details on how to enable them for each type of RHCS subsystem.

7.13.10.1. Enabling peer certificate status check for OCSP
Copiar o link

Important

This section describes an alternative method for enabling revocation checks in an OCSP subsystem. For the preferred method, see the next section: Section 7.13.10.2, “Enabling OCSP for the CA / KRA / TKS / TPS”.

Enabling OCSP for the OCSP system itself would create a chicken and egg phenomenon (in the case if the peer AIA points to the OCSP system itself before it starts up completely). Fortunately, the OCSP subsystem has the advantage of having the frequently updated CRL to verify its peer’s certificate without reaching out to another OCSP system. To enable such special feature, set the following two parameters in the OCSP’s CS.cfg: 

ocsp.store.ldapStore.validateConnCertWithCRL=true
auths.revocationChecking.enabled=true
Copy to Clipboard Toggle word wrap

In addition to enabling the two parameters in the CS.cfg, the enableOCSP parameter should remain to be “false” in its server.xml file, e.g. /var/lib/pki/rhcs10-RSA-OCSP-rootca/conf/server.xml and /var/lib/pki/rhcs10-RSA-OCSP-subca/conf/server.xml in our example: 

enableOCSP=”false”
Copy to Clipboard Toggle word wrap

7.13.10.2. Enabling OCSP for the CA / KRA / TKS / TPS
Copiar o link

Note

The instructions provided in this section also apply to an OCSP subsystem, as long as the peer certificate’s AIA does not point to the same OCSP subsystem during the startup of the OCSP system.

For instance, earlier in this chapter, in the installation procedures (7.4.1 and 7.7.1), the internal directory server’s server-certs for the OCSP servers were reissued with their AIA’s pointing to their corresponding CA’s internal OCSP service.

The following procedure aims to configure your CA, OCSP, KRA, TKS and TPS instances to verify the revocation status of their peer certificates according to the following extensions in the peer certificates:

Prerequisite

  • You are logged onto rhcs10.example.com as root user.

Procedure

This procedure uses the KRA as an example. Similar steps apply to the CA, OCSP, TKS and TPS instances as well, adjust the commands for the appropriate instance.

  1. Stop the KRA: 

    # pki-server stop rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-KRA.service
    Copy to Clipboard Toggle word wrap

  2. Edit the /var/lib/pki/rhcs10-RSA-KRA/conf/server.xml file to configure the Connector name="Secure" section:

    1. Set the enableRevocationCheck parameter to true. Note that enableRevocationCheck is also known as enableOCSP. Only set one and not both.

    2. Make sure you remove these two parameters and their assigned values:

      • ocspResponderURL
      • ocspResponderCertNickname

      For example: 

    <Connector name="Secure"
     enableRevocationCheck="true"
     ocspCacheSize="1000"
     ocspMinCacheEntryDuration="60"
     ocspMaxCacheEntryDuration="120"
     ocspTimeout="10"
     ...
/>
    Copy to Clipboard Toggle word wrap

  3. Start the KRA: 

    # pki-server start rhcs10-RSA-KRA
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-KRA.service
    Copy to Clipboard Toggle word wrap
Note

By default, all RHCS system certificates created during installation are generated with an AIA (Authority Information Access) extension pointing to its issuing CA’s internal OCSP service, such as http://rhcs10.example.com:31080/ca/ocsp.
If you followed the steps in Set the default AIA extension to point to this OCSP, to point to the external OCSP prior to installing the KRA, then all the KRA systems certificates (and all other certificates issued by its CA thereon) should bear the correct AIA pointing to the external OCSP instead.

Important

In an environment where OCSP is depended upon (enabled by setting the enableRevocationCheck or enableOCSP parameter in server.xml mentioned above), the OCSP instance needs to be up and running prior to the start of any of the instances that rely on it, such as KRA, TKS, and TPS in our installation example.
Likewise, the CA needs to be up and running before its external OCSP is started.

7.13.10.3. Enabling peer certificate status check without OCSP on the CA
Copiar o link

CAs can be configured to have the certificates needed (for example, CA’s LDAP server-cert) during startup to use CRL Distribution Points to avoid the chicken and egg issue during startup (see Configure Support for CRL Distribution Point under Section 9.4.1.2, “Enabling automatic revocation checking on the CA” for more details).

Once started, CAs can rely on OCSP to support revocation checks just like other CS subsystems.

Note

Certificate Revocation Validation Order and Expectations

CRL Distribution Point and OCSP-aia extensions are processed during revocation validation of the peer certificate on a CS subsystem as follows:

  • If only CRL Distribution Point is present in the certificate:

    • It is validated per CRL retrieved/associated with the CRL Distribution Point

      • If the certificate is in the CRL: fail/revoked
      • If the certificate is not in the CRL: good

    • If the URL in the CRL Distribution Point is unreachable, it is considered bad

      • Fail/revoked (versus another option not chosen: Ignored/unknown)
        Note how this is slightly different from when ocsp-aia is unreachable

  • If only OCSP-aia is present in the certificate:

    • It is validated per the OCSP response from the OCSP pointed to by the OCSP-aia

      • If the certificate is found in the CRL by the OCSP Responder: fail/revoked
      • If the certificate is not found in the CRL by the OCSP Responder: good

    • If the URL in the OCSP-aia is unreachable, it is considered bad

      • Bad Certificate
        Note how this is slightly different from when the CRL Distribution Point is unreachable

  • If both the OCSP-aia and the CRL Distribution Point are present in the certificate:

    • OCSP-aia takes precedence: that is, Good or Bad

    • If the URL in the OCSP-aia is unreachable, CRL Distribution takes over

      • If the URL in the CRL Distribution Point is unreachable, it is considered Fail/revoked

7.13.11. Update the ciphers list
Copiar o link

Red Hat Certificate System allows to set restrictions on acceptable ciphers when acting as a server or as a client. These cipher controls are configured at different locations.

An RHCS instance is acting as a server when it is accepting requests from another entity. For example:

  • When a RHCS cli talks to a CA for certificate enrollment (in this case, the CA is the server)
  • When a RHCS administrator uses the pkiconsole to talk to a CA (in this case, the CA is the server)
  • When a CA talks to a KRA for key archival (in this case, the KRA is the server, and the CA is the client)

An RHCS instance is acting as a client when it attempts to reach out to another server. For example:

  • When a CA talks to a KRA for key archival (in this case, the CA is the client while the KRA is the server)
  • When a CA talks to its internal LDAP database (in this case, the CA is the client while Directory Server is the server)

The following sections provide instructions on how to configure the ciphers for these different scenarios.

7.13.11.1. Configuring the ciphers for a CS instance acting as a server
Copiar o link

The desired set of ciphers for a given instance is defined by the SSLHostConfig element in the <CS instance directory>/conf/server.xml file.
Follow the instructions below to configure each CS instance.

Important

Back up the original server.xml file before editing, for example to server.xml.orig.

  1. Edit the server.xml file, navigate to the main SSL port’s Connector declaration and find the SSLHostConfig element.

  2. Modify the SSLHostConfig element with the following configuration: 

    <SSLHostConfig sslProtocol="TLS" protocols="TLSv1.2" certificateVerification="optional" ciphers="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384">
    Copy to Clipboard Toggle word wrap

    The above cipher list represents the set of ciphers claimed in this RHCS release in OpenSSL format, where:

    • ciphers=" …​ ": establishes the restricted ciphers desired (for example TLS). In this format, cipher names are separated by a colon.
    • protocols=" …​ ": establishes which TLS version you want (for example, 1.2).

7.13.11.2. Configuring the ciphers for a CS instance acting as a client
Copiar o link

When a CS instance acts as a client, add the desired list of ciphers in the instance’s CS.cfg configuration file. Configure all the client instances as relevant based on their roles.

Important

Back up the original CS.cfg file before editing, for example to CS.cfg.orig.

  • When a CS instance is acting as a client to its internal LDAP database.
    Add the following line to the <instance directory>/<instance type>/conf/CS.cfg file: 

    tcp.clientCiphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    Copy to Clipboard Toggle word wrap
    Note

    To ensure that the internal LDAP database has the desired ciphers enabled, please follow Configuring the ciphers for a DS instance.

  • When a CA instance is acting as a client to the KRA.
    Add the following line to the <instance directory>/ca/conf/CS.cfg file: 

    ca.connector.KRA.clientCiphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    Copy to Clipboard Toggle word wrap

  • When a TPS instance is acting as a client to the CA, KRA, or TKS.
    Add the following line to the <instance directory>/tps/conf/CS.cfg file: 

    tps.connector.<ca|kra|tks id>.clientCiphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    Copy to Clipboard Toggle word wrap
Note

You must restart each server instance for the modifications to take effect, e.g.: 

# pki-server restart rhcs10-RSA-RootCA
Copy to Clipboard Toggle word wrap 
# pki-server restart rhcs10-RSA-SubCA
Copy to Clipboard Toggle word wrap 
# pki-server restart rhcs10-RSA-OCSP-rootca
Copy to Clipboard Toggle word wrap 
# pki-server restart rhcs10-RSA-OCSP-subca
Copy to Clipboard Toggle word wrap 
# pki-server restart rhcs10-RSA-KRA
Copy to Clipboard Toggle word wrap

OR if using the Nuxwdog watchdog: 

# systemctl restart rhcs10-RSA-RootCA
Copy to Clipboard Toggle word wrap 
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service
Copy to Clipboard Toggle word wrap 
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service
Copy to Clipboard Toggle word wrap 
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service
Copy to Clipboard Toggle word wrap 
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service
Copy to Clipboard Toggle word wrap

…​

7.13.11.3. Configuring the ciphers for a DS instance
Copiar o link

By default, a Directory Server instance inherits the ciphers enabled on the OS. If you wish to set it so that the cipher list matches that of the Certificate System, proceed with the following steps for each DS instance:

  • On the DS host rhds11.example.com:

    1. Enable the intended ciphers (use the non-SSL port of the DS instance): 

      # dsconf -D "cn=Directory Manager" ldap://rhds11.example.com:7389 security ciphers set "+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
      Copy to Clipboard Toggle word wrap

    2. Restart the DS instance: 

      # dsctl slapd-CC-RSA-SubCA-LDAP stop
      Copy to Clipboard Toggle word wrap 
      # dsctl slapd-CC-RSA-SubCA-LDAP start
      Copy to Clipboard Toggle word wrap

    3. Verify by listing the enabled ciphers: 

      # dsconf -D "cn=Directory Manager" ldap://rhds11.example.com:7389 security ciphers list --enabled

Enter password for cn=Directory Manager on ldap://rhds11.example.com:7389:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      Copy to Clipboard Toggle word wrap

7.13.12. Requiring TLS mutual authentication for connections to CS
Copiar o link

By default, Red Hat Certificate System already requires role user operations to go through TLS mutual authentication by way of conducting client certificate verification in the RHCS authentication plugin, while at the same time allows some of the non-role operations to be processed via TLS server authentication only. TLS mutual authentication provides stronger authentication for the server connectors. The following procedure allows sites to make the Certificate System instances inaccessible to clients that are unable to present their certificate for TLS handshake.

Important

Do not execute the steps in this section until you have installed all desired Certificate System instances. Once you have executed the steps in this section, you will need to revert the change in case you later wish to install more Certificate System instances.

Procedure

Enabling TLS mutual authentication is done by modifying the server.xml configuration file.

Important

Back up the original server.xml file before editing, for example to server.xml.orig.

  1. Edit the server.xml file and search for the certificateVerification= parameter.

  2. Change the parameter value from optional to required: 

    certificateVerification=required
    Copy to Clipboard Toggle word wrap
  3. Save and restart each server instance for the modifications to take effect.

Once you have strengthened the CS instances, it is important to note that operations that normally do not require TLS mutual authentication will now require to present a valid client certificate at time of TLS handshake. Example operations affected by this are enrollments using CMCSharedToken and some of the pki commands that ordinarily do not require TLS mutual authentication.

  • To get CMCSharedToken to work, you will need to pre-issue a certificate to the user, then at time of HttpClient call, edit the HttpClient configuration file so that it contains the following: 

    clientmode=true
nickname=<client cert that was issued and imported>
    Copy to Clipboard Toggle word wrap

  • In order to work, pki commands now require to present a valid client certificate:

    • For example, originally, the ca-cert-find command does not require mutual authentication: 

      # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 ca-cert-find
      Copy to Clipboard Toggle word wrap

    • Now, with the new restriction, you will need to do the following: 

      # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 -n 'SubCA_AdminV' ca-cert-find
      Copy to Clipboard Toggle word wrap

      The following list shows pki commands that fall into this category:

      • pki client-cert-request
      • pki ca-authority-find
      • pki ca-authority-show
      • pki ca-cert-find
      • pki ca-cert-show
      • pki ca-cert-export
      • pki ca-cert-status
      • pki ca-cert-request-show
      • pki ca-cert-request-submit
      • pki ca-cert-request-profile-find
      • pki ca-cert-request-profile-show
      • pki ca-cert-signing-show
      • pki ca-cert-signing-export
      • pki ca-cert-transport-show
      • pki ca-cert-transport-export
      • pki ca-feature-find
      • pki ca-feature-show

There may be other commands that fall into the same category and require similar treatment.

7.13.13. Enabling TLS mutual authentication from CS to DS
Copiar o link

After you have configured the basic TLS server authentication when installing the CS subsystem, you must choose to enable TLS mutual authentication (also called client authentication) from a given subsystem to the LDAP server.

Note

This section requires the CS instance installed and running. If you used a temporary LDAP server certificate (in the case of a CA), replace it first by following :

These steps are to be performed once the installation is complete.

There are two parts to setting up mutual authentication, first on the DS side, second on the CS side.

Configuration on DS

As a first part, we need to configure the LDAP directory to require TLS mutual authentication.

Note the following:

  • pkispawn already automatically created a pkidbuser on its internal Directory Server, where the CS instance’s "subsystem certificate" (for example subsystemCert cert-pki-ca) that is used for outbound TLS mutual authentication is stored in the user entry. Therefore, there is no need to create another LDAP user or another certificate for the TLS client-authentication.

  • When creating content for /etc/dirsrv/slapd-instance_name/certmap.conf, use the following format: 

    certmap rhcs <certificate issuer DN>
		rhcs:CmapLdapAttr seeAlso
		rhcs:verifyCert on
    Copy to Clipboard Toggle word wrap

    For example 

    certmap rhcs CN=CA Signing Certificate,OU=pki-tomcat-ca,O=pki-tomcat-ca-SD
		rhcs:CmapLdapAttr seeAlso
		rhcs:verifyCert on
    Copy to Clipboard Toggle word wrap

  • After configuring, restart the Directory Server. For example: 

    # dsctl slapd-CC-RSA-SubCA-LDAP restart
    Copy to Clipboard Toggle word wrap

Configuration on CS

As a second part, we need to configure the Red Hat Certificate System instance so that it knows to use the correct authentication type (i.e. SslClientAuth instead of BasicAuth), as well as which port and certificate is to be used to communicate with its internal LDAP server using TLS mutual authentication. This involves editing the RHCS instance’s CS.cfg file located at <instance directory>/<subsystem type>/conf/CS.cfg. For example /var/lib/pki/instance_name/ca/conf/CS.cfg

  1. Stop the CS instance you want to configure: 

    # pki-server stop rhcs10-<INSTANCE>
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
    Copy to Clipboard Toggle word wrap

  2. In the CS.cfg, please add the RHCS instance’s subsystem certificate nickname to internaldb.ldapauth.clientCertNickname, and remove the two unused entries: 

    internaldb.ldapauth.bindDN
		internaldb.ldapauth.bindPWPrompt
    Copy to Clipboard Toggle word wrap

    As shown below: 

internaldb._000=##
		internaldb._001=## Internal Database
		internaldb._002=##
		internaldb.basedn=o=pki-tomcat-ca-SD
		internaldb.database=pki-tomcat-ca
		internaldb.maxConns=15
		internaldb.minConns=3
		internaldb.ldapauth.authtype=SslClientAuth
		internaldb.ldapauth.clientCertNickname=HSM-A:subsystemCert pki-tomcat-ca
		internaldb.ldapconn.host=example.com
		internaldb.ldapconn.port=11636
		internaldb.ldapconn.secureConn=true
Copy to Clipboard Toggle word wrap

  1. Restart the CS instance: 

    # pki-server start rhcs10-<INSTANCE>
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
    Copy to Clipboard Toggle word wrap
Note

You must configure the internaldb.basedn and internaldb.database parameters to match your specific LDAP instance.

For compliance, internaldb.ldapauth.authtype=SslClientAuth and internaldb.ldapconn.secureConn=true must be set, and the value of the internaldb.ldapauth.clientCertNickname must match the nickname of the TLS client certificate to authenticate against LDAP with in the nssdb.

All other values can be changed as desired to reflect your environment or availability needs.

7.13.14. Update the supported_groups TLS extension
Copiar o link

The Protection Profile for Certification Authorities Version 2.1 does not allow the newer (and more secure) named groups for TLS key exchange. In order to meet this requirement, the below procedure describes how to disable these groups:

  1. First by constructing a set of policies based on an existing one (/usr/share/crypto-policies/FIPS.pol) with the necessary modifications. This will result in updates to another configuration file (/etc/crypto-policies/back-ends/nss.config) accordingly.
  2. Followed by instructions on how to further tailor the resulting changed configuration file (/etc/crypto-policies/back-ends/nss.config) to achieve the needed result.
Important

Do not execute the steps in this section until you have installed all desired CS instances. Once you have executed the steps in this section, if more CS instances are to be installed later, you will need to revert the changes before proceeding: 

# update-crypto-policies --set FIPS
Copy to Clipboard Toggle word wrap

Procedure

  1. Shut down all Certificate System servers. For example: 

    # pki-server stop rhcs10-<INSTANCE>
    Copy to Clipboard Toggle word wrap

    OR if using the Nuxwdog watchdog: 

    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
    Copy to Clipboard Toggle word wrap

  2. Find out which file the system is basing its policies on: 

    # update-crypto-policies --show
    Copy to Clipboard Toggle word wrap

    If you followed the installation procedure, you should see "FIPS" as the command output.

  3. Copy the current policies to our new custom policy file, for modifications: 

    # cp /usr/share/crypto-policies/policies/FIPS.pol /etc/crypto-policies/policies/CC-FIPS.pol
    Copy to Clipboard Toggle word wrap

  4. Edit the custom policy file, for example: 

    # vi /etc/crypto-policies/policies/CC-FIPS.pol
    Copy to Clipboard Toggle word wrap

    Make the following modifications, then save the file:

    1. Change the assignment of the groups parameter from: 

      group = SECP256R1 SECP384R1 SECP521R1 \ FFDHE-2048 FFDHE-3072 FFDHE-4096 FFDHE-6144 FFDHE-8192
      Copy to Clipboard Toggle word wrap

      to 

      group = SECP256R1 SECP384R1 SECP521R1
      Copy to Clipboard Toggle word wrap

    2. Change the assignment of the key_exchange parameter from: 

      key_exchange = ECDHE DHE DHE-RSA PSK DHE-PSK ECDHE-PSK
      Copy to Clipboard Toggle word wrap

      to 

      key_exchange = ECDHE DHE PSK DHE-PSK ECDHE-PSK
      Copy to Clipboard Toggle word wrap

    3. Change the assignment of the min_dh_size parameter from 

      min_dh_size = 2048
      Copy to Clipboard Toggle word wrap

      to 

      min_dh_size = 176384
      Copy to Clipboard Toggle word wrap

  5. Register the custom site policy: 

    # update-crypto-policies --set CC-FIPS
    Copy to Clipboard Toggle word wrap

    The nss.config file will reflect the changes after the update_crypto-policies -set call to the custom policy file.
    The second part of this procedure consists in further required changes to the nss.config file.

  6. Edit the nss.config file, for example: 

    # vi /etc/crypto-policies/back-ends/nss.config
    Copy to Clipboard Toggle word wrap

    Under the assignment for the config parameter, in the allow= string, insert the following string directly after the dtls-version-min=dtls1.2 setting: 

    tls-version-max=tls1.2:dtls-version-max=dtls1.2
    Copy to Clipboard Toggle word wrap

    The resulting config line should look like the following: 

    config="disallow=ALL allow=HMAC-SHA256:HMAC-SHA1:HMAC-SHA384:HMAC-SHA512:SECP256R1:SECP384R1:SECP521R1:aes256-gcm:aes256-cbc:aes128-gcm:aes128-cbc:SHA256:SHA384:SHA512:SHA224:ECDHE-RSA:ECDHE-ECDSA:tls-version-min=tls1.2:dtls-version-min=dtls1.2:tls-version-max=tls1.2:dtls-version-max=dtls1.2:DH-MIN=176384:DSA-MIN=2048:RSA-MIN=2048"
    Copy to Clipboard Toggle word wrap

  7. Start or restart any nss-based applications / servers / clients to see the changes apply. For example: 

    # pki-server start rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap 
    # pki-server restart rhcs10-RSA-SubCA
    Copy to Clipboard Toggle word wrap

    …​

    OR if using the Nuxwdog Watchdog: 

    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service
    Copy to Clipboard Toggle word wrap 
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service
    Copy to Clipboard Toggle word wrap 
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service
    Copy to Clipboard Toggle word wrap 
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service
    Copy to Clipboard Toggle word wrap 
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service
    Copy to Clipboard Toggle word wrap

    …​

7.13.15. Enabling the access banner
Copiar o link

To enable or disable the access banner on rhcs10.example.com:

  • Enable the banner by creating the /etc/pki/instance_name/banner.txt file and entering the text to be displayed. The banner text must use the UTF-8 format.

  • If you need to disable the existing access banner, either delete or rename the /etc/pki/instance_name/banner.txt file. For example: 

    # mv /etc/pki/instance_name/banner.txt /etc/pki/instance_name/banner.txt.UNUSED
    Copy to Clipboard Toggle word wrap

Verification:

  1. Validate that the banner does not contain invalid characters: 

    # pki-server banner-validate -i instance_name
---------------
Banner is valid
---------------
    Copy to Clipboard Toggle word wrap

  2. To display the currently configured banner: 

    # pki-server banner-show -i instance_name
    Copy to Clipboard Toggle word wrap

7.13.16. Determining the product version
Copiar o link

The Red Hat Certificate System product version is stored in the /usr/share/pki/CS_SERVER_VERSION file.

To display the version of an installed Red Hat Certificate System server: 

# cat /usr/share/pki/CS_SERVER_VERSION

Red Hat Certificate System 10.4.3
Copy to Clipboard Toggle word wrap

Once you have a server installed and running, you can find the product version for each instance by accessing the following URLs from your browser:

  • http://host_name:port_number/ca/admin/ca/getStatus
  • http://host_name:port_number/kra/admin/kra/getStatus
  • http://host_name:port_number/ocsp/admin/ocsp/getStatus
  • http://host_name:port_number/tks/admin/tks/getStatus
  • http://host_name:port_number/tps/admin/tps/getStatus
Note

Note that each component is a separate package and thus could have a separate version number. The above will show the version number for each currently running component.

Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat