Chapter 7. Installing and configuring Red Hat Certificate System
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: At least one CA running as a security domain is required before any of the other public key infrastructure (PKI) subsystems can be installed. Install the OCSP after you have configured the CA. The KRA and TKS subsystems can be installed in any order, after you have configured the CA and OCSP. 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 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 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: Create an OS administrator group (e.g. pkiadmin ): Create OS users: 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: Create an OS user (e.g John Smith - jsmith ). In our example, this person will serve as a PKI Agent user: Create an OS user (e.g. Astrid Guru - aguru ). In our example, this person will serve as a PKI Auditor user: Associate pkiuser with the pkiadmin and nfast groups: NOTE If using a Thales Luna HSM, associate pkiuser with the hsmusers group (instead of nfast ): Please see Section 4.4, "Supported Hardware Security Modules" for more information on Luna's limitations. Since the tests in this example use an Entrust HSM, associate the users who are to administer the HSM device with the nfast group: 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: 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: 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 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 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 : Create the RootCA directory server installation file at a chosen location (e.g. /root/pki_rsa ): 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. Optional : To view other configuration options for future reference, you can create a template file using the dscreate create-template command: Set up the directory server instance using the .cfg file: 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: List the bootstrap certificates to verify: Export the certificate: Copy the certificate to rhcs10.example.com : Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com : Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com : The LDAP search should be successful, e.g: 7.1.2.2. Installing a DS instance for the RootCA's OCSP 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 : Create the RootCA's OCSP directory server installation file at a chosen location (e.g. /root/pki_rsa ): 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. Set up the directory server instance using the .cfg file: 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: List the bootstrap certificates to verify: Export the certificate: Copy the certificate to rhcs10.example.com : Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com : Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com : The LDAP search should be successful, e.g: 7.1.2.3. Installing a DS instance for the SubCA 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 : Create the SubCA directory server installation file at a chosen location (e.g. /root/pki_rsa ): 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. Set up the directory server instance using the .cfg file: 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: List the bootstrap certificates to verify: Export the certificate: Copy the certificate to rhcs10.example.com : Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com : Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com : The LDAP search should be successful, e.g: 7.1.2.4. Installing a DS instance for the SubCA's OCSP 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 : Create the SubCA's OCSP directory server installation file at a chosen location (e.g. /root/pki_rsa ): 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. Set up the directory server instance using the .cfg file: 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: List the bootstrap certificates to verify: Export the certificate: Copy the certificate to rhcs10.example.com : Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com : Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com : The LDAP search should be successful, e.g: 7.1.2.5. Installing a DS instance for the KRA 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 : Create the KRA directory server installation file at a chosen location (e.g. /root/pki_rsa ): 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. Set up the directory server instance using the .cfg file: 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: List the bootstrap certificates to verify: Export the certificate: Copy the certificate to rhcs10.example.com : Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com : Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com : The LDAP search should be successful, e.g: 7.1.2.6. Installing a DS instance for the TKS 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 : Create the TKS directory server installation file at a chosen location (e.g. /root/pki_rsa ): 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. Set up the directory server instance using the .cfg file: 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: List the bootstrap certificates to verify: Export the certificate: Copy the certificate to rhcs10.example.com : Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com : Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com : The LDAP search should be successful, e.g: 7.1.2.7. Installing a DS instance for the TPS 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 : Create the TPS directory server installation file at a chosen location (e.g. /root/pki_rsa ): 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. Set up the directory server instance using the .cfg file: 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: List the bootstrap certificates to verify: Export the certificate: Copy the certificate to rhcs10.example.com : Test out the LDAP server setup for the Directory Server machine, for example by running the following on rhds11.example.com : Test out the LDAP server setup for the Certificate System machine, for example by running the following on rhcs10.example.com : The LDAP search should be successful, e.g: 7.1.3. Enabling TLS authentication between CS and its internal LDAP server 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. 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 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 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: [DEFAULT] - subsystem-independent settings [Tomcat] [CA], [KRA], [OCSP], [TKS], or [TPS] - the subsystem-specific sections When it runs, pkispawn : 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. Reads the administrator-provided configuration file mentioned above to override the default values. Performs the installation of the requested subsystem. 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: Set a unique instance name: Set the host name: 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. Set the port numbers for the HTTP and HTTPS protocols: 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. Set the HSM-specific parameters: For further details, see Section 6.6.3, "Preparing for installing Certificate System with an HSM" . If building an RSA Certificate System instance, use the following configuration: Allowed choices for the key_algorithm parameters are: 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 . To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: Allowed choices for the key_algorithm parameters are: 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: For ECC, the allowed choice for key_type is ecc . Set the client directory of the bootstrap admin user: 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. Set various passwords for the bootstrap admin user: Set the parameters for the LDAPS connection to Directory Server running on the same host: 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: For the CA that will act as a security domain, set the proper parameters: [Tomcat] section: Set the Tomcat JServ Protocol (AJP) port: Set the Tomcat server port: 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: [CA] - Section 7.3, "Create and configure the RootCA (Part I)" [OCSP] - Section 7.4, "Create and configure the OCSP instance (RootCA)" and Section 7.7, "Create and configure the OCSP instance (SubCA)" [CA] - Section 7.6, "Create and configure the SubCA (Part I)" [KRA] - Section 7.9, "Create and configure the KRA instance" [TKS] - Section 7.10, "Create and configure the TKS instance" [TPS] - Section 7.11, "Create and configure the TPS instance" 7.2.2. Installation methods (single-step or two-step) 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: Note Before starting the installation, it is good practice to first run a precheck using the configuration file: E.g. for the CA: 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: Note Before starting the installation, it is good practice to first run a precheck using the configuration file. E.g. for the CA: Between step customization Between running the two pkispawn steps, you have the opportunity to manually update some instance-specific configuration files before the 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: Note Before starting the installation, it is good practice to first run a precheck using the configuration file. E.g. for the CA: For a complete example, see Section 7.3.2, "Installing the RootCA instance (two-step method)" . 7.2.3. Installation example (introduction) 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: Important To gain a better picture of the process involved, we advise you to: Follow Chapter 6, Prerequisites for installation if you have not done it yet. Follow either the single-step installation or two-step installation example to install RootCA OCSP of RootCA (optional) SubCA OCSP of SubCA KRA (if TMS is of interest - RSA only) continue to follow either the single-step installation or two-step installation example to install TKS TPS 7.3. Create and configure the RootCA (Part I) To install and configure a RootCA instance, use either one of two pkispawn methods: Single-step Two-step . 7.3.1. Installing the RootCA instance (single-step method) 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.1, "Installing a DS instance for the RootCA" . In our example, CC-RSA-RootCA-LDAP is the RootCA's internal database. Procedure 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 ). 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... Run the pkispawn tool to install the RHCS CA instance: Verification steps Show the status of the installed CA: Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs. Verify the sanity of the CA by running the following command. It should display certificates: 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: 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) 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.1, "Installing a DS instance for the RootCA" . In our example, CC-RSA-RootCA-LDAP is the RootCA's internal database. First step of RootCA installation 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 ). 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. Run the pkispawn tool to install the RHCS CA instance: 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: Open the enrollment profile for this CA's signing certificate: Add the following parameter: Save the file. Likewise, do the same for the CA signing cert that this CA will be issuing in the future: Open the enrollment profile for the CA signing certificate: Add the following parameter: 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: Open the corresponding configuration file: Change the following range parameters to the desired values: Save the file. Once you have done the second step of pkispawn in the 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: Verification steps Show the status of the installed CA: Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs. Verify the sanity of the CA by running the following command. It should display certificates: 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: 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 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 Generate a list of non-CMC profiles to be edited: Stop the RootCA instance: 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 : In addition, also change the visible parameter for the caCMCUserCert profile to false : Start the RootCA instance: 7.3.4. Create a CA chain file 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). Create a CA chain file for later use: Copy the files to rhds11.example.com (the machine that hosts the DS instances): On rhds11.example.com , edit the /etc/openldap/ldap.conf file so that TLS_CACERT points to the CA chain file we just created: Restart the DS instance for the RootCA: 7.3.5. Prepare the RootCA to sign other CMC certificate requests 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: 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 Create a client nssdb: 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: and if none exist, you can select Yes to overwrite. Import the CA signing certificate into the nssdb: Import the RootCA bootstrap admin certificate/key into the nssdb: Verification: List the certificates: As the bootstrap admin user, list the users in the RootCA: 7.3.6. Check for random serial numbers List the certificates to make sure all the subsystem certificates have random serial numbers. 7.3.7. Verify that the RootCA signing certificate has no AIA 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: 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 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: 7.3.8.1. CA Setup to support Server Cert CRL File Publishing Note Before proceeding, save a copy of the configuration file before editing: 7.3.8.1.1. Set up the file-based publisher: crlFilePublisher 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. Create the CRL directory for publishing the file-based partitioned CRL: Add the following to the CA's CS.cfg : 7.3.8.1.2. Set up the file-based publishing rule: FileCrlRule 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 : 7.3.8.1.3. Modify the LDAP-based publishing rule: LdapCrlRule 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 : 7.3.8.1.4. Set up the CRL-partitioning for certificates issued via a profile 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 : Note For an ECC CA, set the following to SHA512withEC : 7.3.8.2. Set up CRL HTTP service in the CA 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: Add the following CRL service before the Catalina service in the file /var/lib/pki/rhcs10-RSA-RootCA/conf/server.xml : 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: Note If your selected port has been pre-assigned with another SELinux context, you will see an error message that looks like the following: You can also search and find out whether the CRL HTTP port is pre-assigned by using the following command: We recommend that you select another port. However, if you wish to use the same port, you could do the following: 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: Create a crl.xml file under /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost , and add the following content: Set the user:group ownership for the crl.xml file: Note The CRL Distribution Point set in the enrollment profile looks like this (see 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 Enable the desired profile(s) to include the CRL Distribution Points. These are the profiles corresponding to the configuration in the sections above. 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: 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: Set user:group ownership: Register a new profile in the CA's CS.cfg : Add the following lines for each profile: Edit the profile.list entry to add the two new profiles. For example:: 7.3.8.4. Set up for more immediate CRL update 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 : 7.3.8.5. Start up the CA once the CA's configuration is updated Once configuration is complete, start up the CA: 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) 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): 7.4.1. Replace the temporary DS certificate (OCSP-rootca) 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: Stop DS: Note If you are not certain about the name of a DS instance, list all instances using: dsctl -l. Use the certutil tool to generate the CSR: Important Edit the Server-Cert-ocsp-rootca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Remote copy the Server-Cert-ocsp-rootca.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and its CA certificate in chain one by one. For example: List the certificates: Start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 7.4.2. Install the OCSP instance for the RootCA 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.2, "Installing a DS instance for the RootCA's OCSP" , in our example, CC-RSA-OCSP-rootca-LDAP is the internal database of the RootCA's OCSP. Procedure Create an OCSP installation file at a chosen location (e.g. /root/pki_rsa ) for generating certificate requests: 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... Run the pkispawn tool to install the OCSP subsystem: 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: First run the pkispawn tool with the --skip-configuration option to install the RootCA's OCSP instance: Customize the configuration files between the two installation steps Run the pkispawn tool to configure the OCSP: Verification Show the status of the installed OCSP instance: 7.4.3. Increase the RootCA's OCSP pkiconsole timeout Log in to rhcs10.example.com as root. Stop the RootCA's OCSP service: Edit /var/lib/pki/rhcs10-RSA-OCSP-rootca/conf/server.xml to increase the timeout period: Start the RootCA's OCSP service: 7.4.4. Set the default AIA extension to point to this OCSP 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: Stop the RootCA: Edit the RootCA's CS.cfg and set the ca.defaultOcspUri variable to point to the OCSP. For example: Start the RootCA: 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 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.: 7.4.6. Login to the OCSP pkiconsole with client authentication Configure OCSP with authType=sslclientauth and import the role user certificate by following Section 7.13.6, "Configure pkiconsole login with client authentication" . Login to pkiconsole with the client authentication certificate of the role user: 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 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 On rhds11.example.com as root: 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. Use the dscreate create-template command to create a template .cfg file at a chosen location (e.g. /root/pki_rsa ): Edit the .cfg file created in the step. Uncomment the below parameters and set them to customize the installation: Install the Directory Server instance: Add an ACI (Access Control Instruction) rule to allow anonymous bind access. By default, this is disabled. Create the ldapaci.ldif file at a chosen location (e.g. /root/pki_rsa/dirsrv/ ) with the following content: Run the ldapmodify command to add the ACI: Prepare the CRL publishing subtree: Create two files in the /root/pki_rsa/dirsrv directory with the following content: For the rootca_pki_subtree.ldif file: For the rootca_crl_subtree.ldif file: Add both entries to the CRL instance: 7.4.7.2. Configuring CRL publishing on the RootCA To configure CRL publishing: Add the ca.publish. properties: Stop the RootCA instance: Configure the following properties in the RootCA's CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg ): NOTE Alternatively, you can use the ca-config-set command to update the properties. For example: And so on. You can check that the parameters were successfully updated by using the ca-config-show command. For example: Start the RootCA instance: Push the CRL and CA certificate to the LDAP directory via curl . For example: Disable the direct CA->OCSP CRL publishing method: Stop the RootCA: 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 : For example: Start the CA for the configuration change to take effect: Update the Directory Server using curl . For example: Display the CRL using curl : Run ldapsearch to verify that the CRL and the CA certificate are pushed to the LDAP directory: Disable certificate publishing for the RootCA (optional): Note The following procedure is to prevent a WARNING message in the debug logs like the following: Stop the RootCA: Edit /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg and set the following: Start the RootCA for the configuration change to take effect: 7.4.7.3. Configuring the OCSP to pull the CRLs from the LDAP server 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: Stop the OCSP: 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: 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. 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. 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. Start the OCSP for the ldapStore configuration to take effect: 7.4.7.4. Testing CRL publishing 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 : List the certificates in the database: Use the PKCS10Client tool to generate a PKCS10 certificate request: Use cat on the .keyID file to display the key id. You will need it for the request.privKeyId= field in the step: Generate a CMC request: Create a CMCRequest configuration file, using the PKCS#10 request and private key id you obtained from the step. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the response using the CMCResponse command: 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: Push the CRL and CA certificate to the LDAP directory: Login to the RootCA's Agent UI in the browser. Select Update Revocation List and click Update . Click Update Directory Server and select: Update the certificate revocation list to the directory Update Certificate Manager certificate to the directory Click Update Directory . Wait for the OCSP's ldapStore refresh to happen (observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/logs/debug ). Check the certificate status by using the OCSPClient tool. For example, using the certificate serial number of user1 (in decimal): Revoke the certificate of user2 : Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: Verification 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. Wait until the 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: Select Update Revocation List and click Update . Click Update Directory Server and select: Update the certificate revocation list to the directory Update Certificate Manager certificate to the directory Click Update Directory . Once the ldapStore refresh completes, observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/logs/debug . 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): 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) 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) 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: Verify the existence of the nssdb password file on this instance: Stop DS: Use the certutil tool to generate the CSR: Important Edit the Server-Cert-rootca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Start DS: Remote copy the Server-Cert-rootca.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Note For EC certificates, use the ECC profiles by setting: Submit the request using the HttpClient command: Process the CMC Response : 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Stop DS: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and its CA certificate in chain one by one. For example: List the certificates: On rhds11.example.com , start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 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: Stop the CA: List the certificate: Remove the temporary certificate from the nssdb: 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: To enable certificate revocation checks, in the respective /var/lib/pki/rhcs10-RSA-RootCA/conf/server.xml file: Set enableOCSP or enableRevocationCheck to true : Additionally, remove these two parameters and their assigned values: Disable the legacy revocation check method by editing the CA's CS.cfg file and setting the following to false : Start the RootCA instance: 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" ): Check the publishing of the file-based CRL: Display and verify the content of the CRL 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: Stop the CA service. Set the enableRevocationCheck or enableOCSP parameter to false (if it is currently set to true ) in CA's server.xml . Set the ca.crl.ServerCertCRL.publishOnStart= parameter to true in CA's CS.cfg . Start the CA service to regenerate the missing CRL file: After the CRL file has been recovered, stop the CA service once again. Revert the ca.crl.ServerCertCRL.publishOnStart= parameter to false in CA's CS.cfg . Set the enableRevocationCheck or enableOCSP parameter to true in CA's server.xml . 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 List the certificates in the CA: As the bootstrap admin user, list the users in the RootCA: 7.6. Create and configure the SubCA (Part I) To install and configure a SubCA instance, use either one of two pkispawn methods: Single-step Two-step . 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) 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.3, "Installing a DS instance for the SubCA" , in our example, CC-RSA-SubCA-LDAP is the SubCA's internal database. Procedure Create a SubCA installation file at a chosen location (e.g. /root/pki_rsa ): 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... Run the pkispawn tool to install the RHCS SubCA instance: This will create the SubCA instance in /var/lib/pki/rhcs10-RSA-SubCA . Verification steps Show the status of the installed CA: Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs. Verify the sanity of the CA by running the following command. It should display certificates: 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: 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) 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.3, "Installing a DS instance for the SubCA" . In our example, CC-RSA-SubCA-LDAP is the SubCA's internal database. First step of SubCA installation 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 ). 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. Run the pkispawn tool to install the RHCS CA instance: 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: Open the enrollment profile for this CA's signing certificate: Add the following parameter: Save the file. Likewise, do the same for the CA signing cert that this CA will be issuing in the future: Open the enrollment profile for the CA signing certificate: Add the following parameter: 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: Open the corresponding configuration file: Change the following range parameters to the desired values: Save the file. Once you have done the second step of pkispawn in the 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: Verification steps Show the status of the installed CA: Note down the Unsecure EE, Secure EE, Agent, Admin and pkiconsole URLs. Verify the sanity of the CA by running the following command. It should display certificates: 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: 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 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. Retrieve the SubCA certificate into a .pem file Update the CA certificate chain. For example: 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 . The chain ends with the root certificate, at the bottom. Copy the files to rhds11.example.com (the machine that hosts the DS instances): Restart the DS instance for the SubCA: 7.6.4. Set up the SubCA bootstrap admin certificate 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. Optional : If you have not done this previously, import the RootCA signing certificate into the nssdb: Import the SubCA signing certificate into the nssdb: Import the SubCA bootstrap certificate into the nssdb: Verification: List the contents of the nssdb: 7.6.5. Disable non-CMC and non-installation profiles 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 Generate a list of non-CMC profiles to be edited: Stop the SubCA instance: 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 : In addition, also change the visible parameter for the caCMCUserCert profile to false : Start the SubCA instance: 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 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: 7.6.6.1. CA Setup to support Server Cert CRL File Publishing Note Before proceeding, save a copy of the configuration file before editing: 7.6.6.1.1. Set up the file-based publisher: crlFilePublisher 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. Create the CRL directory for publishing the file-based partitioned CRL: Add the following to the CA's CS.cfg : 7.6.6.1.2. Set up the file-based publishing rule: FileCrlRule 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 : 7.6.6.1.3. Modify the LDAP-based publishing rule: LdapCrlRule 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 : 7.6.6.1.4. Set up the CRL-partitioning for certificates issued via a profile 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 : Note For an ECC CA, set the following to SHA512withEC : 7.6.6.2. Set up CRL HTTP service in the CA 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: Add the following CRL service before the Catalina service in the file /var/lib/pki/rhcs10-RSA-SubCA/conf/server.xml : 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: Note If your selected port has been pre-assigned with another SELinux context, you will see an error message that looks like the following: You can also search and find out whether the CRL HTTP port is pre-assigned by using the following command: We recommend that you select another port. However, if you wish to use the same port, you could do the following: 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: Create a crl.xml file under /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost , and add the following content: Set the user:group ownership for the crl.xml file: Note The CRL Distribution Point set in the enrollment profile looks like this (see 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 Enable the desired profile(s) to include the CRL Distribution Points. These are the profiles corresponding to the configuration in the sections above. 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: 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: Set user:group ownership: Register a new profile in the CA's CS.cfg : Add the following lines for each profile: Edit the profile.list entry to add the two new profiles. For example: 7.6.6.4. Set up for more immediate CRL update 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 : 7.6.6.5. Start up the CA once the CA's configuration is updated Once configuration is complete, start up the CA: 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) 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): 7.7.1. Replace the temporary DS certificate (OCSP-subca) 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: Stop DS: Note If you are not certain about the name of a DS instance, list all instances using: dsctl -l Use the certutil tool to generate the CSR: Important Edit the Server-Cert-ocsp-subca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Remote copy the Server-Cert-ocsp-subca.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and the CA certificates in its chain one by one. For example: List the certificates: Start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 7.7.2. Install the OCSP instance for the SubCA 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.4, "Installing a DS instance for the SubCA's OCSP" , in our example, CC-RSA-OCSP-subca-LDAP is the internal database of the SubCA's OCSP. Procedure Create an OCSP installation file at a chosen location (e.g. /root/pki_rsa ) for generating certificate requests: 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... Run the pkispawn tool to install the OCSP subsystem: 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: First run the pkispawn tool with the --skip-configuration option to install the SubCA's OCSP instance: Customize the configuration files between the two installation steps Run the pkispawn tool to configure the OCSP: Verification Show the status of the installed OCSP instance: 7.7.3. Increase the SubCA's OCSP pkiconsole timeout Log in to rhcs10.example.com as root. Stop the SubCA's OCSP service: Edit /var/lib/pki/rhcs10-RSA-OCSP-subca/conf/server.xml to increase the timeout period: Start the SubCA's OCSP service: 7.7.4. Set the default AIA extension to point to this OCSP 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: Stop the SubCA: Edit the SubCA's CS.cfg and set the ca.defaultOcspUri variable to point to the OCSP. For example: Start the SubCA: 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 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.: 7.7.6. Login to the OCSP pkiconsole with client authentication Configure OCSP with authType=sslclientauth and import the role user certificate by following Configure pkiconsole login with client authentication . Login to pkiconsole with the client authentication certificate of the role user: 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 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 On rhds11.example.com as root: 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. Use the dscreate create-template command to create a template .cfg file at a chosen location (e.g. /root/pki_rsa ): Edit the .cfg file created in the step. Uncomment the below parameters and set them to customize the installation: Install the Directory Server instance: Add an ACI (Access Control Instruction) rule to allow anonymous bind access. By default, this is disabled. Create the ldapaci.ldif file at a chosen location (e.g. /root/pki_rsa/dirsrv/ ) with the following content: Run the ldapmodify command to add the ACI: Prepare the CRL publishing subtree: Create two files in the /root/pki_rsa/dirsrv directory with the following content: For the subca_pki_subtree.ldif file: For the subca_crl_subtree.ldif file: Add both entries to the CRL instance: 7.7.7.2. Configuring CRL publishing on the SubCA To configure CRL publishing: Add the ca.publish. properties: Stop the SubCA instance: Configure the following properties in the SubCA's CS.cfg configuration file (e.g. /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg ): NOTE Alternatively, you can use the ca-config-set command to update the properties. For example: And so on. You can check that the parameters were successfully updated by using the ca-config-show command. For example: Start the SubCA instance: Push the CRL and CA certificate to the LDAP directory via curl . For example: Disable the direct CA->OCSP CRL publishing method: Stop the SubCA: 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 : For example: Start the CA for the configuration change to take effect: Update the Directory Server using curl . For example: Display the CRL using curl : Run ldapsearch to verify that the CRL and the CA certificate are pushed to the LDAP directory: Disable certificate publishing for the SubCA (optional): Note The following procedure is to prevent a WARNING message in the debug logs like the following: Stop the SubCA: Edit /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg and set the following: Start the SubCA for the configuration change to take effect: 7.7.7.3. Configuring the OCSP to pull the CRLs from the LDAP server 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: Stop the OCSP: 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: 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. 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. 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. Start the OCSP for the ldapStore configuration to take effect: 7.7.7.4. Testing CRL publishing 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 : List the certificates in the database: Use the PKCS10Client tool to generate a PKCS10 certificate request: NOTE Use cat on the keyId file so it will be available for the step: Generate a CMC request: Create a CMCRequest configuration file, using the PKCS#10 request and private key id you obtained from the step. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the response using the CMCResponse command: 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: Push the CRL and CA certificate to the LDAP directory: Login to the SubCA's Agent UI in the browser. Select Update Revocation List and click Update . Click Update Directory Server and select: Update the certificate revocation list to the directory Update Certificate Manager certificate to the directory Click Update Directory . Wait for the OCSP's ldapStore refresh to happen (observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-subca/ocsp/logs/debug ). Check the certificate status by using the OCSPClient tool. For example, using the certificate serial number of user1 (in decimal): Revoke the certificate of user2 : Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: Verification 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. Wait until the 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: Select Update Revocation List and click Update . Click Update Directory Server and select: Update the certificate revocation list to the directory Update Certificate Manager certificate to the directory Click Update Directory . Once the ldapStore refresh completes, observe the debug file in /var/lib/pki/rhcs10-RSA-OCSP-subca/ocsp/logs/debug . 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): 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) 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 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 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: Show the status of the installed SubCA: Note down the Secure Agent, Admin and pkiconsole URLs. Perform a sanity test to verify the new SubCA Admin certificate was added successfully: First, find the serial number of the user1 certificate created in Section 7.7.7.4, "Testing CRL publishing" : Place a hold on user1 's certificate using the SubCA Agent's credentials: Make sure the SubCA's EE page is accessible on rhcs10.example.com . 7.8.2. Replace the temporary DS certificate (SubCA) 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: Stop DS: Use the certutil tool to generate the CSR: Important Edit the Server-Cert-subca.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Start DS: Remote copy the Server-Cert-subca.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Note For EC certificates, use the ECC profiles by setting: Submit the request using the HttpClient command: Process the CMC Response: 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Stop the SubCA's LDAP instance: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and the CA certificates in its chain one by one. For example: List the certificates: Start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 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: Stop the SubCA: List the certificate: Remove the temporary certificate from the nssdb: 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: To enable certificate revocation checks, in the respective /var/lib/pki/rhcs10-RSA-SubCA/conf/server.xml file: Set enableOCSP or enableRevocationCheck to true : Additionally, remove these two parameters and their assigned values: Disable the legacy revocation check method by editing the CA's CS.cfg file and setting the following to false : Start the SubCA instance: 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" ): Check the publishing of the file-based CRL: Display and verify the content of the CRL 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: Stop the CA service. Set the enableRevocationCheck or enableOCSP parameter to false (if it is currently set to true ) in CA's server.xml . Set the ca.crl.ServerCertCRL.publishOnStart= parameter to true in CA's CS.cfg . Start the CA service to regenerate the missing CRL file: After the CRL file has been recovered, stop the CA service once again. Revert the ca.crl.ServerCertCRL.publishOnStart= parameter to false in CA's CS.cfg . Set the enableRevocationCheck or enableOCSP parameter to true in CA's server.xml . 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 List the certificates in the CA: As the bootstrap admin user, list the users in the SubCA: 7.8.3. Increase the SubCA pkiconsole timeout On rhcs10.example.com : Stop the SubCA: Edit /var/lib/pki/rhcs10-RSA-SubCA/conf/server.xml to increase the timeout period: Start the SubCA: 7.8.4. Setting up CMC Shared Secret Authentication 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: Import the Issuance Protection Certificate into the nssdb: 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 This section describes the configuration for CMC Shared Token authentication, specific to LDAP and profile enablement. Procedure On rhcs10.example.com : Stop the SubCA: Optional step : To add the shrTok attribute to LDAP, use the ldapmodify command and enter the required information at each interactive > prompt. For example: Add the SharedToken authentication plugin by editing /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg to set the following properties: Configure the SubCA to use the HSM for CMC key wrapping: Edit /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg and set: cmc.token=NHSM-CONN-XC Also add the following entry: keyWrap.useOAEP=true Enable the CMC shared token enrollment profile for self-signed enrollment by configuring as follows: Make sure the enrollment profile caFullCMCSharedTokenCert.cfg is enabled ( enable=true ). For example: In case this shows enable=false , change to enable=true by editing caFullCMCSharedTokenCert.cfg . Start the SubCA to apply the changes: 7.8.4.2. Add an issuance protection certificate 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 Login on rhcs10.example.com as root . Use the PKCS10Client tool to generate a PKCS10 certificate request: 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 Verify that rsa_SubCA_AgentV has the correct certificate. The following two commands should result in the same certificate: NOTE You can obtain the Cert ID with the following command: Login on rhcs10.example.com as jsmith Place the certificate request file received, IssuanceProtectionSystemCert.csr , in the agent's own directory, e.g. /home/jsmith/certs_db . Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Get the CMC Response : Note down the serial number. It should match the same serial number shown when running the following command: Import the Issuance Protection Certificate into the agent nssdb for handling passphrase wrapping in the case of CMC SharedSecret enrollment: Import the Issuance Protection Certificate into the CA Login on rhcs10.example.com as the root user that requested the certificate. Import the Issuance Protection Certificate: Note Ignore this error message (BZ#1393668). Configure the SubCA to use the newly created IssuanceProtectionSystemCert : Stop the SubCA: Edit /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg to set ca.cert.issuance_protection.nickname=NHSM-CONN-XC:IssuanceProtectionSystemCert Start the SubCA: 7.8.4.3. Test the CMC Shared Token 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. Create a regular OS user, e.g. FooUser123 : 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: 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. 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: 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 , Create a client nssdb if it does not already exist: Import the CA trust chain into the nssdb: List the contents of the nssdb: Create a PKCS#10 request. The resulting request and private key id are to be used in the CMCRequest file in the step: Display the private key ID to have it available for the step: Generate a CMC request: Create a CMCRequest configuration file, using the PKCS#10 request and private key id you obtained from the step. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: 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" . Submit the request using the HttpClient command: Process the CMCResponse call: 7.8.5. Check for random serial numbers 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: 7.8.6. Create other SubCA role users 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 Configure the SubCA with sslclientauth and import the role user certificate as described in Section 7.13.6, "Configure pkiconsole login with client authentication" . Login to pkiconsole with the client authentication certificate of the role user: 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 If you wish to install additional RHCS instances, please continue with the 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 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): 7.9.1. Replace the temporary DS certificate (KRA) 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: Stop DS: Use the certutil tool to generate the CSR: Important Edit the Server-Cert-kra.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Remote copy the Server-Cert-kra.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and the CA certificates in its chain one by one. For example: List the certificates: Start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 7.9.2. Install the KRA instance 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.5, "Installing a DS instance for the KRA" , in our example, CC-RSA-KRA-LDAP is the KRA's internal database. Procedure Create a KRA installation file at a chosen location (e.g. /root/pki_rsa ): 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... Run the pkispawn tool to install the KRA subsystem: 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: First run the pkispawn tool with the --skip-configuration option to install the RHCS KRA instance: Customize the configuration files between the two installation steps Run the pkispawn tool to configure the KRA: Verification Show the status of the installed KRA instance: Note down the Secure Agent, Admin and pkiconsole URLs. Verify that the KRA agent web page is accessible. Import the KRA bootstrap administrator certificate into the nssdb: Verify the sanity of the KRA by running the kra-key-request-find command. It should display certificates: Note You can only perform the actual key archival and recovery tests after you complete the setup procedures detailed in the subsections. 7.9.3. Configure OAEP support for the KRA 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 Stop the KRA: 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 Start the KRA: Restart the SubCA: 7.9.4. Create KRA role users Create single-role admin, agent, audit users in the KRA by following the steps in Section 7.12, "Create PKI role users" . 7.9.5. Test key archival 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 . Create a client nssdb if it does not already exist: Create a CRMF request using the KRA transport certificate: 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: Export the KRA transport certificate using its serial number: Create the CRMF request using the transport certificate: Generate a CMC request: Create a CMCRequest configuration file, using the CRMF request and private key id you obtained from the step. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the response using the CMCResponse command: 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 Test the key recovery process with the following steps: As a KRA agent, go to the KRA's agent services page in the browser, and click the Recover Keys link. Tick the Certificate checkbox in order to search for the key by certificate: Parse the earlier response file to display the leaf certificate in base64 format, for example: 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 . 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. 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. 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 . 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 . A dialog pops up. Click on Save File to download the PKCS #12 file for the owner of the private key certificate. After receiving the PKCS #12 file, the certificate/keys owner can then restore the key into their Firefox nssdb. For example: You can now use the certificate again. 7.9.7. Increase the KRA pkiconsole timeout Stop the KRA: Increase the timeout period by editing the /var/lib/pki/rhcs10-RSA-KRA/conf/server.xml file: Then restart the KRA: 7.9.8. Login to the KRA pkiconsole with client authentication Configure the KRA with authType=sslclientauth and import the role user certificate by following Section 7.13.6, "Configure pkiconsole login with client authentication" . Login to pkiconsole with the client auth certificate of the role user: 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 If you wish to install additional RHCS instances, please continue with the 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 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): 7.10.1. Replace the temporary DS certificate (TKS) 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: Stop DS: Use the certutil tool to generate the CSR: Important Edit the Server-Cert-tks.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Remote copy the Server-Cert-tks.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and the CA certificates in its chain one by one. For example: List the certificates: Start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 7.10.2. Install the TKS instance 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.6, "Installing a DS instance for the TKS" , in our example, CC-RSA-TKS-LDAP is the TKS' internal database. Procedure Create a TKS installation file at a chosen location (e.g. /root/pki_rsa ): 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... Run the pkispawn tool to install the TKS subsystem: 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: First run the pkispawn tool with the --skip-configuration option to install the RHCS TKS instance: Customize the configuration files between the two installation steps Run the pkispawn tool to configure the KRA: Verification Show the status of the installed TKS instance: Note down the Secure Agent, Admin and pkiconsole URLs. 7.10.3. Configure OAEP support for the TKS 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 Stop the TKS: Edit the /var/lib/pki/rhcs10-RSA-TKS/tks/conf/CS.cfg configuration file and add the following line: keyWrap.useOAEP=true Start the TKS: 7.10.4. Create TKS Role users Create single-role admin, agent, audit users in the TKS by following the steps in Section 7.12, "Create PKI role users" . 7.10.5. Post-installation If you wish to install additional RHCS instances, please continue with the 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 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): 7.11.1. Replace the temporary DS certificate (TPS) 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: Stop DS: Use the certutil tool to generate the CSR: Important Edit the Server-Cert-tps.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Remote copy the Server-Cert-tps.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and the CA certificates in its chain one by one. For example: List the certificates: Start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 7.11.2. Configuring a TPS authentication database 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 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: 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. Create the TPS AuthDB Directory Server installation file at a chosen location (e.g. /root/pki_rsa ): Edit the .cfg file created in the step. Uncomment the below parameters and set them to customize the installation: Install the Directory Server instance: Add an ACI (Access Control Instruction) rule to allow anonymous bind access. By default, this is disabled. Create the ldapaci.ldif file at a chosen location (e.g. /root/pki_rsa/dirsrv/ ) with the following content: Run the ldapmodify command to add the ACI: 7.11.2.2. Replace the temporary DS certificate (TPS AuthDB) 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: Stop DS: Use the certutil tool to generate the CSR: Important Edit the Server-Cert-tps-auth.csr output file obtained above to remove the few lines before "Begin Certificate Request". For example: The CSR file must start with the line " -----BEGIN CERTIFICATE REQUEST----- " and end with the line " -----END CERTIFICATE REQUEST----- ". Remote copy the Server-Cert-tps-auth.csr file to the system where the CA resides. For example: Issue the real DS certificate On rhcs10.example.com , issue the actual SSL server certificate: Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the CMC Response: 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. 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: 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: Remote copy the new Server-Cert certificate to rhds11.example.com . For example: Replace the temporary DS certificate On rhds11.example.com , replace the temporary DS certificate with the actual DS certificate: Save the contents of the dirsrv directory into a backup directory: Delete the old DS certificates: Import the newly created DS certificate and the CA certificates in its chain one by one. For example: List the certificates: Start DS: Test to confirm that the LDAP server is up and running (in case of a separate system, test on the CA host as well): If testing on a separate system, include the CA certificate chain in front of the ldapsearch command, for example: 7.11.3. Install the TPS instance 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 You are logged in to rhcs10.example.com as root user. You have Section 7.1.2.7, "Installing a DS instance for the TPS" , in our example, CC-RSA-TPS-LDAP is the TPS's internal database. Procedure Create a TPS installation file at a chosen location (e.g. /root/pki_rsa ): 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... Run the pkispawn tool to install the TPS subsystem: 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: First run the pkispawn tool with the --skip-configuration option to install the RHCS TPS instance: Customize the configuration files between the two installation steps Run the pkispawn tool to configure the TPS: Verification Show the status of the installed TPS instance: Note down the Secure Agent, Admin and pkiconsole URLs. Verify that the TPS agent web page is accessible. Import the TPS bootstrap administrator certificate into the nssdb: Note You can only perform the actual smartcard token enrollment tests after you complete the setup procedures detailed in the subsections. 7.11.4. Testing token-side key generation 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 Temporarily update the userKey profile to only generate signing certificates: Stop the TPS: 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: Start the TPS: Create a new user for testing token enrollment, e.g. jdoe : First check if the TPS WebUI is up: Create a .cfg file for a POSIX user as follows: Add the following content to the file and save: Configure anonymous bind access: Create an ldif file containing the following: Run the following to enable anonymous bind access: Run the ldapadd command with the previously created .cfg file to add the jdoe user: Test token-side key generation Test token-side key generation using the tpsclient tool to format and enroll a token. On a separate non-FIPS -enabled system, install the tpsclient package. For example: Note If you are testing on a Fedora system, the corresponding package providing the tpsclient tool would be dogtag-pki-tools . Add the TPS server hostname and IP address to the /etc/hosts file: Test the format and enrollment for the newly created user: Prepare to format a token for jdoe . Create a .txt file: Add the following content. The host and port values should match your own; the port should be a non-SSL port. Prepare to enroll a token for jdoe . Create a .txt file: Add the following content. The host and port values should match your own; the port should be a non-SSL port. Format jdoe 's token. The operation should succeed.: Enroll jdoe 's token. The operation should succeed: Revert the changes after testing To delete the added test token after verification: Log in to the TPS WebUI at https://rhcs10.example.com:25443/tps/ui/ Click Tokens and select the token in check box. Click Remove , then confirm. Alternatively , you can use CLI commands to delete the test token. For example: Revert op.enroll.userKey.keyGen.keyType.num back to 2: Stop the TPS: 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.: Start the TPS: 7.11.5. Configure OAEP support for the TPS 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 Stop the TPS: Edit the /var/lib/pki/rhcs10-RSA-TPS/tps/conf/CS.cfg configuration file and add the following line: keyWrap.useOAEP=true Start the TPS: 7.11.6. Configuring AES support for TMS Server-Side-Keygen 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: For format: Note that you must then configure any other profiles (including external registration) to use this applet. For example: 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 : 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 : TKS CS.cfg 7.11.7. Setting key sizes It is important to set all keysizes to be greater or equal to 2048. E.g: 7.11.8. Setup TPS phoneHome Edit the phoneHome.xml configuration file. For example: Set the correct http port for the TPS. For example: It will now look like the following: Save and restart the TPS. 7.11.9. Create TPS Role users Create single-role admin, agent, audit users in the TPS by following the steps in Section 7.12, "Create PKI role users" . 7.11.10. Post-installation If you wish to install additional RHCS instances, please continue with the 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 This section describes the user configuration that takes place after the subsystems installation. Important Some of the examples in the 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 Prior to performing the recommended procedure to issue any certificate, make sure your SubCA bootstrap admin certificate/key is ready to perform the tasks. Login to rhcs10.example.com as root user. 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" : 7.12.2. Admin users adminV (this user will have a v alid certificate throughout testing) adminR (this user will have a r evoked certificate) adminE (this user will have an e xpired certificate) adminTCA (this user's certificate will be signed by a t rusted 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 u n t rusted CA ) Note This last one requires a second CA setup! 7.12.2.1. Setting up certificate and role for a pki administrator 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 section. 7.12.2.1.1. Generating a CSR for a pki administrator 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. Login to rhcs10.example.com as an 'Administrator' (a non-root user), in this example jgenie . Create a client nssdb in case it does not already exist: 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. 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 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 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: Place the CSR file (rsa_SubCA_AdminV.req) received from jgenie to the /root/.dogtag/pki_rsa_bootstrap/certs_db directory. Generate a CMC request: Create a CMCRequest configuration file. For example: NOTE For request.privKeyId= <private key id> : the private key id to use here is the one generated from the step. See the output message : 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='USDkey_id'/g' /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AdminV.cfg Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: Process the response using CMCResponse to display all certificates in chain individually in PEM format: Copy the agent certificate to /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AdminV_b64.crt : 7.12.2.1.3. Creating the pki admin user and associating the new certificate 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: Create a user, in this example rsa_SubCA_AdminV : 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 . Add the new user to the Administrators group: 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. Verify that the user got added to the Administrators group: 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. Add the rsa_SubCA_AdminV certificate to the pki role user: 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. 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 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. Login to rhcs10.example.com as the pki administrator whose certificate was issued in the section, e.g. jgenie . Install the certificate, e.g. rsa_SubCA_AdminV : Back up the role user rsa_SubCA_AdminV certificate by creating a .p12 file, here for example with the password SECret.123 : 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: 7.12.3. Agent users agentV (this user will have a v alid certificate throughout testing) agentR (this user will have a r evoked certificate) agentE (this user will have an e xpired certificate) agentTCA (this user's certificate will be signed by a t rusted CA ) agentUTCA (this user's certificate will be issued by an u ntrusted CA ) Note This last one requires a second CA setup! 7.12.3.1. Setting up certificate and role for a pki agent 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 section. 7.12.3.1.1. Generating a CSR for a pki agent 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 ). Create a client nssdb if it does not already exist: 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. 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 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 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: Place the CSR file (rsa_SubCA_AgentV.req) received from jsmith to the /root/.dogtag/pki_rsa_bootstrap/certs_db directory. Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: 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. Copy the agent certificate to /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AgentV_b64.crt . 7.12.3.1.3. Creating the pki agent user and associating the new certificate Create the rsa_SubCA_AgentV user: 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 . Add rsa_SubCA_AgentV to the Certificate Manager Agents group: 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 ". Verify that the user rsa_SubCA_AgentV got added to the Certificate Manager Agents group. 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 ". Add the rsa_SubCA_AgentV certificate to the pki role user: 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. 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 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. Login to rhcs10.example.com as an 'Agent' (a non-root user, for example jsmith ). Install the rsa_SubCA_AgentV certificate: Backup the role user rsa_SubCA_AgentV certificate by creating a .p12 file, here for example with the password SECret.123 : 7.12.3.1.5. Initializing Browser for TLS mutual authentication 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 auditV (this user will have a v alid certificate throughout testing) 7.12.4.1. Setting up certificate and role for a pki auditor 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 section. 7.12.4.1.1. Generating a CSR for a pki auditor 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 ). Create a client nssdb if it does not already exist: 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. 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 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 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 Place the CSR file ( rsa_SubCA_AuditV.req ) received from aguru to the /root/.dogtag/pki_rsa_bootstrap/certs_db directory. Generate a CMC request: Create a CMCRequest configuration file. For example: Generate the request using the CMCRequest command: Submit the CMC request: Create a HttpClient configuration file. For example: Submit the request using the HttpClient command: 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. Copy the auditor certificate to /root/.dogtag/pki_rsa_bootstrap/certs_db/rsa_SubCA_AuditV_b64.crt : 7.12.4.1.3. Creating the pki auditor user and associating the new certificate This procedure is to be performed by an existing pki admin user, in this case, the root user that holds the SubCA bootstrap certificate. Create the rsa_SubCA_AuditV user: 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 . Add rsa_SubCA_AuditV to the Auditors group: 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. Verify that the user rsa_SubCA_AuditV got added to the Auditors group. 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. Add the rsa_SubCA_AuditV certificate to the pki role user: 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. 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 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. Login to rhcs10.example.com as an 'Auditor' (a non-root user, for example aguru ). Install the rsa_SubCA_AuditV certificate: Backup the role user rsa_SubCA_AuditV certificate by creating a .p12 file, here for example with the password SECret.123 : 7.12.5. TPS operators The process for TPS operators is similar to the process for Auditors. 7.12.6. Removing the bootstrap admin users from the authentication databases (optional) 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. List the certificates in the authentication nssdb to determine the installed bootstrap admin certificates for the SubCA, KRA and OCSP. For example: Delete the SubCA, OCSP and KRA bootstrap admin user certificates: Optional : If TMS is of interest, you can remove the TKS and TPS bootstrap admin users in the same manner. 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 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: Configuring or adding certificate enrollment profiles (CA). For details, see Chapter 11, Configuring certificate profiles . 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 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: 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: 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: First, display the list of available time zones: Based on the above list, set your desired time zone with this command: 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 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" . 7.13.3. Setting non-SHA1 message digest algorithm for SubjectKeyIdentifier extension in a certificate 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: Open the enrollment profile for the certificate: Add the following parameter: 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: 7.13.4. Configuration for CMC enrollment and revocation (CA) You can do certificate enrollments and revocation via CMC. The configuration is described in Section 9.6, "Configuration for CMC" . Specifically: For details about enabling the CMC Shared Token Feature, see Section 9.6.3, "Enabling the CMC Shared Secret feature" . For details about enabling the PopLinkWitness feature, see Section 9.6.2, "Enabling the PopLinkWitnessV2 feature" . For details about enabling CMCRevoke for the web user interface, see Section 9.6.4, "Enabling CMCRevoke for the Web User Interface" . 7.13.5. Enable Nuxwdog (watchdog service) 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 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 Add the cms.tokenList=<HSM_TOKEN_NAME> parameter to CS.cfg , for example: Move the password file to another directory: Enable the Nuxwdog service: 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: Verification steps: Check the status of the RootCA instance using Nuxwdog: 7.13.5.2. Enable Nuxwdog for the SubCA 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 Add the cms.tokenList=<HSM_TOKEN_NAME> parameter to CS.cfg , for example: Move the password file to another directory: Enable the Nuxwdog service: Start the instance using the Nuxwdog service. Note that once you have successfully enabled Nuxwdog, the CS instance start/stop/restart/status command differs: Verification steps: Check the status of the SubCA instance using Nuxwdog: 7.13.5.3. Enable Nuxwdog for the OCSPs 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: Add the cms.tokenList=<TOKEN_NAME> parameter to CS.cfg , for example: Move the password file to another directory: Enable the Nuxwdog service: Start the instance using the Nuxwdog service: 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: 7.13.5.4. Enable Nuxwdog for the KRA 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 Add the cms.tokenList=<TOKEN_NAME> parameter to the CS.cfg file, for example: Move the password file to another directory: Enable the Nuxwdog service: Start the instance using the Nuxwdog service: Verification steps: Check the status of the KRA instance using Nuxwdog: 7.13.5.5. Enable Nuxwdog for the TKS 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 Add the cms.tokenList=<TOKEN_NAME> parameter to the CS.cfg file, for example: Move the password file to another directory: Enable the Nuxwdog service: Start the instance using the Nuxwdog service: Verification steps: Check the status of the TKS instance using Nuxwdog: 7.13.5.6. Enable Nuxwdog for the TPS 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 Add the cms.tokenList=<TOKEN_NAME> parameter to the CS.cfg file, for example: Move the password file to another directory: Enable the Nuxwdog service: Start the instance using the Nuxwdog service: Verification steps: Check the status of the TPS instance using Nuxwdog: 7.13.6. Configure pkiconsole login with client authentication 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. Login to rhcs10.example.com as root. Stop the server that needs a console login with client authentication. OR if using the Nuxwdog watchdog: Change directory at /var/lib/pki/ <instance name> / <subsystem> /conf . For example, if changing to the RootCA conf directory: Modify the CS.cfg file to change the authType from pwd to sslclientauth , e.g.: 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: Start the server: OR if using the Nuxwdog watchdog: Procedure Each RHCS administrator needs to perform some setup prior to using pkiconsole with TLS connections. Login to rhcs10.example.com as a non-root admin user (for example: jgenie ). 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. Create a nssdb, if it does not already exist: Import the role user certificate (e.g. /home/jgenie/certs_db/rsa_SubCA_AdminV.p12 ): Import the CA certificates: Verification: Verify the admin user certificate for authentication against the server. For example: Verify that pkiconsole can connect to the ca using client authentication: Login as a pki admin user (e.g. jgenie), for example: Run pkiconsole . For example: 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: Install xauth as a root user on rhcs10.example.com : Login again as a RHCS admin user to run pkiconsole . For example: 7.13.7. Enable signed audit Logging Prerequisite You are logged onto rhcs10.example.com as root user. Procedure Stop the instance. For example, for the KRA: OR if using the Nuxwdog watchdog: Set the log.instance.SignedAudit.logSigning attribute to true in the CS.cfg file ( false by default). For example: Start the instance. For example: OR if using the Nuxwdog watchdog: 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) Auditors (e.g - rsa_SubCA_AuditV ) can access the signed audit logs using the following procedure. Procedure Login to rhcs10.example.com as an Auditor (a non-root user, e.g. - aguru ). List the available audit log files: In this example, there is only one file, ca_audit , but you can have multiple audit log files. As an Auditor, retrieve the audit log file and store it locally: If you have multiple log files, retrieve them one by one. Verify the signed audit logs using the AuditVerify tool: Import the SubCA audit signing certificate to the nssdb: Create a file containing a list of audit log files in chronological order: Run the AuditVerify tool: 7.13.9. Enable OS-level (Operational Environment) audit logs 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: Important Make sure the file /etc/audit/rules.d/audit.rules remains present on the system with the following content: 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. Create the file /etc/audit/rules.d/rhcs-audit-log-deletion.rules with the following contents: Then restart the auditd service: 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. Create the /etc/audit/rules.d/rhcs-audit-nssdb-access.rules file with the following contents, replacing <instance name> with the current instance: For each file ( <file> ) in /etc/pki/ <instance name> /alias , add the following line to /etc/audit/rules.d/rhcs-audit-nssdb-access.rules : 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: Then restart auditd : 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. Create the /etc/audit/rules.d/rhcs-audit-rhcs_audit_time_change.rules file with the following contents: Then restart auditd : 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. Create the /etc/audit/rules.d/rhcs-audit-config-access.rules file with the following contents: Additionally, add for each subsystem in the /etc/pki/instance_name/ directory the following contents: 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: 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 After adding each audit rule and restarting the auditd service, you can validate that the new rules were added: 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: Access the SubCA alias directory: Check for the audit event: 7.13.10. Verifying peer certificate for RHCS subsystems 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 Important This section describes an alternative method for enabling revocation checks in an OCSP subsystem. For the preferred method, see the 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 : 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: 7.13.10.2. Enabling OCSP for the CA / KRA / TKS / TPS 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: The OCSP AIA extension (also known as the ocsp-aia in this document). Note that in most cases, OCSP-aia is the recommended method over CRL Distribution Points. The CRL Distribution Point extension. Note that in general CRL Distribution Point is only recommended to be used in the case when OCSP is not usable. See Section 7.13.10.3, "Enabling peer certificate status check without OCSP on the CA" for more information 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. Stop the KRA: OR if using the Nuxwdog watchdog: Edit the /var/lib/pki/rhcs10-RSA-KRA/conf/server.xml file to configure the Connector name="Secure" section: Set the enableRevocationCheck parameter to true . Note that enableRevocationCheck is also known as enableOCSP . Only set one and not both. Make sure you remove these two parameters and their assigned values: ocspResponderURL ocspResponderCertNickname For example: Start the KRA: OR if using the Nuxwdog watchdog: 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 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 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 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 . Edit the server.xml file, navigate to the main SSL port's Connector declaration and find the SSLHostConfig element. Modify the SSLHostConfig element with the following configuration: 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 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: 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: 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: Note You must restart each server instance for the modifications to take effect, e.g.: OR if using the Nuxwdog watchdog: ... 7.13.11.3. Configuring the ciphers for a DS instance 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 : Enable the intended ciphers (use the non-SSL port of the DS instance): Restart the DS instance: Verify by listing the enabled ciphers: 7.13.12. Requiring TLS mutual authentication for connections to CS 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 . Edit the server.xml file and search for the certificateVerification= parameter. Change the parameter value from optional to required : 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: 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: Now, with the new restriction, you will need to do the following: 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 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 : Section 7.5.1, "Replace the temporary DS certificate (RootCA)" for the RootCA. Section 7.8.2, "Replace the temporary DS certificate (SubCA)" for the SubCA. 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: For example After configuring, restart the Directory Server. For example: 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 Stop the CS instance you want to configure: OR if using the Nuxwdog watchdog: In the CS.cfg , please add the RHCS instance's subsystem certificate nickname to internaldb.ldapauth.clientCertNickname , and remove the two unused entries: As shown below: Restart the CS instance: OR if using the Nuxwdog watchdog: 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 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: 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. 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: Procedure Shut down all Certificate System servers. For example: OR if using the Nuxwdog watchdog: Find out which file the system is basing its policies on: If you followed the installation procedure, you should see "FIPS" as the command output. Copy the current policies to our new custom policy file, for modifications: Edit the custom policy file, for example: Make the following modifications, then save the file: Change the assignment of the groups parameter from: to Change the assignment of the key_exchange parameter from: to Change the assignment of the min_dh_size parameter from to Register the custom site policy: 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. Edit the nss.config file, for example: Under the assignment for the config parameter, in the allow= string, insert the following string directly after the dtls-version-min=dtls1.2 setting: The resulting config line should look like the following: Start or restart any nss-based applications / servers / clients to see the changes apply. For example: ... OR if using the Nuxwdog Watchdog: ... 7.13.15. Enabling the access banner 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: Verification: Validate that the banner does not contain invalid characters: To display the currently configured banner: 7.13.16. Determining the product version 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: 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.
/usr/sbin/groupadd -r pkiadmin /usr/sbin/useradd -g pkiadmin -d /home/jgenie -s /bin/bash -c "Red Hat Certificate System Administrator Jane Genie" -m jgenie /usr/sbin/useradd -c "Red Hat Certificate System Agent John Smith" -m jsmith /usr/sbin/useradd -c "Red Hat Certificate System Auditor Astrid Guru" -m aguru /usr/sbin/usermod -a -G pkiadmin pkiuser /usr/sbin/usermod -a -G nfast pkiuser /usr/sbin/usermod -a -G hsmusers pkiuser /usr/sbin/usermod -a -G nfast jgenie /usr/sbin/usermod -a -G hsmusers jgenie groups pkiuser jgenie pkiuser : pkiuser nfast pkiadmin jgenie : pkiadmin nfast 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 dscreate create-template /root/pki_rsa/ldap-template.cfg dscreate from-file /root/pki_rsa/rootca-ldap.cfg Starting installation Completed installation for CC-RSA-RootCA-LDAP 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 certutil -L -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-rootca-cert.pem scp /opt/pki_rsa/temp-dirsrv-rootca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-rootca-cert.pem 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 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 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 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 dscreate from-file /root/pki_rsa/ocsp-rootca-ldap.cfg Starting installation Completed installation for CC-RSA-OCSP-rootca-LDAP 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 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 scp /opt/pki_rsa/temp-dirsrv-ocsp-rootca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-ocsp-rootca-cert.pem 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 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 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 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 dscreate from-file /root/pki_rsa/subca-ldap.cfg Starting installation Completed installation for CC-RSA-SubCA-LDAP 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 certutil -L -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-subca-cert.pem scp /opt/pki_rsa/temp-dirsrv-subca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-subca-cert.pem 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 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 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 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 dscreate from-file /root/pki_rsa/ocsp-subca-ldap.cfg Starting installation Completed installation for CC-RSA-OCSP-subca-LDAP 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 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 scp /opt/pki_rsa/temp-dirsrv-ocsp-subca-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-ocsp-subca-cert.pem 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 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 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 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 dscreate from-file /root/pki_rsa/kra-ldap.cfg Starting installation Completed installation for CC-RSA-KRA-LDAP 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 certutil -L -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-kra-cert.pem scp /opt/pki_rsa/temp-dirsrv-kra-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-kra-cert.pem 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 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 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 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 dscreate from-file /root/pki_rsa/tks-ldap.cfg Starting installation Completed installation for CC-RSA-TKS-LDAP 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 certutil -L -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-tks-cert.pem scp /opt/pki_rsa/temp-dirsrv-tks-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-tks-cert.pem 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 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 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 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 dscreate from-file /root/pki_rsa/tps-ldap.cfg Starting installation Completed installation for CC-RSA-TPS-LDAP 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 certutil -L -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -n "Self-Signed-CA" -a -o /opt/pki_rsa/temp-dirsrv-tps-cert.pem scp /opt/pki_rsa/temp-dirsrv-tps-cert.pem root@rhcs10.example.com:/opt/pki_rsa/temp-dirsrv-tps-cert.pem 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 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 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 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 pki_instance_name= instance_name pki_hostname= server.example.com pki_https_port= port_number pki_http_port= port_number 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 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 SHA256withRSA SHA384withRSA SHA512withRSA 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 SHA256withEC SHA384withEC SHA512withEC nistp256 nistp384 nistp521 pki_client_dir= bootstrap_admin_directory pki_admin_password=password pki_client_database_password=password pki_client_pkcs12_password=password 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 certutil -L -d /etc/dirsrv/slapd-instance_name/ \ -n "server-cert" -a -o /root/ds.crt 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 pki_ajp_port= Tomcat_AJP_port pki_tomcat_server_port= Tomcat_server_port pkispawn -s [CA, OCSP, KRA, TKS, TPS] -f cs_inst.cfg -debug pkispawn -s CA -f rootca_inst.cfg --precheck --debug pkispawn -s CA -f rootca_inst.cfg --debug pkispawn -s [CA, OCSP, KRA, TKS, TPS] -f cs_inst.cfg --skip-configuration -debug pkispawn -s CA -f rootca_inst.cfg --skip-configuration --precheck --debug pkispawn -s CA -f rootca_inst.cfg --skip-configuration --debug pkispawn -s [CA, OCSP, KRA, TKS, TPS] -f cs_inst.cfg --skip-installation -debug pkispawn -s CA -f rootca_inst.cfg --skip-installation --precheck --debug pkispawn -s CA -f rootca_inst.cfg --skip-installation --debug cd /root/pki_rsa vi rootca_inst.cfg [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 pkispawn -s CA -f rootca_inst.cfg --debug pki-server status rhcs10-RSA-RootCA pki -p 8443 -h rhcs10.example.com ca-cert-find 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)? cd /root/pki_rsa vi rootca_inst.cfg [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 pkispawn -s CA -f rootca_inst.cfg --skip-configuration --debug vi /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/caCert.profile 7.default.params.messageDigest=SHA-256 vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caInstallCACert.cfg vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCcaCert.cfg policyset.caCertSet.8.default.params.messageDigest=SHA-256 vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caInternalAuthAuditSigningCert.cfg policyset.auditSigningCertSet.2.constraint.params.range=720 policyset.auditSigningCertSet.2.default.params.range=720 pkispawn -s CA -f rootca_inst.cfg --skip-installation --debug pki-server status rhcs10-RSA-RootCA pki -p 8443 -h rhcs10.example.com ca-cert-find 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)? 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 pki-server stop rhcs10-RSA-RootCA 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/USDline; sed -i 's/^enable=true/enable=false/g' /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/USDline; done sed -i 's/^visible=true/visible=false/' /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCUserCert.cfg pki-server start rhcs10-RSA-RootCA certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias -n "CA Signing Cert - rhcs10-RSA-RootCA" -a > /opt/pki_rsa/rootCA.pem cp /opt/pki_rsa/rootCA.pem /opt/pki_rsa/ca-chain.pem scp /opt/pki_rsa/rootCA.pem root@rhds11.example.com:/opt/pki_rsa scp /opt/pki_rsa/ca-chain.pem root@rhds11.example.com:/opt/pki_rsa echo "TLS_CACERT /opt/pki_rsa/ca-chain.pem" >> /etc/openldap/ldap.conf dsctl slapd-CC-RSA-RootCA-LDAP restart 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 -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-init certutil -L -d /root/.dogtag/pki_rsa_bootstrap/certs_db 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 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 ---------------------------------------- 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 pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 8443 -n "PKI Bootstrap Administrator for RSA-RootCA" ca-user-find ----------------- 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 pki -p 8443 ca-cert-find | grep -i serial certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" pki-server stop rhcs10-RSA-RootCA cp /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg.bak.<date> mkdir /var/lib/pki/rhcs10-RSA-RootCA/crl chown pkiuser.pkiuser /var/lib/pki/rhcs10-RSA-RootCA/crl 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 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 ca.publish.rule.instance.LdapCrlRule.predicate=issuingPointId==MasterCRL 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 ca.crl.ServerCertCRL.signingAlgorithm=SHA512withEC <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> semanage port -a -t http_port_t -p tcp 8085 firewall-cmd --permanent --add-port=8085/tcp firewall-cmd --reload ValueError: Port tcp/8085 already defined semanage port -l | grep <port> semanage port -m -t http_port_t -p tcp 8085 mkdir -p /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost chown -R pkiuser:pkiuser /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost <Context docBase="/var/lib/pki/rhcs10-RSA-RootCA/crl"> <Resources allowLinking="true" cachingAllowed="false" /> </Context> chown pkiuser:pkiuser /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost/crl.xml 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 ... 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 ... 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 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 profile.list=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP,acmeServerCert,caCMCserverCert,caCMCECserverCert, ... ca.crl.ServerCertCRL.alwaysUpdate=true pki-server start rhcs10-RSA-RootCA ls -l /opt/pki_rsa/ca-chain.pem cat /opt/pki_rsa/ca-chain.pem dsctl slapd-CC-RSA-OCSP-rootca-LDAP stop 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 vi /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/Server-Cert-ocsp-rootca.csr 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-rootca_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-ocsp-rootca.cfg ### 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 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-rootca.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a 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/ cp -r /etc/dirsrv/slapd-CC-RSA-OCSP-rootca-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-OCSP-rootca-LDAP/ 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" 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" 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 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 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 dsctl slapd-CC-RSA-OCSP-rootca-LDAP start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :6636 -b "dc=example,dc=com" -w SECret.123 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 cd /root/pki_rsa vi ocsp_rootca_inst.cfg [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 pkispawn -s OCSP -f ocsp_rootca_inst.cfg --debug pkispawn -s OCSP -f ocsp_rootca_inst.cfg --skip-configuration --debug pkispawn -s OCSP -f ocsp_rootca_inst.cfg --skip-installation --debug pki-server status rhcs10-RSA-OCSP-rootca pki-server stop rhcs10-RSA-OCSP-rootca <Connector name="Secure" port="33443" ... connectionTimeout="3000000" pki-server start rhcs10-RSA-OCSP-rootca pki-server stop rhcs10-RSA-RootCA ca.defaultOcspUri=http://rhcs10.example.com:33080/ocsp/ee/ocsp pki-server start rhcs10-RSA-RootCA 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 ---------------------------------------- pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:33443/ocsp dscreate create-template /root/pki_rsa/rootca-crl-publish-ldap.cfg 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 dscreate from-file /root/pki_rsa/rootca-crl-publish-ldap.cfg Starting installation Completed installation for CC-RSA-RootCA-CRL-PUBLISH 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";) ldapmodify -x -h rhds11.example.com -p 12389 -D 'cn=Directory Manager' -W -f /root/pki_rsa/dirsrv/ldapaci.ldif dn: dc=pki,dc=example,dc=com objectClass: domain dc: pki dn: dc=crl,dc=pki,dc=example,dc=com objectClass: domain dc: crl ldapadd -x -H ldap://rhds11.example.com:12389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/rootca_pki_subtree.ldif ldapadd -x -H ldap://rhds11.example.com:12389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/rootca_crl_subtree.ldif pki-server stop rhcs10-RSA-RootCA 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= USDsubj.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= USDsubj.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 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=\USDsubj.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=\USDsubj.cn,dc=crl,dc=pki,dc=example,dc=com 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=\USDsubj.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=\USDsubj.cn,dc=crl,dc=pki,dc=example,dc=com pki-server start rhcs10-RSA-RootCA 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> pki-server stop rhcs10-RSA-RootCA ca.publish.rule.instance.ocsprule- <host/port info> .enable=false ca.publish.rule.instance.ocsprule-rhcs10-example-com-33443.enable=false pki-server start rhcs10-RSA-RootCA 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 - 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 - ldapsearch -x -D "cn=Directory Manager" -h "rhds11.example.com" -p 12389 -b "dc=example,dc=com" -w SECret.123 . . . 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 . . . 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 pki-server stop rhcs10-RSA-RootCA ca.publish.cert.enable=false pki-server start rhcs10-RSA-RootCA pki-server stop rhcs10-RSA-OCSP-rootca 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 debug.level=0 pki-server start rhcs10-RSA-OCSP-rootca 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 . . . 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 cat /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req.keyId; echo vi cmcRequest_p10_user1.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/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> 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_user1.cfg ### 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 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 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 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 vi cmc-agent-signed-revoke.cfg ### 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 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 vi HttpClient.revoke.agentSigned.cfg ### 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 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 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 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 ls /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt dsctl slapd-CC-RSA-RootCA-LDAP stop 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 vi /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/Server-Cert-rootca.csr dsctl slapd-CC-RSA-RootCA-LDAP start 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-rootca_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-rootca.cfg ### 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 servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECserverCertWithCRLDP 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-rootca.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n " CA Signing Cert - rhcs10-RSA-RootCA " -a scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-rootca.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ dsctl slapd-CC-RSA-RootCA-LDAP stop cp -r /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-RootCA-LDAP/ certutil -D -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt -n "Server-Cert" certutil -D -d /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-RootCA-LDAP/pwdfile.txt -n "Self-Signed-CA" 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 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 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 dsctl slapd-CC-RSA-RootCA-LDAP start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :636 -b "dc=example,dc=com" -w SECret.123 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 pki-server stop rhcs10-RSA-RootCA 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 certutil -D -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "DS temp CA certificate" enableOCSP=true or enableRevocationCheck=true ocspResponderURL ocspResponderCertNickname auths.revocationChecking.enabled=false pki-server start rhcs10-RSA-RootCA 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 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 pki-server stop rhcs10-RSA-RootCA pki-server start rhcs10-RSA-RootCA pki -p 8443 ca-cert-find pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 8443 -n "PKI Bootstrap Administrator for RSA-RootCA" ca-user-find cd /root/pki_rsa vi subca_inst.cfg [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 pkispawn -s CA -f subca_inst.cfg --debug pki-server status rhcs10-RSA-SubCA pki -p 31443 -h rhcs10.example.com ca-cert-find 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)? cd /root/pki_rsa vi subca_inst.cfg [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 pkispawn -s CA -f subca_inst.cfg --skip-configuration --debug vi /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/caCert.profile 7.default.params.messageDigest=SHA-256 vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caInstallCACert.cfg vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCcaCert.cfg policyset.caCertSet.8.default.params.messageDigest=SHA-256 vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caInternalAuthAuditSigningCert.cfg policyset.auditSigningCertSet.2.constraint.params.range=720 policyset.auditSigningCertSet.2.default.params.range=720 pkispawn -s CA -f subca_inst.cfg --skip-installation --debug pki-server status rhcs10-RSA-SubCA pki -p 8443 -h rhcs10.example.com ca-cert-find 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)? certutil -L -d /var/lib/pki/rhcs10-RSA-SubCA/alias -n "CA Signing Cert - rhcs10-RSA-SubCA" -a > /opt/pki_rsa/subCA.pem cat /opt/pki_rsa/subCA.pem /opt/pki_rsa/rootCA.pem > /opt/pki_rsa/ca-chain.pem scp /opt/pki_rsa/subCA.pem root@rhds11.example.com:/opt/pki_rsa scp /opt/pki_rsa/ca-chain.pem root@rhds11.example.com:/opt/pki_rsa dsctl slapd-CC-RSA-SubCA-LDAP restart 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 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 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 ---------------------------------------- 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 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 pki-server stop rhcs10-RSA-SubCA 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/USDline; sed -i 's/^enable=true/enable=false/g' /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/USDline; done 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 pki-server start rhcs10-RSA-SubCA pki-server stop rhcs10-RSA-SubCA cp /var/lib/pki/rhcs10-RSA-SubCA/conf/CS.cfg /var/lib/pki/rhcs10-RSA-SubCA/conf/CS.cfg.bak.<date> mkdir /var/lib/pki/rhcs10-RSA-SubCA/crl chown pkiuser.pkiuser /var/lib/pki/rhcs10-RSA-SubCA/crl 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 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 ca.publish.rule.instance.LdapCrlRule.predicate=issuingPointId==MasterCRL 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 ca.crl.ServerCertCRL.signingAlgorithm=SHA512withEC <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> semanage port -a -t http_port_t -p tcp 31085 firewall-cmd --permanent --add-port=31085/tcp firewall-cmd --reload ValueError: Port tcp/31085 already defined semanage port -l | grep <port> semanage port -m -t http_port_t -p tcp 31085 mkdir -p /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost chown -R pkiuser:pkiuser /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost <Context docBase="/var/lib/pki/rhcs10-RSA-SubCA/crl"> <Resources allowLinking="true" cachingAllowed="false" /> </Context> chown pkiuser:pkiuser /var/lib/pki/rhcs10-RSA-SubCA/conf/CRL/localhost/crl.xml 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 ... 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 ... 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 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 profile.list=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP,acmeServerCert,caCMCserverCert,caCMCECserverCert, ... ca.crl.ServerCertCRL.alwaysUpdate=true pki-server start rhcs10-RSA-SubCA ls -l /opt/pki_rsa/ca-chain.pem cat /opt/pki_rsa/ca-chain.pem dsctl slapd-CC-RSA-OCSP-subca-LDAP stop 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 vi /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/Server-Cert-ocsp-subca.csr 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-ocsp-subca_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-ocsp-subca.cfg ### 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 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-ocsp-subca.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a 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/ cp -r /etc/dirsrv/slapd-CC-RSA-OCSP-subca-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-OCSP-subca-LDAP/ 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" 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" 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 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 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 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 dsctl slapd-CC-RSA-OCSP-subca-LDAP start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :11636 -b "dc=example,dc=com" -w SECret.123 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 cd /root/pki_rsa vi ocsp_subca_inst.cfg [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 pkispawn -s OCSP -f ocsp_subca_inst.cfg --debug pkispawn -s OCSP -f ocsp_subca_inst.cfg --skip-configuration --debug pkispawn -s OCSP -f ocsp_subca_inst.cfg --skip-installation --debug pki-server status rhcs10-RSA-OCSP-subca pki-server stop rhcs10-RSA-OCSP-subca <Connector name="Secure" port="32443" ... connectionTimeout="3000000" pki-server start rhcs10-RSA-OCSP-subca pki-server stop rhcs10-RSA-SubCA ca.defaultOcspUri=http://rhcs10.example.com:32080/ocsp/ee/ocsp pki-server start rhcs10-RSA-SubCA 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 ---------------------------------------- pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:32443/ocsp dscreate create-template /root/pki_rsa/subca-crl-publish-ldap.cfg 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 dscreate from-file /root/pki_rsa/subca-crl-publish-ldap.cfg Starting installation Completed installation for CC-RSA-SubCA-CRL-PUBLISH 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";) ldapmodify -x -h rhds11.example.com -p 5389 -D 'cn=Directory Manager' -W -f /root/pki_rsa/dirsrv/ldapaci.ldif dn: dc=pki,dc=example,dc=com objectClass: domain dc: pki dn: dc=crl,dc=pki,dc=example,dc=com objectClass: domain dc: crl ldapadd -x -H ldap://rhds11.example.com:5389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/subca_pki_subtree.ldif ldapadd -x -H ldap://rhds11.example.com:5389 -D "cn=Directory Manager" -W -f /root/pki_rsa/dirsrv/subca_crl_subtree.ldif pki-server stop rhcs10-RSA-SubCA 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= USDsubj.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= USDsubj.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 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=\USDsubj.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=\USDsubj.cn,dc=crl,dc=pki,dc=example,dc=com 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=\USDsubj.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=\USDsubj.cn,dc=crl,dc=pki,dc=example,dc=com pki-server start rhcs10-RSA-SubCA 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> pki-server stop rhcs10-RSA-SubCA ca.publish.rule.instance.ocsprule- <host/port info> .enable=false ca.publish.rule.instance.ocsprule-rhcs10-example-com-32443.enable=false pki-server start rhcs10-RSA-SubCA 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 - 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 - ldapsearch -x -D "cn=Directory Manager" -h "rhds11.example.com" -p 5389 -b "dc=example,dc=com" -w SECret.123 . . . 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 . . . 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 pki-server stop rhcs10-RSA-SubCA ca.publish.cert.enable=false pki-server start rhcs10-RSA-SubCA pki-server stop rhcs10-RSA-OCSP-subca 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 debug.level=0 pki-server start rhcs10-RSA-OCSP-subca 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 . . . 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 cat /root/.dogtag/pki_rsa_bootstrap/certs_db/user1.req.keyId; echo vi cmcRequest_p10_user1.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/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> 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_user1.cfg ### 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 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 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 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 vi cmc-agent-signed-revoke.cfg ### 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 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 vi HttpClient.revoke.agentSigned.cfg ### 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 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 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 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 pki-server status rhcs10-RSA-SubCA pki -p 31443 -h rhcs10.example.com ca-cert-find --uid user1 pki -d /home/jsmith/certs_db -n rsa_SubCA_AgentV -p 31443 -h rhcs10.example.com ca-cert-hold <user1 serial number> dsctl slapd-CC-RSA-SubCA-LDAP stop 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 vi /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/Server-Cert-subca.csr dsctl slapd-CC-RSA-SubCA-LDAP start 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-subca_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-subca.cfg ### 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 servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECserverCertWithCRLDP 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-subca.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-subca.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ dsctl slapd-CC-RSA-SubCA-LDAP stop cp -r /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-SubCA-LDAP/ certutil -D -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -n "Server-Cert" certutil -D -d /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-SubCA-LDAP/pwdfile.txt -n "Self-Signed-CA" 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 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 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 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 dsctl slapd-CC-RSA-SubCA-LDAP start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :7636 -b "dc=example,dc=com" -w SECret.123 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 pki-server stop rhcs10-RSA-SubCA 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 certutil -D -d /var/lib/pki/rhcs10-RSA-SubCA/alias/ -n "DS temp CA certificate" enableOCSP=true or enableRevocationCheck=true ocspResponderURL ocspResponderCertNickname auths.revocationChecking.enabled=false pki-server start rhcs10-RSA-SubCA 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 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 pki-server stop rhcs10-RSA-SubCA pki-server start rhcs10-RSA-SubCA pki -p 31443 ca-cert-find pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 -n "PKI Bootstrap Administrator for RSA-SubCA" ca-user-find pki-server stop rhcs10-RSA-SubCA <Connector name="Secure" port="31443" ... connectionTimeout="3000000" pki-server start rhcs10-RSA-SubCA 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 certutil -A -d /var/lib/pki/rhcs10-RSA-SubCA/alias -i /root/.dogtag/pki_rsa_bootstrap/IssuanceProtectionSystemCert.pem -n "IssuanceProtectionSystemCert" -t "" pki-server stop rhcs10-RSA-SubCA 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" 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 cat /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caFullCMCSharedTokenCert.cfg | grep enable= enable=true pki-server start rhcs10-RSA-SubCA echo "<YourHSMpassword>" > /root/.dogtag/pki_rsa_bootstrap/certs_db/hsm_pass.txt 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 certutil -L -d /home/jsmith/certs_db -n "rsa_SubCA_AgentV" -a 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 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 vi /home/jsmith/certs_db/cmc_IssuanceProtectionSystemCert_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/home/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 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 vi /home/jsmith/certs_db/HttpClient_IssuanceProtectionSystemCert.cfg ### 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 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 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 pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -p 31443 -n "PKI Bootstrap Administrator for RSA-SubCA" ca-cert-find --name "IssuanceProtectionSystemCert" pki -d /home/jsmith/certs_db -c SECret.123 -n "IssuanceProtectionSystemCert" client-cert-import --cert /home/jsmith/certs_db/IssuanceProtectionSystemCert.crt --trust ",," pki -p 31443 ca-cert-export <issuance protection cert ID> --output-file /root/.dogtag/pki_rsa_bootstrap/IssuanceProtectionSystemCert.pem 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. 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 pki-server stop rhcs10-RSA-SubCA pki-server start rhcs10-RSA-SubCA /usr/sbin/useradd -d /home/FooUser123 -s /bin/bash -c "FooUser123" -m FooUser123 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: 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" 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 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== 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 pki -d /home/FooUser123/certs_db -c SECret.123 client-init 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 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 certutil -d /home/FooUser123/certs_db/ -L 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 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 cat /home/FooUser123/certs_db/pkcs10.self.req.keyId; echo vi /home/FooUser123/certs_db/cmc-p10-self.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/home/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 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 vim /home/FooUser123/certs_db/HttpClient-cmc-p10.self.cfg ### 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 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 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 pki -p 31443 ca-cert-find | grep -i serial pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:31443/ca ls -l /opt/pki_rsa/ca-chain.pem cat /opt/pki_rsa/ca-chain.pem dsctl slapd-CC-RSA-KRA-LDAP stop 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 vi /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/Server-Cert-kra.csr 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-kra_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-kra.cfg ### 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 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-kra.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ cp -r /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-KRA-LDAP/ certutil -D -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -n "Server-Cert" certutil -D -d /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-KRA-LDAP/pwdfile.txt -n "Self-Signed-CA" 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 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 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 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 dsctl slapd-CC-RSA-KRA-LDAP start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :22636 -b "dc=example,dc=com" -w SECret.123 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 cd /root/pki_rsa vi kra_inst.cfg [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 pkispawn -s KRA -f kra_inst.cfg --debug pkispawn -s KRA -f kra_inst.cfg --skip-configuration --debug pkispawn -s KRA -f kra_inst.cfg --skip-installation --debug pki-server status rhcs10-RSA-KRA 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 pki -p 28443 -d /root/.dogtag/pki_rsa_bootstrap/certs_db -n "PKI Bootstrap Administrator for RSA-KRA" kra-key-request-find pki-server stop rhcs10-RSA-KRA pki-server start rhcs10-RSA-KRA pki-server restart rhcs10-RSA-SubCA pki -d /home/FooUser123/certs_db -c SECret.123 client-init 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 ---------------------------- pki -d /home/FooUser123/certs_db -c SECret.123 -p 31443 ca-cert-export 0x555251b --output-file /home/FooUser123/certs_db/kra_transport.txt 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 vi /home/FooUser123/certs_db/cmc-crmf-self.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/home/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 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 vim /home/FooUser123/certs_db/HttpClient-cmc-crmf.self.cfg ### 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 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 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. CMCResponse -d /home/FooUser123/certs_db -i /home/FooUser123/certs_db/cmc.self.Resp -v pk12util -d ~/.mozilla/firefox/'1234gggg.Default User' -n "FooUser123 cert" -i getAsyncPk12 pki-server stop rhcs10-RSA-KRA <Connector name="Secure" port="28443" ... connectionTimeout="3000000" pki-server start rhcs10-RSA-KRA pkiconsole -d <home .redhat-idm-console dir> -n <client cert> https://rhcs10.example.com:28443/kra ls -l /opt/pki_rsa/ca-chain.pem cat /opt/pki_rsa/ca-chain.pem dsctl slapd-CC-RSA-TKS-LDAP stop 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 vi /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/Server-Cert-tks.csr 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tks_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tks.cfg ### 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 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tks.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tks.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ cp -r /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-TKS-LDAP/ certutil -D -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -n "Server-Cert" certutil -D -d /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TKS-LDAP/pwdfile.txt -n "Self-Signed-CA" 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 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 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 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 dsctl slapd-CC-RSA-TKS-LDAP start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :16636 -b "dc=example,dc=com" -w SECret.123 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 cd /root/pki_rsa vi tks_inst.cfg [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 pkispawn -s TKS -f tks_inst.cfg --debug pkispawn -s TKS -f tks_inst.cfg --skip-configuration --debug pkispawn -s TKS -f tks_inst.cfg --skip-installation --debug pki-server status rhcs10-RSA-TKS pki-server stop rhcs10-RSA-TKS pki-server start rhcs10-RSA-TKS ls -l /opt/pki_rsa/ca-chain.pem cat /opt/pki_rsa/ca-chain.pem dsctl slapd-CC-RSA-TPS-LDAP stop 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 vi /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/Server-Cert-tps.csr 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tps.cfg ### 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 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a scp /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps.pem root@rhds11.example.com:/etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ cp -r /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ /etc/dirsrv/save-rsa/slapd-CC-RSA-TPS-LDAP/ certutil -D -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -n "Server-Cert" certutil -D -d /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/ -f /etc/dirsrv/slapd-CC-RSA-TPS-LDAP/pwdfile.txt -n "Self-Signed-CA" 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 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 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 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 dsctl slapd-CC-RSA-TPS-LDAP start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :17636 -b "dc=example,dc=com" -w SECret.123 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 vim /root/pki_rsa/tps-auth-db-ldap.cfg [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 dscreate from-file /root/pki_rsa/tps-auth-db-ldap.cfg Starting installation Completed installation for CC-RSA-TPS-AUTH-DB 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";) ldapmodify -x -h rhds11.example.com -p 9389 -D 'cn=Directory Manager' -W -f /root/pki_rsa/dirsrv/ldapaci.ldif dsctl slapd-CC-RSA-TPS-AUTH-DB stop 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 vi /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/Server-Cert-tps-auth.csr 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/cmc.dirsrv-tps-auth_pkcs10.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. ### 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 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 vim /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_dirsrv-tps-auth.cfg ### 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 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 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. vi /root/.dogtag/pki_rsa_bootstrap/certs_db/Server-Cert-tps-auth.pem certutil -L -d /var/lib/pki/rhcs10-RSA-RootCA/alias/ -n "CA Signing Cert - rhcs10-RSA-RootCA" -a 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/ cp -r /etc/dirsrv/slapd-CC-RSA-TPS-AUTH-DB/ /etc/dirsrv/save-rsa/slapd-CC-RSA-TPS-AUTH-DB/ 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" 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" 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 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 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 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 dsctl slapd-CC-RSA-TPS-AUTH-DB start ldapsearch -x -D "cn=Directory Manager" -H ldaps:// rhds11.example.com :9636 -b "dc=example,dc=com" -w SECret.123 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 cd /root/pki_rsa vi tps_inst.cfg [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 pkispawn -s TPS -f tps_inst.cfg --debug pkispawn -s TPS -f tps_inst.cfg --skip-configuration --debug pkispawn -s TPS -f tps_inst.cfg --skip-installation --debug pki-server status rhcs10-RSA-TPS 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 ---------------------------------------- pki-server stop rhcs10-RSA-TPS op.enroll.userKey.keyGen.keyType.num=1 pki-server start rhcs10-RSA-TPS 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 vi ldap_user1_add.cfg 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: 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";) ldapadd -h rhds11-5.example.com -p 389 -c -D "cn=Directory Manager" -w SECret.123 -f ldapci.ldif 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 dnf install -y redhat-pki-tps echo "<TPS server IP> rhcs10.example.com" >> /etc/hosts vi token_format.txt 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 vi token_enroll.txt 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 tpsclient < token_format.txt tpsclient < token_enroll.txt 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 ---------------------------- 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" ------------------------------------ pki-server stop rhcs10-RSA-TPS op.enroll.userKey.keyGen.keyType.num=2 pki-server start rhcs10-RSA-TPS pki-server stop rhcs10-RSA-TPS pki-server start rhcs10-RSA-TPS op.enroll. <tps profile> .update.applet.requiredVersion.prot.3=1.5.64260792 op.format. <tps profile> .update.applet.requiredVersion.prot.3=1.5.64260792 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 connectionTimeout="300000" connectionTimeout="-1" tks.defKeySet.prot3.devKeyType=AES tks.defKeySet.prot3.divers=gpkmc tks.defKeySet.prot3.diversVer1Keys=none tks.defKeySet.prot3.masterKeyType=AES op.enroll.userKey.keyGen.encryption.keySize=2048 op.enroll.userKey.keyGen.signing.keySize=2048 vi /var/lib/pki/rhcs10-RSA-TPS/tps/conf/phoneHome.xml <Operation> http ://rhcs10.example.com: 25080 /tps/tps</Operation> 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> 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 pki -d /home/jgenie/certs_db -c SECret.123 client-init 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 vi /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AdminV.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/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>_ PKCS10Client: PKCS#10 request key id written into /home/jgenie/certs_db/rsa_SubCA_AdminV.req.keyId 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 vi /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AdminV_signed.cfg ### 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 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 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 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 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 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 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 ---------------------------- 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" pki -d /home/jgenie/certs_db -c SECret.123 pkcs7-import "rsa_SubCA_AdminV" --pkcs7 /home/jgenie/certs_db/rsa_SubCA_AdminV_pkcs7.crt certutil -d /home/jgenie/certs_db -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI . . . Output omitted . . . rsa_SubCA_AdminV u,u,u 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 pki -v -d /home/jgenie/certs_db -c SECret.123 -n "rsa_SubCA_AdminV" -p 31443 ca-user-find pki -d /home/jsmith/certs_db -c SECret.123 client-init 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 vi /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AgentV.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/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>_ 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 vi /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AgentV_signed.cfg ### 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 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 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 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 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 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 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 ---------------------------- 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" pki -d /home/jsmith/certs_db -c SECret.123 pkcs7-import "rsa_SubCA_AgentV" --pkcs7 /home/jsmith/certs_db/rsa_SubCA_AgentV_pkcs7.crt certutil -d /home/jsmith/certs_db -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI . . . Output omitted . . . rsa_SubCA_AgentV u,u,u 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 pki -d /home/aguru/certs_db -c SECret.123 client-init 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 vi /root/.dogtag/pki_rsa_bootstrap/certs_db/cmcRequest_p10_rsa_SubCA_AuditV.cfg ### numRequests: Total number of PKCS10 requests or CRMF requests. numRequests=1 ### input: full path for the PKCS10 request or CRMF request, ### The content must be in Base-64 encoded format. ### Multiple files are supported. They must be separated by a space. input=/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>_ 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 vi /root/.dogtag/pki_rsa_bootstrap/certs_db/HttpClient_cmc_p10_rsa_SubCA_AuditV_signed.cfg ### 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 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 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 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 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 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 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 ---------------------------- 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" pki -d /home/aguru/certs_db -c SECret.123 pkcs7-import "rsa_SubCA_AuditV" --pkcs7 /home/aguru/certs_db/rsa_SubCA_AuditV_pkcs7.crt certutil -d /home/aguru/certs_db -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI . . . Output omitted . . . rsa_SubCA_AuditV u,u,u 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 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 pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-SubCA" pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-OCSP-rootca" pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-OCSP-subca" pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-KRA" pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-TKS" pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db -c SECret.123 client-cert-del "PKI Bootstrap Administrator for RSA-TPS" timedatectl set-time HH:MM:SS timedatectl set-time YYYY-MM-DD timedatectl list-timezones timedatectl set-timezone <your_preferred_timezone> vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCcaCert.cfg policyset.caCertSet.8.default.params.messageDigest=SHA-256 policyset.caCertSet.list=1,2,3,8,4,5,6,9,10 cat /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg | grep cms.tokenList cms.tokenList=NHSM-CONN-XC mv /var/lib/pki/rhcs10-RSA-RootCA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/ pki-server instance-nuxwdog-enable rhcs10-RSA-RootCA --------------------------- Nuxwdog enabled for instance rhcs10-RSA-RootCA. --------------------------- 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: **** * 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 ... cat /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg | grep cms.tokenList cms.tokenList=NHSM-CONN-XC mv /var/lib/pki/rhcs10-RSA-SubCA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/ pki-server instance-nuxwdog-enable rhcs10-RSA-SubCA --------------------------- Nuxwdog enabled for instance rhcs10-RSA-SubCA. --------------------------- 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: ****** 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 ... cat /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/conf/CS.cfg | grep cms.tokenList cms.tokenList=NHSM-CONN-XC mv /var/lib/pki/rhcs10-RSA-OCSP-rootca/conf/password.conf ~/<YOUR_PREFERRED_DIR>/ pki-server instance-nuxwdog-enable rhcs10-RSA-OCSP-rootca/ --------------------------- Nuxwdog enabled for instance rhcs10-RSA-OCSP-rootca/. --------------------------- 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: **** * 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 ... 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 ... cat /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg | grep cms.tokenList cms.tokenList=NHSM-CONN-XC mv /var/lib/pki/rhcs10-RSA-KRA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/ pki-server instance-nuxwdog-enable rhcs10-RSA-KRA --------------------------- Nuxwdog enabled for instance rhcs10-RSA-KRA. --------------------------- 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: **** * 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 ... cat /var/lib/pki/rhcs10-RSA-TKS/TKS/conf/CS.cfg | grep cms.tokenList cms.tokenList=NHSM-CONN-XC mv /var/lib/pki/rhcs10-RSA-TKS/conf/password.conf ~/<YOUR_PREFERRED_DIR>/ pki-server instance-nuxwdog-enable rhcs10-RSA-TKS --------------------------- Nuxwdog enabled for instance rhcs10-RSA-TKS. --------------------------- 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: **** * 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 ... cat /var/lib/pki/rhcs10-RSA-TPS/TPS/conf/CS.cfg | grep cms.tokenList cms.tokenList=NHSM-CONN-XC mv /var/lib/pki/rhcs10-RSA-TPS/conf/password.conf ~/<YOUR_PREFERRED_DIR>/ pki-server instance-nuxwdog-enable rhcs10-RSA-TPS --------------------------- Nuxwdog enabled for instance rhcs10-RSA-TPS. --------------------------- 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: **** * 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 ... pki-server stop rhcs10- <INSTANCE> systemctl stop pki-tomcatd-nuxwdog@rhcs10- <INSTANCE> .service cd /var/lib/pki/rhcs10-RSA-RootCA/ca/conf authType=sslclientauth pki-server ca-config-set -i rhcs10-RSA-RootCA authType sslclientauth pki-server start rhcs10- <INSTANCE> systemctl start pki-tomcatd-nuxwdog@rhcs10- <INSTANCE> .service pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-init 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 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" ------------------------------------- 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" ------------------------------------- pki -U https://rhcs10.example.com:31443 -d /home/jgenie/.redhat-idm-console -c SECret.123 -n rsa_SubCA_AdminV ca-user-find ssh -X jgenie@rhcs10.example.com pkiconsole -d /home/jgenie/.redhat-idm-console -n rsa_SubCA_AdminV https://rhcs10.example.com:31443/ca dnf install xauth ssh -X jgenie@rhcs10.example.com pkiconsole -d /home/jgenie/.redhat-idm-console -n rsa_SubCA_AdminV https://rhcs10.example.com:31443/ca pki-server stop rhcs10-RSA-KRA systemctl stop pki-tomcatd-nuxwdog@rhcs10-KRA.service vi /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg log.instance.SignedAudit.logSigning=true pki-server start rhcs10-RSA-KRA systemctl start pki-tomcatd-nuxwdog@rhcs10-KRA.service 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 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 ---------------------------- 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 pki -p 31443 -h `hostname` ca-cert-find --name "CA Audit Signing Certificate" --------------- 1 entries found --------------- Serial Number: 0xe8e47bf . . . Output omitted . . . 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" --------------------------------------------------- cat > /home/aguru/certs_db/audit.txt << EOF ca_audit EOF cd /home/aguru/certs_db/ AuditVerify -d /home/aguru/certs_db -n "SubCA Audit Signing Certificate" -a audit.txt dnf install audit 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 -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 service auditd restart -w /etc/pki/ <instance name> /alias -p warx -k rhcs_audit_nssdb -w /etc/pki/ <instance name> /alias/ <file> -p warx -k rhcs_audit_nssdb -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 service auditd restart -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 service auditd restart -w /etc/pki/ instance_name /server.xml -p wax -k rhcs_audit_config -w /etc/pki/ instance name /subsystem/CS.cfg -p wax -k rhcs_audit_config -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 auditctl -l cd /etc/pki/rhcs10-RSA-SubCA/alias/ ausearch -k rhcs_audit_nssdb ocsp.store.ldapStore.validateConnCertWithCRL=true auths.revocationChecking.enabled=true enableOCSP="false" pki-server stop rhcs10-RSA-KRA systemctl stop pki-tomcatd-nuxwdog@rhcs10-KRA.service <Connector name="Secure" enableRevocationCheck="true" ocspCacheSize="1000" ocspMinCacheEntryDuration="60" ocspMaxCacheEntryDuration="120" ocspTimeout="10" /> pki-server start rhcs10-RSA-KRA systemctl start pki-tomcatd-nuxwdog@rhcs10-KRA.service <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"> 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 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 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 pki-server restart rhcs10-RSA-RootCA pki-server restart rhcs10-RSA-SubCA pki-server restart rhcs10-RSA-OCSP-rootca pki-server restart rhcs10-RSA-OCSP-subca pki-server restart rhcs10-RSA-KRA systemctl restart rhcs10-RSA-RootCA systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service 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" dsctl slapd-CC-RSA-SubCA-LDAP stop dsctl slapd-CC-RSA-SubCA-LDAP start 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 certificateVerification=required clientmode=true nickname= <client cert that was issued and imported> pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 ca-cert-find pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 -n 'SubCA_AdminV' ca-cert-find certmap rhcs <certificate issuer DN> rhcs:CmapLdapAttr seeAlso rhcs:verifyCert on certmap rhcs CN=CA Signing Certificate,OU=pki-tomcat-ca,O=pki-tomcat-ca-SD rhcs:CmapLdapAttr seeAlso rhcs:verifyCert on dsctl slapd-CC-RSA-SubCA-LDAP restart pki-server stop rhcs10- <INSTANCE> systemctl stop pki-tomcatd-nuxwdog@rhcs10- <INSTANCE> .service internaldb.ldapauth.bindDN internaldb.ldapauth.bindPWPrompt 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 pki-server start rhcs10- <INSTANCE> systemctl start pki-tomcatd-nuxwdog@rhcs10- <INSTANCE> .service update-crypto-policies --set FIPS pki-server stop rhcs10- <INSTANCE> systemctl stop pki-tomcatd-nuxwdog@rhcs10- <INSTANCE> .service update-crypto-policies --show cp /usr/share/crypto-policies/policies/FIPS.pol /etc/crypto-policies/policies/CC-FIPS.pol vi /etc/crypto-policies/policies/CC-FIPS.pol group = SECP256R1 SECP384R1 SECP521R1 \ FFDHE-2048 FFDHE-3072 FFDHE-4096 FFDHE-6144 FFDHE-8192 group = SECP256R1 SECP384R1 SECP521R1 key_exchange = ECDHE DHE DHE-RSA PSK DHE-PSK ECDHE-PSK key_exchange = ECDHE DHE PSK DHE-PSK ECDHE-PSK min_dh_size = 2048 min_dh_size = 176384 update-crypto-policies --set CC-FIPS vi /etc/crypto-policies/back-ends/nss.config tls-version-max=tls1.2:dtls-version-max=dtls1.2 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" pki-server start rhcs10-RSA-RootCA pki-server restart rhcs10-RSA-SubCA systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service mv /etc/pki/instance_name/banner.txt /etc/pki/instance_name/banner.txt.UNUSED pki-server banner-validate -i instance_name --------------- Banner is valid --------------- pki-server banner-show -i instance_name cat /usr/share/pki/CS_SERVER_VERSION Red Hat Certificate System 10.4.3