1pki_default.cfg(5)PKI Server Default Deployment Configurationpki_default.cfg(5)
2
6 pki_default.cfg - PKI server default deployment configuration file.
7
10 /usr/share/pki/server/etc/default.cfg
11
14 This file contains the default settings for a Certificate Server in‐
15 stance created using pkispawn. This file should not be edited, as it
16 can be modified when the Certificate Server packages are updated. In‐
17 stead, when setting up a Certificate Server instance, a user should
18 provide pkispawn with a configuration file containing overrides to the
19 defaults in /usr/share/pki/server/etc/default.cfg. See pkispawn(8) for
20 details.
21
24 default.cfg contains parameters that are grouped into sections. These
25 sections are stacked, so that parameters defined in earlier sections
26 can be overwritten by parameters defined in later sections. The sec‐
27 tions are read in the following order: [DEFAULT], [Tomcat], and the
28 subsystem section ([CA], [KRA], [OCSP], [TKS], or [TPS]). This allows
29 the ability to specify parameters to be shared by all subsystems in
30 [DEFAULT] or [Tomcat], and subsystem-specific customization.
31 There are a small number of bootstrap parameters which are passed in
34 the configuration file by pkispawn. Other parameter's values can be
35 interpolated tokens rather than explicit values. For example:
36 pki_ca_signing_nickname=caSigningCert cert-%(pki_instance_name)s CA
39 This substitutes the value of pki_instance_name into the parameter
43 value. It is possible to interpolate any non-password parameter within
44 a section or in [DEFAULT]. Any parameter used in interpolation can
45 ONLY be overridden within the same section. So, for example, pki_in‐
46 stance_name should only be overridden in [DEFAULT]; otherwise, interpo‐
47 lations can fail.
48 Note: Any non-password related parameter values in the configuration
51 file that needs to contain a % character must be properly escaped. For
52 example, a value of foo%bar would be specified as foo%%bar in the con‐
53 figuration file.
54
57 Once the configuration parameters have been constructed from the above
58 sections and overrides, pkispawn will perform a series of basic tests
59 to determine if the parameters being passed in are valid and consis‐
60 tent, before starting any installation. In pre-check mode, these tests
61 are executed and then pkispawn exits.
62 It is possible to disable specific tests by setting the directives be‐
65 low. While all these tests should pass to ensure a successful instal‐
66 lation, it may be reasonable to skip tests in pre-check mode.
67 pki_skip_ds_verify
70 Skip verification of the Directory Server credentials. In this test,
71 pkispawn attempts to bind to the directory server instance for the in‐
72 ternal database using the provided credentials. This could be skipped
73 if the directory server instance does not yet exist or is inaccessible.
74 Defaults to False.
75 pki_skip_sd_verify
78 Skip verification of the security domain user/password. In this test,
79 pkispawn attempts to log onto the security domain using the provided
80 credentials. This can be skipped if the security domain is unavail‐
81 able. Defaults to False.
82
85 The parameters described below, as well as the parameters located in
86 the following sections, can be customized as part of a deployment.
87 This list is not exhaustive.
88 pki_instance_name
91 Name of the instance. The instance is located at /var/lib/pki/in‐
92 stance_name. For Java subsystems, the default is specified as pki-tom‐
93 cat.
94 pki_https_port, pki_http_port
97 Secure and unsecure ports. Defaults to standard Tomcat ports 8443 and
98 8080, respectively.
99 pki_ajp_port, pki_tomcat_server_port
102 Ports for Tomcat subsystems. Defaults to standard Tomcat ports of 8009
103 and 8005, respectively.
104 pki_ajp_host
107 Host on which to listen for AJP requests. Defaults to localhost4 to
108 listen to local traffic only on IPv4 stack. NOTE Deprecated in favor of
109 pki_ajp_host_ipv4.
110 pki_ajp_host_ipv4 Host on which to listen for AJP requests. Defaults
113 to localhost4 to listen to local traffic only on IPv4 stack.
114 pki_ajp_host_ipv6 Host on which to listen for AJP requests. Defaults
117 to localhost6 to listen to local traffic only on IPv6 stack.
118 pki_proxy_http_port, pki_proxy_https_port, pki_enable_proxy
121 Ports for an Apache proxy server. Certificate Server instances can be
122 run behind an Apache proxy server, which will communicate with the Tom‐
123 cat instance through the AJP port. See the Red Hat Certificate System
124 documentation ⟨https://access.redhat.com/knowledge/docs/Red_Hat_Cer‐
125 tificate_System⟩ for details.
126 pki_user, pki_group, pki_audit_group
129 Specifies the default administrative user, group, and auditor group
130 identities for PKI instances. The default user and group are both
131 specified as pkiuser, and the default audit group is specified as pki‐
132 audit.
133 pki_token_name, pki_token_password
136 The token and password where this instance's system certificate and
137 keys are stored. Defaults to the NSS internal software token.
138 pki_hsm_enable, pki_hsm_libfile, pki_hsm_modulename
141 If an optional hardware security module (HSM) is being utilized (rather
142 than the default software security module included in NSS), then the
143 pki_hsm_enable parameter must be set to True (by default this parameter
144 is False), and values must be supplied for both the pki_hsm_libfile
145 (e.g. /opt/nfast/toolkits/pkcs11/libcknfast.so) and pki_hsm_modulename
146 parameters (e.g. nethsm).
147 SYSTEM CERTIFICATE PARAMETERS
150 pkispawn sets up a number of system certificates for each subsystem.
151 The system certificates which are required differ between subsystems.
152 Each system certificate is denoted by a tag, as noted below. The dif‐
153 ferent system certificates are:
154 • signing certificate ("ca_signing"). Used to sign other cer‐
157 tificates. Required for CA.
158 • OCSP signing certificate ("ocsp_signing" in CA, "signing" in
160 OCSP). Used to sign CRLs. Required for OCSP and CA.
161 • storage certificate ("storage"). Used to encrypt keys for
163 storage in KRA. Required for KRA only.
164 • transport certificate ("transport"). Used to encrypt keys in
166 transport to the KRA. Required for KRA only.
167 • subsystem certificate ("subsystem"). Used to communicate be‐
169 tween subsystems within the security domain. Issued by the
170 security domain CA. Required for all subsystems.
171 • server certificate ("sslserver"). Used for communication with
173 the server. One server certificate is required for each Cer‐
174 tificate Server instance.
175 • audit signing certificate ("audit_signing"). Used to sign au‐
177 dit logs. Required for all subsystems except the RA.
178 Each system certificate can be customized using the parameters below:
182 pki_<tag>_key_type, pki_<type>_key_size,
185 pki_<tag>_key_algorithm
186 Characteristics of the private key. See the Red Hat Certificate System
187 documentation ⟨https://access.redhat.com/knowledge/docs/Red_Hat_Cer‐
188 tificate_System⟩ for possible options. The defaults are RSA for the
189 type, 2048 bits for the key size, and SHA256withRSA for the algorithm.
190 pki_<tag>_signing_algorithm
193 For signing certificates, the algorithm used for signing. Defaults to
194 SHA256withRSA.
195 pki_<tag>_token
198 Location where the certificate and private key are stored. Defaults to
199 the internal software NSS token database.
200 pki_<tag>_nickname
203 Nickname for the certificate in the token database.
204 pki_<tag>_subject_dn
207 Subject DN for the certificate. The subject DN for the SSL Server cer‐
208 tificate must include CN=hostname.
209 All system certs can be configured to request the PSS variant of rsa
212 signing algorithms (when applicable).
213 pki_use_pss_rsa_signing_algorithm
216 Set this to True if algs such as SHA256withRSA/PSS for each subsystem
219 signing algorithm is desired. The default is false. If set only, this
220 setting will cause all other signing algorithm values to be promoted to
221 /PSS.
222 Ex: (SHA256withRSA/PSS)
225 If this setting is not set, the standard default algorithms will con‐
228 tinue to be used, without PSS support.. If higher than 256 support is
229 desired, each algorithm must be set explicitly, example:
230 pki_ca_signing_key_algorithm=SHA512withRSA/PSS
233 ADMIN USER PARAMETERS
236 pkispawn creates a bootstrap administrative user that is a member of
237 all the necessary groups to administer the installed subsystem. On a
238 security domain CA, the CA administrative user is also a member of the
239 groups required to register a new subsystem on the security domain.
240 The certificate and keys for this administrative user are stored in a
241 PKCS #12 file in pki_client_dir, and can be imported into a browser to
242 administer the system.
243 pki_admin_name, pki_admin_uid
246 Name and UID of this administrative user. Defaults to caadmin for CA,
247 kraadmin for KRA, etc.
248 pki_admin_password
251 Password for the admin user. This password is used to log into the
252 pki-console (unless client authentication is enabled), as well as log
253 into the security domain CA.
254 pki_admin_email
257 Email address for the admin user.
258 pki_admin_dualkey, pki_admin_key_size, pki_admin_key_type, pki_ad‐
261 min_key_algorithm
262 Settings for the administrator certificate and keys.
263 pki_admin_subject_dn
266 Subject DN for the administrator certificate. Defaults to cn=PKI Ad‐
267 ministrator, e=%(pki_admin_email)s, o=%(pki_security_domain_name)s.
268 pki_admin_nickname
271 Nickname for the administrator certificate.
272 pki_import_admin_cert
275 Set to True to import an existing admin certificate for the admin user,
276 rather than generating a new one. A subsystem-specific administrator
277 will still be created within the subsystem's LDAP tree. This is useful
278 to allow multiple subsystems within the same instance to be more easily
279 administered from the same browser by using a single certificate.
280 By default, this is set to False for CA subsystems and true for KRA,
283 OCSP, TKS, and TPS subsystems. In this case, the admin certificate is
284 read from the file ca_admin.cert in pki_client_dir.
285 Note that cloned subsystems do not create a new administrative user.
288 The administrative user of the master subsystem is used instead, and
289 the details of this master user are replicated during the install.
290 pki_client_admin_cert_p12
293 Location for the PKCS #12 file containing the administrative user's
294 certificate and keys. For a CA, this defaults to ca_admin_cert.p12 in
295 the pki_client_dir directory.
296 BACKUP PARAMETERS
299 pki_backup_keys, pki_backup_file, pki_backup_password
300 Set pki_backup_keys to True to back up the subsystem certificates and
301 keys to a PKCS #12 file specified in pki_backup_file (default is
302 /etc/pki/instance_name/alias/subsystem_backup_keys.p12).
303 pki_backup_password is the password of the PKCS#12 file.
304 Important: Keys in HSM may not be extractable, so they may not be able
307 to be exported into a PKCS #12 file. Therefore, if pki_hsm_enable is
308 set to True, pki_backup_keys should be set to False and
309 pki_backup_password should be left unset (the default values in
310 /usr/share/pki/server/etc/default.cfg). Failure to do so will result
311 in pkispawn reporting this error and exiting.
312 CLIENT DIRECTORY PARAMETERS
315 pki_client_dir
316 This is the location where all client data used during the installation
317 is stored. At the end of the invocation of pkispawn, the administra‐
318 tive user's certificate and keys are stored in a PKCS #12 file in this
319 location.
320 Note: When using an HSM, it is currently recommended to NOT specify a
323 value for pki_client_dir that is different from the default value.
324 pki_client_database_dir, pki_client_database_password
327 Location where an NSS token database is created in order to generate a
328 key for the administrative user. Usually, the data in this location is
329 removed at the end of the installation, as the keys and certificates
330 are stored in a PKCS #12 file in pki_client_dir.
331 pki_client_database_purge
334 Set to True to remove pki_client_database_dir at the end of the instal‐
335 lation. Defaults to True.
336 INTERNAL DATABASE PARAMETERS
339 pki_ds_hostname, pki_ds_ldap_port, pki_ds_ldaps_port
340 Hostname and ports for the internal database. Defaults to localhost,
341 389, and 636, respectively.
342 pki_ds_bind_dn, pki_ds_password
345 Credentials to connect to the database during installation. Directory
346 Manager-level access is required during installation to set up the rel‐
347 evant schema and database. During the installation, a more restricted
348 PKI user is set up to client authentication connections to the data‐
349 base. Some additional configuration is required, including setting up
350 the directory server to use SSL. See the documentation for details.
351 pki_ds_secure_connection
354 Sets whether to require connections to the Directory Server using
355 LDAPS. This requires SSL to be set up on the Directory Server first.
356 Defaults to false.
357 pki_ds_secure_connection_ca_nickname
360 Once a Directory Server CA certificate has been imported into the PKI
361 security databases (see pki_ds_secure_connection_ca_pem_file),
362 pki_ds_secure_connection_ca_nickname will contain the nickname under
363 which it is stored. The default.cfg file contains a default value for
364 this nickname. This parameter is only utilized when pki_ds_secure_con‐
365 nection has been set to true.
366 pki_ds_secure_connection_ca_pem_file
369 The pki_ds_secure_connection_ca_pem_file parameter will consist of the
370 fully-qualified path including the filename of a file which contains an
371 exported copy of a Directory Server's CA certificate. While this pa‐
372 rameter is only utilized when pki_ds_secure_connection has been set to
373 true, a valid value is required for this parameter whenever this condi‐
374 tion exists.
375 pki_ds_remove_data
378 Sets whether to remove any data from the base DN before starting the
379 installation. Defaults to True.
380 pki_ds_base_dn
383 The base DN for the internal database. It is advised that the Certifi‐
384 cate Server have its own base DN for its internal database. If the
385 base DN does not exist, it will be created during the running of
386 pkispawn. For a cloned subsystem, the base DN for the clone subsystem
387 MUST be the same as for the master subsystem.
388 pki_ds_database
391 Name of the back-end database. It is advised that the Certificate
392 Server have its own base DN for its internal database. If the back-end
393 does not exist, it will be created during the running of pkispawn.
394 ISSUING CA PARAMETERS
397 pki_issuing_ca_hostname, pki_issuing_ca_https_port, pki_issuing_ca_uri
398 Hostname and port, or URI of the issuing CA. Required for installa‐
399 tions of subordinate CA and non-CA subsystems. This should point to
400 the CA that will issue the relevant system certificates for the subsys‐
401 tem. In a default install, this defaults to the CA subsystem within
402 the same instance. The URI has the format https://ca_host‐
403 name:ca_https_port.
404 MISCELLANEOUS PARAMETERS
407 pki_enable_access_log
408 Located in the [Tomcat] section, this variable determines whether the
409 instance will enable (True) or disable (False) Tomcat access logging.
410 Defaults to True.
411 pki_enable_java_debugger
414 Sets whether to attach a Java debugger such as Eclipse to the instance
415 for troubleshooting. Defaults to False.
416 pki_enable_on_system_boot
419 Sets whether or not PKI instances should be started upon system boot.
420 Currently, if this PKI subsystem exists within a shared instance, and
423 it has been configured to start upon system boot, then ALL other previ‐
424 ously configured PKI subsystems within this shared instance will start
425 upon system boot.
426 Similarly, if this PKI subsystem exists within a shared instance, and
429 it has been configured to NOT start upon system boot, then ALL other
430 previously configured PKI subsystems within this shared instance will
431 NOT start upon system boot.
432 Additionally, if more than one PKI instance exists, no granularity ex‐
435 ists which allows one PKI instance to be enabled while another PKI in‐
436 stance is disabled (i.e. PKI instances are either all enabled or all
437 disabled). To provide this capability, the PKI instances must reside
438 on separate machines.
439 Defaults to True (see the following note on why this was previously
442 'False').
443 Note: Since this parameter did not exist prior to Dogtag 10.2.3, the
446 default behavior of PKI instances in Dogtag 10.2.2 and prior was False.
447 To manually enable this behavior, obtain superuser privileges, and exe‐
448 cute 'systemctl enable pki-tomcatd.target'; to manually disable this
449 behavior, execute 'systemctl disable pki-tomcatd.target'.
450 pki_security_manager
453 Enables the Java security manager policies provided by the JDK to be
454 used with the instance. Defaults to True.
455 SECURITY DOMAIN PARAMETERS
458 The security domain is a component that facilitates communication be‐
459 tween subsystems. The first CA installed hosts this component and is
460 used to register subsequent subsystems with the security domain. These
461 subsystems can communicate with each other using their subsystem cer‐
462 tificate, which is issued by the security domain CA. For more informa‐
463 tion about the security domain component, see the Red Hat Certificate
464 System documentation ⟨https://access.redhat.com/knowl‐
465 edge/docs/Red_Hat_Certificate_System⟩.
466 pki_security_domain_hostname, pki_security_domain_https_port
469 Location of the security domain. Required for KRA, OCSP, TKS, and TPS
470 subsystems and for CA subsystems joining a security domain. Defaults
471 to the location of the CA subsystem within the same instance.
472 pki_security_domain_user, pki_security_domain_password
475 Administrative user of the security domain. Required for KRA, OCSP,
476 TKS, and TPS subsystems, and for CA subsystems joining a security do‐
477 main. Defaults to the administrative user for the CA subsystem within
478 the same instance (caadmin).
479 pki_security_domain_name
482 The name of the security domain. This is required for the security do‐
483 main CA.
484 CLONE PARAMETERS
487 pki_clone
488 Installs a clone, rather than original, subsystem.
489 pki_clone_pkcs12_password, pki_clone_pkcs12_path
492 Location and password of the PKCS #12 file containing the system cer‐
493 tificates for the master subsystem being cloned. This file should be
494 readable by the user that the Certificate Server is running as (default
495 of pkiuser), and have the correct selinux context (pki_tomcat_cert_t).
496 This can be achieved by placing the file in /var/lib/pki/in‐
497 stance_name/alias.
498 Important: Keys in HSM may not be extractable, so they may not be able
501 to be exported into a PKCS #12 file. For the case of clones using an
502 HSM, this means that the HSM keys must be shared between the master and
503 its clones. Therefore, if pki_hsm_enable is set to True, both
504 pki_clone_pkcs12_path and pki_clone_pkcs12_password should be left un‐
505 set (the default values in /usr/share/pki/server/etc/default.cfg).
506 Failure to do so will result in pkispawn reporting this error and exit‐
507 ing.
508 pki_clone_setup_replication
511 Defaults to True. If set to False, the installer does not set up
512 replication agreements from the master to the clone as part of the sub‐
513 system configuration. In this case, it is expected that the top level
514 suffix already exists, and that the data has already been replicated.
515 This option is useful if you want to use other tools to create and man‐
516 age your replication topology, or if the baseDN is already replicated
517 as part of a top-level suffix.
518 pki_clone_reindex_data
521 Defaults to False. This parameter is only relevant when
522 pki_clone_setup_replication is set to False. In this case, it is ex‐
523 pected that the database has been prepared and replicated as noted
524 above. Part of that preparation could involve adding indexes and in‐
525 dexing the data. If you would like the Dogtag installer to add the in‐
526 dexes and reindex the data instead, set pki_clone_reindex_data to True.
527 pki_clone_replication_master_port, pki_clone_replication_clone_port
530 Ports on which replication occurs. These are the ports on the master
531 and clone databases respectively. Defaults to the internal database
532 port.
533 pki_clone_replicate_schema
536 Replicate schema when the replication agreement is set up and the new
537 instance (consumer) is initialized. Otherwise, the schema must be in‐
538 stalled in the clone as a separate step beforehand. This does not usu‐
539 ally have to be changed. Defaults to True.
540 pki_clone_replication_security
543 The type of security used for the replication data. This can be set to
544 SSL (using LDAPS), TLS, or None. Defaults to None. For SSL and TLS,
545 SSL must be set up for the database instances beforehand.
546 pki_master_hostname, pki_master_https_port, pki_clone_uri
549 Hostname and port, or URI of the subsystem being cloned. The URI for‐
550 mat is https://master_hostname:master_https_port where the default mas‐
551 ter hostname and https port are set to be the security domain's host‐
552 name and https port.
553 CA SERIAL NUMBER PARAMETERS
556 pki_serial_number_range_start, pki_serial_number_range_end
557 Sets the range of serial numbers to be used when issuing certificates.
558 Values here are hexadecimal (without the 0x prefix). It is useful to
559 override these values when migrating data from another CA, so that se‐
560 rial number conflicts do not occur. Defaults to 1 and 10000000 respec‐
561 tively.
562 pki_request_number_range_start, pki_request_number_range_end
565 Sets the range of request numbers to be used by the CA. Values here
566 are decimal. It is useful to override these values when migrating data
567 from another CA, so that request number conflicts do not occur. De‐
568 faults to 1 and 10000000 respectively.
569 pki_replica_number_range_start, pki_replica_number_range_end
572 Sets the range of replica numbers to be used by the CA. These numbers
573 are used to identify database replicas in a replication topology. Val‐
574 ues here are decimal. Defaults to 1 and 100 respectively.
575 EXTERNAL CA CERTIFICATE PARAMETERS
578 pki_external
579 Sets whether the new CA will have a signing certificate that will be
580 issued by an external CA. This is a two step process. In the first
581 step, a CSR to be presented to the external CA is generated. In the
582 second step, the issued signing certificate and certificate chain are
583 provided to the pkispawn utility to complete the installation. De‐
584 faults to False.
585 pki_ca_signing_csr_path
588 Required in the first step of the external CA signing process. The CSR
589 will be printed to the screen and stored in this location.
590 pki_req_ski
593 Include a Subject Key Identifier extension in the CSR. The value is
594 either a hex-encoded byte string (without leading "0x"), or the string
595 "DEFAULT" which will derive a value from the public key.
596 pki_external_step_two
599 Specifies that this is the second step of the external CA process. De‐
600 faults to False.
601 pki_ca_signing_cert_path, pki_cert_chain_path
604 Required for the second step of the external CA signing process. This
605 is the location of the CA signing cert (as issued by the external CA)
606 and the external CA's certificate chain.
607 SUBORDINATE CA CERTIFICATE PARAMETERS
610 pki_subordinate
611 Specifies whether the new CA which will be a subordinate of another CA.
612 The master CA is specified by pki_issuing_ca. Defaults to False.
613 pki_subordinate_create_new_security_domain
616 Set to True if the subordinate CA will host its own security domain.
617 Defaults to False.
618 pki_subordinate_security_domain_name
621 Used when pki_subordinate_create_security_domain is set to True. Spec‐
622 ifies the name of the security domain to be hosted on the subordinate
623 CA.
624 STANDALONE PKI PARAMETERS
627 A stand-alone PKI subsystem is defined as a non-CA PKI subsystem that
628 does not contain a CA as a part of its deployment, and functions as its
629 own security domain. Currently, only stand-alone KRAs are supported.
630 pki_standalone
633 Sets whether or not the new PKI subsystem will be stand-alone. This is
634 a two step process. In the first step, CSRs for each of this stand-
635 alone PKI subsystem's certificates will be generated so that they may
636 be presented to the external CA. In the second step, the issued cer‐
637 tificates, external CA certificate, and external CA certificate chain
638 are provided to the pkispawn utility to complete the installation. De‐
639 faults to False.
640 pki_admin_csr_path
643 Will be generated by the first step of a stand-alone PKI process. This
644 is the location of the file containing the administrator's CSR (which
645 will be presented to the external CA). Defaults to empty.
646 pki_audit_signing_csr_path
649 Will be generated by the first step of a stand-alone PKI process. This
650 is the location of the file containing the audit signing CSR (which
651 will be presented to the external CA). Defaults to empty.
652 pki_sslserver_csr_path
655 Will be generated by the first step of a stand-alone PKI process. This
656 is the location of the file containing the SSL server CSR (which will
657 be presented to the external CA). Defaults to empty.
658 pki_storage_csr_path
661 [KRA ONLY] Will be generated by the first step of a stand-alone KRA
662 process. This is the location of the file containing the storage CSR
663 (which will be presented to the external CA). Defaults to empty.
664 pki_subsystem_csr_path
667 Will be generated by the first step of a stand-alone PKI process. This
668 is the location of the file containing the subsystem CSR (which will be
669 presented to the external CA). Defaults to empty.
670 pki_transport_csr_path
673 [KRA ONLY] Will be generated by the first step of a stand-alone KRA
674 process. This is the location of the file containing the transport CSR
675 (which will be presented to the external CA). Defaults to empty.
676 pki_external_step_two
679 Specifies that this is the second step of a standalone PKI process.
680 Defaults to False.
681 pki_cert_chain_path
684 Required for the second step of a stand-alone PKI process. This is the
685 location of the file containing the external CA signing certificate (as
686 issued by the external CA). Defaults to '%(pki_instance_configura‐
687 tion_path)s/external_ca.cert'.
688 pki_ca_signing_cert_path
691 Required for the second step of a stand-alone PKI process. This is the
692 location of the file containing the external CA's certificate chain (as
693 issued by the external CA). Defaults to empty.
694 pki_admin_cert_path
697 Required for the second step of a stand-alone PKI process. This is the
698 location of the file containing the administrator's certificate (as is‐
699 sued by the external CA). Defaults to empty.
700 pki_audit_signing_cert_path
703 Required for the second step of a stand-alone PKI process. This is the
704 location of the file containing the audit signing certificate (as is‐
705 sued by the external CA). Defaults to empty.
706 pki_sslserver_cert_path
709 Required for the second step of a stand-alone PKI process. This is the
710 location of the file containing the sslserver certificate (as issued by
711 the external CA). Defaults to empty.
712 pki_storage_cert_path
715 [KRA ONLY] Required for the second step of a stand-alone KRA process.
716 This is the location of the file containing the storage certificate (as
717 issued by the external CA). Defaults to empty.
718 pki_subsystem_cert_path
721 Required for the second step of a stand-alone PKI process. This is the
722 location of the file containing the subsystem certificate (as issued by
723 the external CA). Defaults to empty.
724 pki_transport_cert_path
727 [KRA ONLY] Required for the second step of a stand-alone KRA process.
728 This is the location of the file containing the transport certificate
729 (as issued by the external CA). Defaults to empty.
730 KRA PARAMETERS
733 pki_kra_ephemeral_requests
734 Specifies to use ephemeral requests for archivals and retrievals. De‐
735 faults to False.
736 TPS PARAMETERS
739 pki_authdb_basedn
740 Specifies the base DN of TPS authentication database.
741 pki_authdb_hostname
744 Specifies the hostname of TPS authentication database. Defaults to lo‐
745 calhost.
746 pki_authdb_port
749 Specifies the port number of TPS authentication database. Defaults to
750 389.
751 pki_authdb_secure_conn
754 Specifies whether to use a secure connection to TPS authentication
755 database. Defaults to False.
756 pki_enable_server_side_keygen
759 Specifies whether to enable server-side key generation. Defaults to
760 False. The location of the KRA instance should be specified in the
761 pki_kra_uri parameter.
762 pki_ca_uri
765 Specifies the URI of the CA instance used by TPS to create and revoke
766 user certificates. Defaults to the instance in which the TPS is run‐
767 ning.
768 pki_kra_uri
771 Specifies the URI of the KRA instance used by TPS to archive and re‐
772 cover keys. Required if server-side key generation is enabled using
773 the pki_enable_server_side_keygen parameter. Defaults to the instance
774 in which the TPS is running.
775 pki_tks_uri
778 Specifies the URI of the TKS instance used by TPS to generate symmetric
779 keys. Defaults to the instance in which the TPS is running.
780
783 pkispawn(8)
784
787 Ade Lee <alee@redhat.com>.
788
791 Copyright (c) 2012 Red Hat, Inc. This is licensed under the GNU Gen‐
792 eral Public License, version 2 (GPLv2). A copy of this license is
793 available at http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.
794PKI December 13, 2012 pki_default.cfg(5)