pki_d...lt.cfg(5)

📦
version 11.2.0 · 4 versions
, in centos-stream 9, ubuntu jammy

🌸 NAME 🌸

pki_default.cfg — the PKI server default deployment configuration file, aka pki_default.cfg(5) if you're being formal, which we are not 💅

📍 LOCATION 📍

/usr/share/pki/server/etc/default.cfg

Like, that's where it lives. Do not move it. Do not touch it. We'll get to why 😭

✨ DESCRIPTION ✨

Okay so bestie, listen 🫶 this file holds all the default settings for a Certificate Server instance that gets created using pkispawn.

And here's the thing — do not edit this file. Fr fr, hands off 🙈 It can literally get modified when the Certificate Server packages are updated, so anything you scribble in there is gonna get steamrolled.

Instead ✨ when you're setting up a Certificate Server instance, you hand pkispawn a configuration file containing overrides to the defaults in /usr/share/pki/server/etc/default.cfg. That's the move. See pkispawn(8) for the details, iykyk.

🎀 SECTIONS 🎀

default.cfg contains parameters grouped into sections. And these sections are stacked — so parameters defined in earlier sections can be overwritten by parameters defined in later sections. It's giving layered cake 🎂

The sections are read in exactly this order:

  1. [DEFAULT]
  2. [Tomcat]
  3. the subsystem section ([CA], [KRA], [OCSP], [TKS], or [TPS])

Which is iconic, because it lets you specify parameters shared by all subsystems in [DEFAULT] or [Tomcat], and then do subsystem-specific customization on top. Chef's kiss 👑

There are a small number of bootstrap parameters which are passed in the configuration file by pkispawn. Other parameters' values can be interpolated tokens rather than explicit values. For example:

pki_ca_signing_nickname=caSigningCert cert-%(pki_instance_name)s CA

That substitutes the value of pki_instance_name into the parameter value. Slay.

It is possible to interpolate any non-password parameter within a section or in [DEFAULT]. But — and this is the important part — any parameter used in interpolation can ONLY be overridden within the same section. So, for example, pki_instance_name should only be overridden in [DEFAULT]; otherwise, interpolations can fail 💀

Note: Any non-password related parameter values in the configuration file that need to contain a % character must be properly escaped. For example, a value of foo%bar would be specified as foo%%bar in the configuration file. Double it up or it's over 🫠

🔍 PRE-CHECK PARAMETERS 🔍

Once the configuration parameters have been constructed from the above sections and overrides, pkispawn is gonna run a series of basic tests to determine if the parameters being passed in are valid and consistent — before starting any installation. Responsible queen behavior honestly 💅

In pre-check mode, these tests are executed and then pkispawn exits. No install, just vibes and validation.

It is possible to disable specific tests by setting the directives below. While all these tests should pass to ensure a successful installation, it may be reasonable to skip tests in pre-check mode. (Like, do it if you must, but know what you're doing 🙈)

  • pki_skip_ds_verify — Skip verification of the Directory Server credentials. In this test, pkispawn attempts to bind to the directory server instance for the internal database using the provided credentials. This could be skipped if the directory server instance does not yet exist or is inaccessible. Defaults to False.
  • pki_skip_sd_verify — Skip verification of the security domain user/password. In this test, pkispawn attempts to log onto the security domain using the provided credentials. This can be skipped if the security domain is unavailable. Defaults to False.

🦋 GENERAL INSTANCE PARAMETERS 🦋

The parameters described below, as well as the parameters located in the following sections, can be customized as part of a deployment. Heads up: this list is not exhaustive. There's more lurking, but this is the main character lineup ⭐

  • pki_instance_name — Name of the instance. The instance is located at /var/lib/pki/instance_name. For Java subsystems, the default is specified as pki-tomcat.
  • pki_https_port, pki_http_port — Secure and unsecure ports. Defaults to standard Tomcat ports 8443 and 8080, respectively.
  • pki_ajp_port, pki_tomcat_server_port — Ports for Tomcat subsystems. Defaults to standard Tomcat ports of 8009 and 8005, respectively.
  • pki_ajp_host — Host on which to listen for AJP requests. Defaults to localhost4 to listen to local traffic only on IPv4 stack.
NOTE: Deprecated in favor of pki_ajp_host_ipv4. She's retired, respect her legacy 🫡
  • pki_ajp_host_ipv4 — Host on which to listen for AJP requests. Defaults to localhost4 to listen to local traffic only on IPv4 stack.
  • pki_ajp_host_ipv6 — Host on which to listen for AJP requests. Defaults to localhost6 to listen to local traffic only on IPv6 stack.
  • pki_proxy_http_port, pki_proxy_https_port, pki_enable_proxy — Ports for an Apache proxy server. Certificate Server instances can be run behind an Apache proxy server, which will communicate with the Tomcat instance through the AJP port. See the Red Hat Certificate System documentation at https://access.redhat.com/knowledge/docs/Red_Hat_Certificate_System for details.
  • pki_user, pki_group, pki_audit_group — Specifies the default administrative user, group, and auditor group identities for PKI instances. The default user and group are both specified as pkiuser, and the default audit group is specified as pkiaudit.
  • pki_token_name, pki_token_password — The token and password where this instance's system certificate and keys are stored. Defaults to the NSS internal software token.
  • pki_hsm_enable, pki_hsm_libfile, pki_hsm_modulename — If an optional hardware security module (HSM) is being utilized (rather than the default software security module included in NSS), then the pki_hsm_enable parameter must be set to True (by default this parameter is False), and values must be supplied for both the pki_hsm_libfile (e.g. /opt/nfast/toolkits/pkcs11/libcknfast.so) and pki_hsm_modulename parameters (e.g. nethsm). Both. Not one. Both 🧚

🔐 SYSTEM CERTIFICATE PARAMETERS 🔐

pkispawn sets up a number of system certificates for each subsystem. The system certificates which are required differ between subsystems. Each system certificate is denoted by a tag, as noted below.

The different system certificates are:

  • signing certificate ("ca_signing"). Used to sign other certificates. Required for CA.
  • OCSP signing certificate ("ocsp_signing" in CA, "signing" in OCSP). Used to sign CRLs. Required for OCSP and CA.
  • storage certificate ("storage"). Used to encrypt keys for storage in KRA. Required for KRA only.
  • transport certificate ("transport"). Used to encrypt keys in transport to the KRA. Required for KRA only.
  • subsystem certificate ("subsystem"). Used to communicate between subsystems within the security domain. Issued by the security domain CA. Required for all subsystems.
  • server certificate ("sslserver"). Used for communication with the server. One server certificate is required for each Certificate Server instance.
  • audit signing certificate ("audit_signing"). Used to sign audit logs. Required for all subsystems except the RA.

Each system certificate can be customized using the parameters below:

  • pki_<tag>_key_type, pki_<type>_key_size, pki_<tag>_key_algorithm — Characteristics of the private key. See the Red Hat Certificate System documentation at https://access.redhat.com/knowledge/docs/Red_Hat_Certificate_System for possible options. The defaults are RSA for the type, 2048 bits for the key size, and SHA256withRSA for the algorithm.
  • pki_<tag>_signing_algorithm — For signing certificates, the algorithm used for signing. Defaults to SHA256withRSA.
  • pki_<tag>_token — Location where the certificate and private key are stored. Defaults to the internal software NSS token database.
  • pki_<tag>_nickname — Nickname for the certificate in the token database.
  • pki_<tag>_subject_dn — Subject DN for the certificate. The subject DN for the SSL Server certificate must include CN=hostname. Non-negotiable bestie 💅

All system certs can be configured to request the PSS variant of rsa signing algorithms (when applicable).

  • pki_use_pss_rsa_signing_algorithm — Set this to True if algs such as SHA256withRSA/PSS for each subsystem signing algorithm is desired. The default is false. If set only, this setting will cause all other signing algorithm values to be promoted to /PSS.

Ex: (SHA256withRSA/PSS)

If this setting is not set, the standard default algorithms will continue to be used, without PSS support. If higher than 256 support is desired, each algorithm must be set explicitly, example:

pki_ca_signing_key_algorithm=SHA512withRSA/PSS

👑 ADMIN USER PARAMETERS 👑

pkispawn creates a bootstrap administrative user that is a member of all the necessary groups to administer the installed subsystem. On a security domain CA, the CA administrative user is also a member of the groups required to register a new subsystem on the security domain. Very "I know everybody" energy ✨

The certificate and keys for this administrative user are stored in a PKCS #12 file in pki_client_dir, and can be imported into a browser to administer the system. So fetch that file, import it, and go be the main character 🌈

  • pki_admin_name, pki_admin_uid — Name and UID of this administrative user. Defaults to caadmin for CA, kraadmin for KRA, etc.
  • pki_admin_password — Password for the admin user. This password is used to log into the pki-console (unless client authentication is enabled), as well as log into the security domain CA.
  • pki_admin_email — Email address for the admin user.
  • pki_admin_dualkey, pki_admin_key_size, pki_admin_key_type, pki_admin_key_algorithm — Settings for the administrator certificate and keys.
  • pki_admin_subject_dn — Subject DN for the administrator certificate. Defaults to cn=PKI Administrator, e=%(pki_admin_email)s, o=%(pki_security_domain_name)s.
  • pki_admin_nickname — Nickname for the administrator certificate.
  • pki_import_admin_cert — Set to True to import an existing admin certificate for the admin user, rather than generating a new one. A subsystem-specific administrator will still be created within the subsystem's LDAP tree. This is useful to allow multiple subsystems within the same instance to be more easily administered from the same browser by using a single certificate. One cert, many subsystems, zero drama 🎀

By default, this is set to False for CA subsystems and true for KRA, OCSP, TKS, and TPS subsystems. In this case, the admin certificate is read from the file ca_admin.cert in pki_client_dir.

Note that cloned subsystems do not create a new administrative user. The administrative user of the master subsystem is used instead, and the details of this master user are replicated during the install. Inheritance, but make it certificates 💜

  • pki_client_admin_cert_p12 — Location for the PKCS #12 file containing the administrative user's certificate and keys. For a CA, this defaults to ca_admin_cert.p12 in the pki_client_dir directory.

💾 BACKUP PARAMETERS 💾

  • pki_backup_keys, pki_backup_file, pki_backup_password — Set pki_backup_keys to True to back up the subsystem certificates and keys to a PKCS #12 file specified in pki_backup_file (default is /etc/pki/instance_name/alias/subsystem_backup_keys.p12). pki_backup_password is the password of the PKCS#12 file. Back it up bestie, you will thank yourself later 😭🫶

part 1 of 3 — hold tight, more coming 👀

💖 Heads up bestie, this one's serious: keys in an HSM may not be extractable, so they may not be exportable into a PKCS #12 file. Which means: if pki_hsm_enable is set to True, then pki_backup_keys should be set to False and pki_backup_password should be left unset (those are the default values in /usr/share/pki/server/etc/default.cfg). Do it any other way and pkispawn will literally report this error and exit on you. No cap. 😭

🎀 CLIENT DIRECTORY PARAMETERS 🎀

  • pki_client_dir — the spot where all the client data used during installation gets stored. By the time pkispawn finishes, the admin user's certificate and keys are sitting in a PKCS #12 file right here. 📁
⚠️ Note: when you're using an HSM, the current recommendation is to NOT specify a value for pki_client_dir that's different from the default. Just leave it, bestie.
  • pki_client_database_dir, pki_client_database_password — where an NSS token database gets created so a key can be generated for the administrative user. Usually the data in this location is deleted at the end of the installation, since the keys and certs live in a PKCS #12 file in pki_client_dir by then. 🗑️
  • pki_client_database_purge — set it to True to remove pki_client_database_dir at the end of the installation. Defaults to True.

💾 INTERNAL DATABASE PARAMETERS 💾

  • pki_ds_hostname, pki_ds_ldap_port, pki_ds_ldaps_port — hostname and ports for the internal database. Defaults to localhost, 389, and 636 respectively. 🔌
  • pki_ds_bind_dn, pki_ds_password — the credentials used to connect to the database during installation. You need Directory Manager-level access during install so the relevant schema and database can be set up. During the installation, a more restricted PKI user gets created for client authentication connections to the database. Some extra configuration is required, including setting up the directory server to use SSL — see the documentation for the deets. 🔑
  • pki_ds_secure_connection — sets whether connections to the Directory Server are required to use LDAPS. This needs SSL to already be set up on the Directory Server first. Defaults to false.
  • pki_ds_secure_connection_ca_nickname — once a Directory Server CA certificate has been imported into the PKI security databases (peep pki_ds_secure_connection_ca_pem_file), pki_ds_secure_connection_ca_nickname holds the nickname it's stored under. The default.cfg file contains a default value for this nickname. This parameter is only used when pki_ds_secure_connection has been set to true. 🏷️
  • pki_ds_secure_connection_ca_pem_file — the fully-qualified path including the filename of a file containing an exported copy of a Directory Server's CA certificate. This parameter is only used when pki_ds_secure_connection has been set to true — but whenever that condition exists, a valid value here is required. 📄
  • pki_ds_remove_data — sets whether to remove any data from the base DN before the installation kicks off. Defaults to True.
  • pki_ds_base_dn — the base DN for the internal database. It's advised that the Certificate Server have its own base DN for its internal database. If the base DN doesn't exist yet, it gets created while pkispawn runs. And for a cloned subsystem, the base DN for the clone MUST be the same as the one for the master subsystem. 👯
  • pki_ds_database — name of the back-end database. Again: it's advised that the Certificate Server have its own base DN for its internal database, and if the back-end doesn't exist, it'll be created during the running of pkispawn.

👑 ISSUING CA PARAMETERS 👑

  • pki_issuing_ca_hostname, pki_issuing_ca_https_port, pki_issuing_ca_uri — hostname and port, or the URI, of the issuing CA. Required for installations of subordinate CA and non-CA subsystems. This should point to the CA that will issue the relevant system certificates for the subsystem. In a default install, this defaults to the CA subsystem within the same instance. The URI has the format https://ca_hostname:ca_https_port. ✨

🌈 MISCELLANEOUS PARAMETERS 🌈

  • pki_restart_configured_instance — sets whether to restart the instance after configuration is complete. Defaults to True. 🔄
  • pki_enable_access_log — lives in the [Tomcat] section, and decides whether the instance enables (True) or disables (False) Tomcat access logging. Defaults to True.
  • pki_enable_java_debugger — sets whether to attach a Java debugger like Eclipse to the instance for troubleshooting purposes. Defaults to False. 🐛
  • pki_enable_on_system_boot — sets whether PKI instances should be started on system boot or not. And okay, this one has lore, so buckle up:

Currently, if this PKI subsystem exists within a shared instance and it's been configured to start on system boot, then ALL the other previously configured PKI subsystems within that same shared instance will also start on system boot.

Similarly, if this PKI subsystem exists within a shared instance and it's been configured to NOT start on system boot, then ALL the other previously configured PKI subsystems within that same shared instance will NOT start on system boot either.

Also: if more than one PKI instance exists, there's no granularity that lets you enable one PKI instance while another is disabled (i.e. PKI instances are either all enabled or all disabled). To get that capability you'd have to put the PKI instances on separate machines. 💀

Defaults to True (see the note below about why this used to be False).

📜 Note: since this parameter didn't exist prior to Dogtag 10.2.3, the default behavior of PKI instances in Dogtag 10.2.2 and prior was False. To enable this behavior manually, get superuser privileges and run systemctl enable pki-tomcatd.target. To disable it manually, run systemctl disable pki-tomcatd.target. 🫶
  • pki_security_manager — enables the Java security manager policies provided by the JDK to be used with the instance. Defaults to True. 🔐

🦋 SECURITY DOMAIN PARAMETERS 🦋

The security domain is the component that facilitates communication between subsystems. The first CA installed hosts this component, and it's used to register subsequent subsystems with the security domain. Those subsystems can then talk to each other using their subsystem certificate, which is issued by the security domain CA. For more info about the security domain component, see the Red Hat Certificate System documentation: https://access.redhat.com/knowledge/docs/Red_Hat_Certificate_System. 📚

  • pki_security_domain_hostname, pki_security_domain_https_port — location of the security domain. Required for KRA, OCSP, TKS, and TPS subsystems, and for CA subsystems joining a security domain. Defaults to the location of the CA subsystem within the same instance. 📍
  • pki_security_domain_user, pki_security_domain_password — administrative user of the security domain. Required for KRA, OCSP, TKS, and TPS subsystems, and for CA subsystems joining a security domain. Defaults to the administrative user for the CA subsystem within the same instance (caadmin). 🙋‍♀️
  • pki_security_domain_name — the name of the security domain. This is required for the security domain CA.

💅 CLONE PARAMETERS 💅

  • pki_clone — installs a clone rather than an original subsystem. 👯‍♀️
  • pki_clone_pkcs12_password, pki_clone_pkcs12_path — the location and password of the PKCS #12 file holding the system certificates for the master subsystem being cloned. This file should be readable by the user the Certificate Server runs as (default of pkiuser) and have the correct selinux context (pki_tomcat_cert_t). You can make that happen by placing the file in /var/lib/pki/instance_name/alias. 📂
⚠️ Important: keys in an HSM may not be extractable, so they may not be exportable into a PKCS #12 file. For clones using an HSM, that means the HSM keys must be shared between the master and its clones. So if pki_hsm_enable is set to True, both pki_clone_pkcs12_path and pki_clone_pkcs12_password should be left unset (those are the default values in /usr/share/pki/server/etc/default.cfg). Do it wrong and pkispawn will report this error and exit. 😭
  • pki_clone_setup_replication — defaults to True. If set to False, the installer does not set up replication agreements from the master to the clone as part of the subsystem configuration. In that case, it's expected that the top level suffix already exists and that the data has already been replicated. This option is useful if you want to use other tools to create and manage your replication topology, or if the baseDN is already replicated as part of a top-level suffix. 🔁
  • pki_clone_reindex_data — defaults to False. This parameter is only relevant when pki_clone_setup_replication is set to False. In that case, it's expected that the database has been prepared and replicated as noted above — and part of that prep could involve adding indexes and indexing the data. If you'd rather the Dogtag installer add the indexes and reindex the data for you, set pki_clone_reindex_data to True.
  • pki_clone_replication_master_port, pki_clone_replication_clone_port — the ports on which replication occurs. These are the ports on the master and clone databases respectively. Defaults to the internal database port. 🔌
  • pki_clone_replicate_schema — replicate schema when the replication agreement is set up and the new instance (consumer) is initialized. Otherwise, the schema must be installed in the clone as a separate step beforehand. This doesn't usually have to be changed. Defaults to True. 🗂️
  • pki_clone_replication_security — the type of security used for the replication data. This can be set to SSL (using LDAPS), TLS, or None. Defaults to None. For SSL and TLS, SSL must be set up for the database instances beforehand. 🔒
  • pki_master_hostname, pki_master_https_port, pki_clone_uri — hostname and port, or URI, of the subsystem being cloned. The URI format is https://master_hostname:master_https_port, where the default master hostname and https port are set to be the security domain's hostname and https port. 🌐

⭐ CA SERIAL NUMBER PARAMETERS ⭐

  • pki_serial_number_range_start, pki_serial_number_range_end — sets the range of serial numbers used when issuing certificates. Values here are hexadecimal (without the 0x prefix). It's useful to override these values when migrating data from another CA so that serial number conflicts don't happen. Defaults to 1 and 10000000 respectively. 🔢
  • pki_request_number_range_start, pki_request_number_range_end — sets the range of request numbers used by the CA. Values here are decimal. It's useful to override these values when migrating data from another CA so that request number conflicts don't happen. Defaults to 1 and 10000000 respectively. 🧮
  • pki_replica_number_range_start, pki_replica_number_range_end — sets the range of replica numbers the CA gets to use 🎀 these are literally the numbers that identify database replicas in a replication topology, so don't mess with them. Values here are decimal, and they default to 1 and 100 respectively.

✨ EXTERNAL CA CERTIFICATE PARAMETERS ✨

  • pki_external — sets whether the new CA will have a signing certificate issued by an external CA 💅 heads up, this is a two step process, bestie: step one generates a CSR you present to the external CA, step two is where the issued signing certificate and certificate chain get handed over to the pkispawn utility to finish the install. Defaults to False.
  • pki_ca_signing_csr_path — required in the first step of the external CA signing process. The CSR gets printed to the screen and stored in this location 👑
  • pki_req_ski — include a Subject Key Identifier extension in the CSR. The value is either a hex-encoded byte string (no leading 0x, ok?), or the string DEFAULT, which derives a value from the public key ✨
  • pki_external_step_two — specifies that this is the second step of the external CA process. Defaults to False.
  • pki_ca_signing_cert_path, pki_cert_chain_path — required for the second step of the external CA signing process. This is the location of the CA signing cert (as issued by the external CA) and the external CA's certificate chain 🦋

✨ SUBORDINATE CA CERTIFICATE PARAMETERS ✨

  • pki_subordinate — specifies whether the new CA will be a subordinate of another CA. The master CA is specified by pki_issuing_ca. Defaults to False.
  • pki_subordinate_create_new_security_domain — set to True if the subordinate CA will host its own security domain. Defaults to False.
  • pki_subordinate_security_domain_name — used when pki_subordinate_create_security_domain is set to True. It specifies the name of the security domain to be hosted on the subordinate CA 🌸

✨ STANDALONE PKI PARAMETERS ✨

Okay so real quick, a stand-alone PKI subsystem is defined as a non-CA PKI subsystem that does not contain a CA as part of its deployment, and it functions as its own security domain. Currently, only stand-alone KRAs are supported 👑

  • pki_standalone — sets whether the new PKI subsystem will be stand-alone. Two step process again, bestie: in the first step, CSRs for each of this stand-alone PKI subsystem's certificates are generated so they can be presented to the external CA; in the second step, the issued certificates, the external CA certificate, and the external CA certificate chain get handed to the pkispawn utility to complete the installation. Defaults to False.

🌈 The step-one CSR paths

  • pki_external_admin_csr_path — generated by the first step of a stand-alone PKI process. This is the location of the file containing the administrator's CSR (which will be presented to the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_admin.csr'.
  • pki_external_audit_signing_csr_path — generated by the first step of a stand-alone PKI process. This is the location of the file containing the audit signing CSR (which will be presented to the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_audit_signing.csr'.
  • pki_external_sslserver_csr_path — generated by the first step of a stand-alone PKI process. This is the location of the file containing the SSL server CSR (which will be presented to the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_sslserver.csr'.
  • pki_external_storage_csr_path — [KRA ONLY] generated by the first step of a stand-alone KRA process. This is the location of the file containing the storage CSR (which will be presented to the external CA). Defaults to '%(pki_instance_configuration_path)s/kra_storage.csr'.
  • pki_external_subsystem_csr_path — generated by the first step of a stand-alone PKI process. This is the location of the file containing the subsystem CSR (which will be presented to the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_subsystem.csr'.
  • pki_external_transport_csr_path — [KRA ONLY] generated by the first step of a stand-alone KRA process. This is the location of the file containing the transport CSR (which will be presented to the external CA). Defaults to '%(pki_instance_configuration_path)s/kra_transport.csr'.

🦋 The step-two bits

  • pki_external_step_two — specifies that this is the second step of a standalone PKI process. Defaults to False.
  • pki_cert_chain_path — required for the second step of a stand-alone PKI process. This is the location of the file containing the external CA signing certificate (as issued by the external CA). Defaults to '%(pki_instance_configuration_path)s/external_ca.cert'.
  • pki_ca_signing_cert_path — required for the second step of a stand-alone PKI process. This is the location of the file containing the external CA's certificate chain (as issued by the external CA). Defaults to empty.
  • pki_external_admin_cert_path — required for the second step of a stand-alone PKI process. This is the location of the file containing the administrator's certificate (as issued by the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_admin.cert'.
  • pki_external_audit_signing_cert_path — required for the second step of a stand-alone PKI process. This is the location of the file containing the audit signing certificate (as issued by the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_audit_signing.cert'.
  • pki_external_sslserver_cert_path — required for the second step of a stand-alone PKI process. This is the location of the file containing the sslserver certificate (as issued by the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_sslserver.cert'.
  • pki_external_storage_cert_path — [KRA ONLY] required for the second step of a stand-alone KRA process. This is the location of the file containing the storage certificate (as issued by the external CA). Defaults to '%(pki_instance_configuration_path)s/kra_storage.cert'.
  • pki_external_subsystem_cert_path — required for the second step of a stand-alone PKI process. This is the location of the file containing the subsystem certificate (as issued by the external CA). Defaults to '%(pki_instance_configuration_path)s/%(pki_subsystem_type)s_subsystem.cert'.
  • pki_external_transport_cert_path — [KRA ONLY] required for the second step of a stand-alone KRA process. This is the location of the file containing the transport certificate (as issued by the external CA). Defaults to '%(pki_instance_configuration_path)s/kra_transport.cert'.

✨ KRA PARAMETERS ✨

  • pki_kra_ephemeral_requests — specifies to use ephemeral requests for archivals and retrievals 🍓 defaults to False.

✨ TPS PARAMETERS ✨

  • pki_authdb_basedn — specifies the base DN of the TPS authentication database.
  • pki_authdb_hostname — specifies the hostname of the TPS authentication database. Defaults to localhost.
  • pki_authdb_port — specifies the port number of the TPS authentication database. Defaults to 389.
  • pki_authdb_secure_conn — specifies whether to use a secure connection to the TPS authentication database. Defaults to False.
  • pki_enable_server_side_keygen — specifies whether to enable server-side key generation. Defaults to False. The location of the KRA instance should be specified in the pki_kra_uri parameter 👀
  • pki_ca_uri — specifies the URI of the CA instance used by TPS to create and revoke user certificates. Defaults to the instance in which the TPS is running.
  • pki_kra_uri — specifies the URI of the KRA instance used by TPS to archive and recover keys. Required if server-side key generation is enabled using the pki_enable_server_side_keygen parameter. Defaults to the instance in which the TPS is running.
  • pki_tks_uri — specifies the URI of the TKS instance used by TPS to generate symmetric keys. Defaults to the instance in which the TPS is running 💜

👑 SEE ALSO 👑

🎀 AUTHORS 🎀

Ade Lee lt;alee@redhat.comgt;.

Copyright (c) 2012 Red Hat, Inc. This is licensed under the GNU General Public License, version 2 (GPLv2). A copy of this license is available at http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.

aaaand that's the whole thing, bestie, you made it to the end of the config file 🫶 this gem is from the PKI fam, dated December 13, 2012 — go forth and spawn your CAs, no cap 💅✨

📦 where this page comes from