Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

7.3. Installing Using the pkispawn Utility

Read the following section carefully to ensure that you make the right choices when following the installation examples in this section.

7.3.1. About the pkispawn Utility
Copiar enlace

In Red Hat Certificate System, administrators set up the individual public key infrastructure (PKI) subsystems by running the pkispawn utility.
The pkispawn utility requires a configuration file. This file contains parameters that are grouped into sections. These sections are stacked, so that parameters defined in earlier sections can be overridden by parameters defined in later sections. The sections are read in the following order:
  1. [DEFAULT]
  2. [Tomcat]
  3. The subsystem-specific sections: [CA], [KRA], [OCSP], [TKS], or [TPS]
During the setup, pkispawn:
  1. First reads the default values from the /etc/pki/default.cfg file.

    Important

    Do not edit the /etc/pki/default.cfg file. You will be instructed to create a configuration file that overrides the defaults when passed to the pkispawn utility. Parameters not set in the configuration file use the defaults. For details about using a configuration file, see Section 7.3.2, “Two-step Installation Using pkispawn”.
  2. Reads the administrator-provided configuration file mentioned above to override the default values.
  3. Performs the installation of the requested PKI subsystem.
  4. Passes the settings to a Java servlet that performs the configuration based on the settings.
For general information about pkispawn and examples, see the pkispawn(8) and pki_default.cfg(5) man pages.
For instructions about how to install a CA, KRA, or OCSP subsystem, see Section 7.3.2, “Two-step Installation Using pkispawn”.
For instructions about how to install a TKS or TPS subsystem, see Section 7.3.3, “Single-step Installation Using pkispawn (TMS-only)”.

7.3.2. Two-step Installation Using pkispawn
Copiar enlace

To install a CA, KRA, or OCSP subsystem, use the pkispawn two-step installation to enable the administrator to manually update configuration files between the two parts of the installation.
The name two-step installation comes from the fact that the pkispawn utility is often run twice with a slightly different set of parameters in its overwrite configuration file to complete the installation.
The two-step installation is consisted of the following major parts:
  1. Installation using the pkispawn Utility (Step 1)
    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.
    This part of the installation contains the following substeps:
    1. Section 7.3.2.1, “Creating the Configuration File for the First Step of the Installation”
    2. Section 7.3.2.2, “Starting the pkispawn Step One Installation”
  2. Between-step configuration and customization
    For details, see Section 7.3.2.3, “Configuration Between the Two pkispawn Installation Steps”.
  3. Configuration Using the pkispawn Utility (Step 2)
    During this step, pkispawn is run to continue the installation based on the configuration files in the instance-specific /etc/pki/instance_name/ directory.
    For details about this part of the installation see Section 7.3.2.4, “Starting the pkispawn Step Two Installation”.
Depending on your environment, additional configuration and customization steps are required.
Create a text file for the pkispawn configuration settings, such as /root/pki/config.subsystem.txt, and fill it with the settings described below. Every setting must be added.

Important

This section describes a 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.

Subsystem-independent Settings

Independently of the subsystem you install, the following settings are required in the configuration file in the:
  • [DEFAULT] section:
    1. Set a unique instance name: 
      pki_instance_name=instance_name
      Copy to Clipboard Toggle word wrap
    2. Set the host name and security domain name: 
      pki_host=server.example.com
pki_security_domain_name=example.com Security Domain
pki_security_domain_user=caadmin
pki_security_domain_password=SD password
      Copy to Clipboard Toggle word wrap

      Note

      Certificate System creates unique certificate nicknames based on these parameters and the instance name. The uniqueness of certificate nicknames is very important in keeping the HSM token shared by multiple PKI instances functional.
    3. Set the port numbers for the HTTP and HTTPS protocols: 
      pki_https_port=port_number
pki_http_port=port_number
      Copy to Clipboard Toggle word wrap

      Important

      To run more than one Certificate System instance on the same host, you must set ports in the pki_https_port and pki_http_port parameters that are not used by any other service on the host. By default, Certificate System uses port 8080 for HTTP and 8443 for HTTPS.
    4. Set the HSM-specific parameters: 
      pki_hsm_enable=True
pki_hsm_libfile=HSM_PKCS11_library_path
pki_hsm_modulename=HSM_module_name
pki_token_name=HSM_token_name
pki_token_password=HSM_token_password


pki_audit_signing_token=HSM_token_name
pki_subsystem_token=HSM_token_name
pki_sslserver_token=HSM_token_name
      Copy to Clipboard Toggle word wrap
      For further details, see Section 6.4.4, “Preparing for Installing Certificate System with an HSM”.
    5. If building an RSA Certificate System instance, use the following configuration: 
      pki_admin_key_algorithm=SHA256withRSA
pki_admin_key_size=4096
pki_admin_key_type=rsa
pki_sslserver_key_algorithm=SHA256withRSA
pki_sslserver_key_size=4096
pki_sslserver_key_type=rsa
pki_subsystem_key_algorithm=SHA256withRSA
pki_subsystem_key_size=4096
pki_subsystem_key_type=rsa
pki_audit_signing_key_algorithm=SHA256withRSA
pki_audit_signing_key_size=4096
pki_audit_signing_key_type=rsa
pki_audit_signing_signing_algorithm=SHA256withRSA
      Copy to Clipboard Toggle word wrap
      Allowed choices for the key_algorithm parameters are:
      • SHA256withRSA
      • SHA384withRSA
      • SHA512withRSA

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (RSA) must match key_type (rsa).
      Allowed choices for key_type is only rsa.
      Allowed choices for key_size are 2048 and 4096.
    6. To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: 
      pki_admin_key_algorithm=SHA256withEC
pki_admin_key_size=nistp256
pki_admin_key_type=ecc
pki_sslserver_key_algorithm=SHA256withEC
pki_sslserver_key_size=nistp256
pki_sslserver_key_type=ecc
pki_subsystem_key_algorithm=SHA256withEC
pki_subsystem_key_size=nistp256
pki_subsystem_key_type=ecc
pki_audit_signing_key_algorithm=SHA256withEC
pki_audit_signing_key_size=nistp256
pki_audit_signing_key_type=ecc
pki_audit_signing_signing_algorithm=SHA256withEC
      Copy to Clipboard Toggle word wrap
      Allowed choices for the key_algorithm parameters are:
      • SHA256withEC
      • SHA384withEC
      • SHA512withEC

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (EC) must match key_type (ecc).
      Allowed choices for key_size are:
      • nistp256
      • nistp384
      • nistp521
      Allowed choice for key_type is ecc
    7. Set the client directory of the bootstrap admin user: 
      pki_client_dir=bootstrap_admin_directory
      Copy to Clipboard Toggle word wrap
      By default, the path is set to ~/.dogtag/instance_name/

      Important

      The pki_admin_* and pki_client_* parameters belong to the bootstrap user that is automatically created by the installation process. For further information about default roles (privileges) and the bootstrap user, see Section 2.6.6, “Users, Authorization, and Access Controls”.
      For descriptions about the parameters covered in this section, see the pki_default.cfg(5) man page.
    8. Set various passwords for the bootstrap admin user: 
      pki_admin_password=password
pki_client_database_password=password
pki_client_pkcs12_password=password
      Copy to Clipboard Toggle word wrap
    9. Set the parameters for the LDAPS connection to Directory Server running on the same host: 
      pki_ds_database=back-end database name
pki_ds_hostname=hostname
pki_ds_secure_connection=True
pki_ds_secure_connection_ca_pem_file=path_to_CA_or_self-signed_certificate
pki_ds_password=password
      Copy to Clipboard Toggle word wrap
    10. If you use a self-signed certificate in Directory Server use the following command to export it from the Directory Server's Network Security Services (NSS) database: 
      # certutil -L -d /etc/dirsrv/slapd-instance_name/ \
     -n "server-cert" -a -o /root/ds.crt
      Copy to Clipboard Toggle word wrap
  • [Tomcat] section:
    1. Set the Tomcat JServ Protocol (AJP) port: 
      pki_ajp_port=Tomcat_AJP_port
      Copy to Clipboard Toggle word wrap
    2. Set the Tomcat server port: 
      pki_tomcat_server_port=Tomcat_server_port
      Copy to Clipboard Toggle word wrap

    Important

    To run more than one PKI subsystem instance on the same host, you must set ports in the pki_ajp_port and pki_tomcat_server_port parameters that are not used by any other service on the host. By default, the pki_ajp_port is set to 8009 and pki_tomcat_server_port to 8005.
For non-TMS, after you created the initial configuration file, add the subsystem-specific settings to it. See:
For TMS, to continue creating the configuration file for the pkispawn single-step Installation, see Section 7.3.3.1, “Creating the Configuration File for pkispawn single-step Installation”.

CA Settings

In addition to the section called “Subsystem-independent Settings”, you need the following settings in the [CA] section to install a CA:
  1. Enable random serial numbers by adding following setting: 
    pki_random_serial_numbers_enable=true
    Copy to Clipboard Toggle word wrap
  2. Set the following parameters to specify the data of the bootstrap admin user, which will be automatically created during the installation: 
    pki_admin_nickname=bootstrap_CA_admin
pki_admin_name=bootstrap_CA_administrator_name
pki_admin_uid=caadmin
pki_admin_email=caadmin@example.com
    Copy to Clipboard Toggle word wrap
    Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create actual administrator, agent, and auditor accounts.
  3. Specify the HSM token for the subsystem-dependent certificates: 
    pki_ca_signing_token=HSM_token_name
pki_ocsp_signing_token=HSM_token_name
    Copy to Clipboard Toggle word wrap
  4. If building an RSA-based CA, use the following configuration: 
    pki_ca_signing_key_algorithm=SHA256withRSA
pki_ca_signing_key_size=4096
pki_ca_signing_key_type=rsa
pki_ca_signing_signing_algorithm=SHA256withRSA
pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=4096
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA
    Copy to Clipboard Toggle word wrap
    Allowed choices for the key_algorithm parameters are:
    • SHA256withRSA
    • SHA384withRSA
    • SHA384withRSA

    Note

    You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
    Signature algorithm (RSA) must match key_type (rsa).
    Allowed choices for key_size parameters are:
    • 2048
    • 4096
    Allowed choices for key_type parameters are only rsa.
  5. By default, the key type for system certificates is rsa and the key length is 2048 bit. To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: 
    pki_ocsp_signing_key_algorithm=SHA256withEC
pki_ocsp_signing_key_size=nisp256
pki_ocsp_signing_key_type=ecc
pki_ocsp_signing_signing_algorithm=SHA256withEC
    Copy to Clipboard Toggle word wrap
    Allowed choices for key_algorithm parameters are:
    • SHA256withEC
    • SHA384withEC
    • SHA512withEC

    Note

    You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
    Signature algorithm (EC) must match key_type (ecc).
    Allowed choices for key_size parameters are:
    • nistp256
    • nistp384
    • nistp521
    Allowed choices for key_type parameters is ecc.

Settings for Other Subsystems

In addition to the section called “Subsystem-independent Settings”, you need the following settings in the [CA], [KRA], or [OCSP] section to install a subordinate CA, KRA, or OCSP:
  1. Subsystems that are not a root CA use the two-step installation mechanism that is sometimes referred to as External CA. For the first step, add the following parameters under each respective subsystem-specific section: 
    pki_external=True
pki_external_step_two=False
    Copy to Clipboard Toggle word wrap
  2. This step depends on the subsystem you are installing:
    Subordinate CA
    Add the following settings to the [CA] section:
    1. Add all settings from the [CA] section of the root CA.
    2. Set the output paths for the system certificate signing requests (CSR): 
      pki_ca_signing_csr_path=path
pki_ocsp_signing_csr_path=path
pki_audit_signing_csr_path=path
pki_sslserver_csr_path=path
pki_subsystem_csr_path=path
pki_admin_csr_path=path
      Copy to Clipboard Toggle word wrap
    OCSP
    Set the following in the [OCSP] section:
    1. Specify the following parameters to set the data of the bootstrap OCSP admin user which is automatically created during the installation: 
      pki_admin_nickname=bootstrap_OCSP_admin
pki_admin_name=bootstrap_OCSP_administrator_name
pki_admin_uid=ocspadmin
pki_admin_email=ocspadmin@example.com
      Copy to Clipboard Toggle word wrap
      Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create actual administrator, agent, and auditor accounts.
    2. Specify the HSM token for the subsystem-dependent certificates: 
      pki_ocsp_signing_token=HSM_token_name
      Copy to Clipboard Toggle word wrap
    3. If building an RSA Certificate System instance, use the following configuration: 
      pki_ocsp_signing_key_algorithm=SHA256withRSA
pki_ocsp_signing_key_size=4096
pki_ocsp_signing_key_type=rsa
pki_ocsp_signing_signing_algorithm=SHA256withRSA
      Copy to Clipboard Toggle word wrap
      Allowed choices for the key_algorithm parameters are:
      • SHA256withRSA
      • SHA384withRSA
      • SHA384withRSA

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (RSA) must match key_type (rsa).
      Allowed choices for key_size parameters are:
      • 2048
      • 4096
      Allowed choices for key_type parameters are only rsa.

      Note

      It is suggested to match your CA instance type (RSA or ECC) with your OCSP responder type (RSA or ECC).
    4. To use Elliptic Curve Cryptography (ECC) instead of RSA when creating certificates, set: 
      pki_ocsp_signing_key_algorithm=SHA256withEC
pki_ocsp_signing_key_size=nisp256
pki_ocsp_signing_key_type=ecc
pki_ocsp_signing_signing_algorithm=SHA256withEC
      Copy to Clipboard Toggle word wrap
      Allowed choices for the key_algorithm parameters are:
      • SHA256withEC
      • SHA384withEC
      • SHA512withEC

      Note

      You can set this parameter to each value specified in the ca.profiles.defaultSigningAlgsAllowed parameter in the CA's CS.cfg file. For details, see the Signing Algorithm Constraint section in the Red Hat Certificate System Administration Guide (Common Criteria Edition).
      Signature algorithm (EC) must match key_type (ecc).
      Allowed choices for key_size parameters are:
      • nistp256
      • nistp384
      • nistp521
      Allowed choices for key_type parameters are only ecc.

      Note

      It is suggested to match your CA instance type (RSA or ECC) with your OCSP responder type (RSA or ECC).
    5. Set the output paths for the system certificate signing requests (CSR): 
      pki_ocsp_signing_csr_path=path
pki_audit_signing_csr_path=path
pki_sslserver_csr_path=path
pki_subsystem_csr_path=path
pki_admin_csr_path=path
      Copy to Clipboard Toggle word wrap
    KRA
    Set the following in the [KRA] section:
    1. Specify the following parameters to set the data of the bootstrap KRA admin user which is automatically created during the installation: 
      pki_admin_nickname=bootstrap_KRA_admin
pki_admin_name=bootstrap_KRA_administrator_name
pki_admin_uid=kraadmin
pki_admin_email=kraadmin@example.com
      Copy to Clipboard Toggle word wrap
      Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create actual administrator, agent, and auditor accounts.
    2. Specify the HSM token for the subsystem-dependent certificates: 
      pki_transport_token=HSM_token_name
pki_storage_token=HSM_token_name
      Copy to Clipboard Toggle word wrap
    3. RSA is the only key type supported for both the KRA storage and transport certificates. By default, the key length is 2048 bit. To choose a 4096 bit key instead, add the following parameters: 
      pki_transport_key_size=4096
pki_storage_key_size=4096
      Copy to Clipboard Toggle word wrap
    4. Set the output paths for the system certificate signing requests (CSR): 
      pki_kra_signing_csr_path=path
pki_audit_signing_csr_path=path
pki_sslserver_csr_path=path
pki_subsystem_csr_path=path
pki_admin_csr_path=path
      Copy to Clipboard Toggle word wrap

7.3.2.2. Starting the pkispawn Step One Installation
Copiar enlace

After you prepared the configuration file as described in Section 7.3.2.1, “Creating the Configuration File for the First Step of the Installation”, start the first step of the installation:
  • For a root CA: 
    # pkispawn -f /root/pki/config.root-CA.txt -s CA
    Copy to Clipboard Toggle word wrap
  • For a subordinate CA or other non-CA subsystems: 
    # pkispawn -f /root/pki/config.subsystem.txt -s subsystem
    Copy to Clipboard Toggle word wrap
    Replace subsystem with one of the following subsystems: CA, KRA, or OCSP. For example, for a KRA installation: 
    # pkispawn -f /root/pki/config.KRA.txt -s KRA
    Copy to Clipboard Toggle word wrap

7.3.2.3. Configuration Between the Two pkispawn Installation Steps
Copiar enlace

After the installation step described in Section 7.3.2.2, “Starting the pkispawn Step One Installation” has finished successfully, you can manually update the instance-specific configuration files before Section 7.3.2.4, “Starting the pkispawn Step Two Installation” is performed, where the actual configuration begins.
For required procedures, perform the actions described in this section after you have completed step 1 of the pkispawn procedure.
For optional procedures, see Part III, “Configuring Certificate System”. Useful between-installation-step procedures include:
7.3.2.3.1. Enabling Signed Audit Logging
Copiar enlace
The signed audit logging feature enables the prevention of unauthorized log manipulation.
For details, see Section 13.3.1, “Enabling and Configuring Signed Audit Log”.
7.3.2.3.2. Setting the KRA into Encryption Mode
Copiar enlace
If you are using a Hardware Security Module (HSM) that does not support secure key extraction, it is necessary to set the Key Recovery Authority (KRA) into encryption mode. For details, see Section 12.2.2.2, “Solving Limitations of HSMs When Using AES Encryption in KRAs”.
7.3.2.3.3. Enabling OCSP
Copiar enlace
For details about enabling the Online Certificate Status Protocol (OCSP) see Section 9.4.1.2, “Enabling Certificate Revocation Checking for Subsystems”.

7.3.2.4. Starting the pkispawn Step Two Installation
Copiar enlace

After you have completed Section 7.3.2.3, “Configuration Between the Two pkispawn Installation Steps”, start the second step of the pkispawn installation:
  • Root CA: 
    # pkispawn -f /root/pki/config.root-CA.txt -s CA --skip-installation
    Copy to Clipboard Toggle word wrap
    If the configuration step succeeds, the pkispawn utility displays an installation summary. For example: 
    ================================================================
                       INSTALLATION SUMMARY
================================================================

  Administrator's username:             caadmin
  Administrator's PKCS #12 file:
        /root/.dogtag/instance_name/ca_admin_cert.p12

  To check the status of the subsystem:
        systemctl status pki-tomcatd@instance_name.service

  To restart the subsystem:
        systemctl restart pki-tomcatd@instance_name.service

  The URL for the subsystem is:
        https://server.example.com:8443/ca/

  PKI instances will be enabled upon system boot

================================================================
    Copy to Clipboard Toggle word wrap
  • Subordinate CA or other non-CA subsystems:
    1. Submit the CSRs to a CA to issue the certificates.
      One major difference between installing non-root CA subsystems and a root CA is that prior to running step two of the pkispawn utility, other subsystems require submitting the system certificate signing requests (CSR) to a CA:
      In the first step of the section called “Settings for Other Subsystems”, you added the *_csr_path parameters in the pkispawn configuration file for the subsystems to be installed. If the first step of pkispawn succeeded, Certificate System generated and stored the CSRs in the specified paths. These certificate requests are in PKCS#10 format and you must convert them to Certificate Management over CMS (CMC) format before submitting them to the CA. Follow instructions specified at 4.2. Creating Certificate Signing Requests in Red Hat Certificate System Administration Guide. You need the resulting system certificates when you execute the second step of the pkispawn command.
      Additionally, you need the issuing CA's certificate chain in PKCS#7 format. To retrieve it:
      1. Access the issuing CA's EE URL.
      2. Navigate to Retrieval Import CA Certificate Chain and click Display the CA certificate chain in PKCS#7 for importing into a server.
      3. Click Submit.
      4. Copy the displayed PKCS#7-formatted output into a text file, such as /root/pki/cert_chain.p7b, on the Certificate System host.
    2. Create a configuration file for the second step of the pkispawn command:
      1. Copy the pkispawn configuration file from the first step and edit the newly created file for step two of the pkispawn command:
        1. In the [DEFAULT] section, set the path to the issuing CA's certificate chain file you prepared in the previous step and the CA signing certificate's nickname. For example: 
          [DEFAULT]
pki_ca_signing_nickname=CA Signing Certificate
pki_ca_signing_cert_path=/root/pki/cert_chain.p7b
          Copy to Clipboard Toggle word wrap
        2. Add the following settings to the subsystem-specific section ([CA], [KRA], or [OCSP]) depending on the subsystem you install:
          Subordinate CA
          pki_ca_signing_crt_path=/root/pki/subsystem/ocsp_signing.crt
pki_subsystem_crt_path=/root/pki/subsystem/subsystem.crt
pki_sslserver_crt_path=/root/pki/subsystem/sslserver.crt
pki_audit_signing_crt_path=/root/pki/subsystem/ca_audit_signing.crt
pki_admin_crt_path=/root/pki/subsystem/ca_admin.crt
pki_external_step_two=True
          Copy to Clipboard Toggle word wrap
          OCSP
          pki_ocsp_signing_crt_path=/root/pki/subsystem/ocsp_signing.crt
pki_subsystem_crt_path=/root/pki/subsystem/subsystem.crt
pki_sslserver_crt_path=/root/pki/subsystem/sslserver.crt
pki_audit_signing_crt_path=/root/pki/subsystem/ocsp_audit_signing.crt
pki_admin_crt_path=/root/pki/subsystem/ocsp_admin.crt
pki_external_step_two=True
          Copy to Clipboard Toggle word wrap
          KRA
          pki_storage_crt_path=/root/pki/subsystem/kra_storage.crt
pki_transport_crt_path=/root/pki/subsystem/kra_transport.crt
pki_subsystem_crt_path=/root/pki/subsystem/subsystem.crt
pki_sslserver_crt_path=/root/pki/subsystem/sslserver.crt
pki_audit_signing_crt_path=/root/pki/subsystem/kra_audit_signing.crt
pki_admin_crt_path=/root/pki/subsystem/kra_admin.crt
pki_external_step_two=True
          Copy to Clipboard Toggle word wrap
    3. Run the pkispawn command: 
      # pkispawn -f /root/pki/config.subsystem.txt -s subsystem
      Copy to Clipboard Toggle word wrap
      Replace subsystem with one of the following subsystems: CA, KRA, or OCSP. For example, for a KRA installation: 
      # pkispawn -f /root/pki/config.KRA.txt -s KRA
      Copy to Clipboard Toggle word wrap

7.3.3. Single-step Installation Using pkispawn (TMS-only)
Copiar enlace

TPS and TKS subsystems can be installed by using the pkispawn single-step installation process.
pkispawn requires a configuration file.
Follow the section called “Subsystem-independent Settings” to fill in the subsystem-independent part of the pkispawn configuration file.
In addition, under the [DEFAULT] section add the following: 
pki_security_domain_hostname=example.redhat.com
pki_security_domain_https_port=8443
pki_security_domain_user=caadmin
pki_security_domain_password=[SD password]
Copy to Clipboard Toggle word wrap
Then add the subsystem-specific section ([TKS] or [TPS]) as following:
TKS
Set the following in the [TKS] section:
  • Specify the following parameters to set the data of the bootstrap TKS admin user which is automatically created during the installation: 
    pki_admin_nickname=bootstrap_TKS_admin
pki_admin_name=bootstrap_TKS_administrator_name
pki_admin_uid=tksadmin
pki_admin_email=tksadmin@example.com
    Copy to Clipboard Toggle word wrap
    Red Hat Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create the administrator, and auditor accounts.
TPS
Set the following in the [TPS] section:
  1. Specify the following parameters to set the data of the bootstrap TPS admin user, which is automatically created during the installation: 
    pki_admin_nickname=bootstrap_TPS_admin
pki_admin_name=bootstrap_TPS_administrator_name
pki_admin_uid=tpsadmin
pki_admin_email=tpsadmin@example.com
    Copy to Clipboard Toggle word wrap
    Red Hat Certificate System assigns administrator and agent privileges to this bootstrap account. Use this account after the installation to create the administrator, and the auditor accounts.
  2. Set the LDAP base DN of the TPS authentication database: 
    pki_authdb_basedn=base_DN_of_the_TPS_authentication_database
    Copy to Clipboard Toggle word wrap
  3. Enable the server-side key generation and archival: 
    pki_enable_server_side_keygen=True
    Copy to Clipboard Toggle word wrap

7.3.3.2. Running pkispawn for single-step Installation
Copiar enlace

Run the pkispawn command:
# pkispawn -f /root/pki/config.TKS.txt -s TKS
or
# pkispawn -f /root/pki/config.TPS.txt -s TPS

7.3.3.3. Post-Installation for Single-Step Installation
Copiar enlace

Follow the procedures below:
Once you completed the procedures above, follow Section 7.4, “Post-installation Tasks” for additional post-installation actions.
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat