1pkispawn(8) PKI Instance Creation Utility pkispawn(8)
2
6 pkispawn - Sets up a PKI subsystem.
7
10 pkispawn -s subsystem -f config_file [-h] [-v]
11
14 Sets up a PKI subsystem (CA, KRA, OCSP, TKS, or TPS) in a Tomcat in‐
15 stance.
16 Note: A 389 Directory Server instance must be configured and running
19 before this script can be run. PKI server requires an internal direc‐
20 tory database. The default configuration assumes a Directory Server
21 instance running on the same machine on port 389. For more information
22 on creating a Directory Server instance, see dscreate(8).
23 An instance can contain multiple subsystems, although it may contain at
26 most one of each type of subsystem on a single machine. So, for exam‐
27 ple, an instance could contain CA and KRA subsystems, but not two CA
28 subsystems. To create an instance with a CA and a KRA, simply run
29 pkispawn twice, with values -s CA and -s KRA respectively.
30 The instances are created based on values for configuration parameters
33 in the default configuration (i.e. /usr/share/pki/server/etc/de‐
34 fault.cfg) and the user-provided configuration file. The user-provided
35 configuration file is read after the default configuration file, so any
36 parameters defined in that file will override parameters in the default
37 configuration file. In general, most users will store only those pa‐
38 rameters which are different from the default configuration in their
39 user-provided configuration file.
40 This configuration file contains parameters that are grouped into sec‐
43 tions. These sections are stacked, so that parameters defined in ear‐
44 lier sections can be overwritten by parameters defined in later sec‐
45 tions. The sections are read in the following order: [DEFAULT], [Tom‐
46 cat], and the subsystem section ([CA], [KRA], [OCSP], [TKS], or [TPS]).
47 This allows the ability to specify parameters to be shared by all sub‐
48 systems in [DEFAULT] or [Tomcat], and system-specific customization.
49 Note: Any non-password related parameter values in the configuration
52 file that needs to contain a % character must be properly escaped. For
53 example, a value of foo%bar would be specified as foo%%bar in the con‐
54 figuration file.
55 At a minimum, the user-defined configuration file must provide some
58 passwords needed for the install. An example configuration file is
59 provided in the EXAMPLES section below. For more information on the
60 default configuration file and the parameters it contains (and can be
61 customized), see pki_default.cfg(5).
62 The pkispawn run creates several different installation files that can
65 be referenced later, if need be:
66 • For Tomcat-based instances, a Tomcat instance is created at
69 /var/lib/pki/pki_instance_name, where pki_instance_name is de‐
70 fined in the configuration file.
71 • A log file of pkispawn operations is written to
73 /var/log/pki/pki-subsystem-spawn.timestamp.log.
74 • A .p12 (PKCS #12) file containing a certificate for a subsys‐
76 tem administrator is stored in pki_client_dir defined in the
77 configuration file.
78 When the utility is done running, the CA can be accessed by pointing a
82 browser to https://hostname:pki_https_port/. The agent pages can be
83 accessed by importing the CA certificate and administrator certificate
84 into the browser.
85 The PKI server instance can also be accessed using the pki command line
88 interface. See pki(1). For more extensive documentation on how to use
89 PKI features, see the Red Hat Certificate System Documentation at
90 https://access.redhat.com/knowledge/docs/Red_Hat_Certificate_System.
91 Instances created using pkispawn can be removed using pkidestroy. See
94 pkidestroy(8).
95
98 -s subsystem
99 Specifies the subsystem to be installed and configured, where sub‐
100 system is CA, KRA, OCSP, TKS, or TPS.
101 -f config_file
104 Specifies the path to the user-defined configuration file.
105 This file contains differences between the default configuration
106 and the custom configuration.
107 --precheck
110 Execute pre-checks and exit.
111 --skip-configuration
114 Run the first step of the installation (i.e. skipping the instance
115 configuration step).
116 --skip-installation
119 Run the second step of the installation (i.e. skipping the instance
120 installation step).
121 -h, --help
124 Prints additional help information.
125 -v
128 Displays verbose information about the installation.
129 This flag can be provided multiple times to increase verbosity.
130 See pkispawn -h for details.
131
134 Separate PKI instances
135 As described above, this version of PKI continues to support separate
136 PKI instances for all subsystems.
137 Separate PKI instances run as a single Java-based Apache Tomcat in‐
140 stance, contain a single PKI subsystem (CA, KRA, OCSP, TKS, or TPS),
141 and must utilize unique ports if co-located on the same machine.
142 Shared PKI instances
145 Additionally, this version of PKI introduces the notion of a shared PKI
146 instance.
147 Shared PKI instances also run as a single Java-based Apache Tomcat in‐
150 stance, but may contain any combination of up to one of each type of
151 PKI subsystem:
152 • CA
155 • TKS
157 • CA, KRA
159 • CA, OCSP
161 • TKS, TPS
163 • CA, KRA, TKS, TPS
165 • CA, KRA, OCSP, TKS, TPS
167 • etc.
169 Shared PKI instances allow all of their subsystems contained within
173 that instance to share the same ports, and must utilize unique ports if
174 more than one shared PKI instance is co-located on the same machine.
175 Semantically, a shared PKI instance that contains a single PKI subsys‐
178 tem is identical to a separate PKI instance.
179
182 If no options are specified, pkispawn will provide an interactive menu
183 to collect the parameters needed to install the Certificate Server in‐
184 stance. Note that only the most basic installation options are pro‐
185 vided. This includes root CA, KRA, OCSP, TKS, and TPS connecting to an
186 existing directory server. More advanced setups such as cloned subsys‐
187 tems, subordinate or externally signed CA, subsystems that connect to
188 the directory server using LDAPS, and subsystems that are customized
189 beyond the options described below require the use of a configuration
190 file with the -f option.
191 The interactive option is most useful for those users getting familiar
194 with Certificate Server. The parameters collected are written to the
195 installation file of the subsystem, which can be found at /etc/syscon‐
196 fig/pki/tomcat/instance_name/subsystem/deployment.cfg.
197 The following parameters are queried interactively during the installa‐
200 tion process.
201 Subsystem Type
204 Subsystem (CA/KRA/OCSP/TKS/TPS):
205 The type of subsystem to be installed.
206 Prompted when the -s option is not specified.
207 The default value chosen is CA.
208 Instance Specific Parameters
211 Instance name:
212 The name of the tomcat instance in which the subsystem is to be in‐
213 stalled. The default value is pki-tomcat.
214 Note: Only one subsystem of a given type (CA, KRA, OCSP, TKS, TPS) can
217 exist within a given instance.
218 HTTP port:
221 The HTTP port of the Tomcat instance. The default value is 8080.
222 Secure HTTP port:
225 The HTTPS port of the Tomcat instance. The default value is 8443.
226 AJP port:
229 The AJP port of the Tomcat instance. The default value is 8009.
230 Management port:
233 The management port of the Tomcat instance. The default value is
234 8005.
235 Note: When deploying a new subsystem into an existing instance,
238 pkispawn will attempt to read the ports from deployment.cfg files
239 stored for previously installed subsystems for this instance. If suc‐
240 cessful, the installer will not prompt for these ports.
241 Administrative User Parameters
244 Username:
245 The username of the administrator of this subsystem. The default
246 value is <ca/kra/ocsp/tks/tps>admin.
247 Password:
250 Password for the administrator user.
251 Import certificate:
254 An optional parameter that can be used to import an already avail‐
255 able CA admin certificate into this instance.
256 Export certificate:
259 Setup the path where the admin certificate of this <subsystem>
260 should be stored.
261 The default value is $HOME/.dogtag/pki-tom‐
262 cat/<ca/kra/ocsp/tks/tps>_admin.cert.
263 Directory Server Parameters
266 Hostname:
267 Hostname of the directory server instance. The default value is
268 the hostname of the system.
269 Use a secure LDAPS connection?
272 Answering yes to this question will cause prompts for Secure LDAPS
273 Port: and Directory Server CA certificate pem file:.
274 Answering no to this question will cause a prompt for LDAP Port.
275 The initial default value for this question is no.
276 Secure LDAPS Port:
279 Secure LDAPS port for the directory server instance. The default
280 value is 636.
281 Directory Server CA certificate PEM file:
284 The fully-qualified path including the filename of the file which
285 contains an exported copy of the Directory Server's CA certificate
286 (e.g. $HOME/dscacert.pem).
287 This file must exist prior to pkispawn being able to utilize it.
288 For details on creation of this file see the EXAMPLES section below
289 entitled Installing PKI Subsystem with Secure LDAP Connection.
290 LDAP Port:
293 LDAP port for the directory server instance. The default value is
294 389.
295 Base DN:
298 The Base DN to be used for the internal database for this subsys‐
299 tem.
300 The default value is o=pki-tomcat-<subsystem>.
301 Bind DN:
304 The bind DN required to connect for the directory server.
305 This user must have sufficient permissions to install the required
306 schema and database.
307 The default value is cn=Directory Manager.
308 Password:
311 Password for the bind DN.
312 Security Domain Parameters
315 Name:
316 The name of the security domain. Required only if installing a root
317 CA.
318 Default value: <DNS domain name> Security Domain.
319 Hostname:
322 The hostname for the security domain CA. Required only for non-CA
323 subsystems.
324 The default value is the hostname of this system.
325 Secure HTTP port:
328 The https port for the security domain. Required only for non-CA
329 subsystems. The default value is 8443.
330 Username:
333 The username of the security domain administrator of the CA.
334 Required only for non-CA subsystems.
335 The default value is caadmin.
336 Password:
339 Password for the security domain administrator. Required for all
340 subsystems that are not root CAs.
341
344 This option is only available when pkispawn is invoked in a non-inter‐
345 active mode. When the --precheck option is provided, a set of basic
346 tests are performed to ensure that the parameters provided to pkispawn
347 are valid and consistent.
348 pkispawn will then exit with an exit code of 0 on success, or 1 on
351 failure. This mode can be used to perform basic tests prior to doing
352 any actual installation of the PKI server instance.
353 Flags are available to disable specific tests. For instance, one might
356 want to disable validation of the credentials for the internal database
357 user if the directory server instance has not yet been created.
358 See pki_default.cfg(5) for more details about available flags.
361
364 pkispawn provides a number of parameters to customize an instance be‐
365 fore it is created. Usually, most other customization can be done af‐
366 ter the server is created. However, sometimes certain types of cus‐
367 tomization need to be done before the server is created, but there are
368 no parameters for that. For example, configuring session timeout,
369 adding CSR extensions, customizing certificate profiles, configuring
370 TLS ciphers, etc. To support such customization, pkispawn provides a
371 two-step installation mode.
372 Generally, instance creation happens in one step (except for the exter‐
375 nal CA case). Internally, the process happens in two stages. In the
376 first stage, pkispawn will install the instance files (e.g. CS.cfg, NSS
377 database, profiles, etc.) in the instance directory and customize them
378 based on pkispawn parameters. In the second stage, pkispawn will start
379 the instance and configure the instance based on the instance configu‐
380 ration files (e.g. initializing database, generating certificates, con‐
381 figuring connectors, etc.). The two-step process allows the process to
382 be stopped after the first stage, allowing further customization to be
383 done before running the second stage.
384 To use two-step installation mode, prepare a normal pkispawn configura‐
387 tion file, then run pkispawn with the --skip-configuration parameter.
388 For example:
389 $ pkispawn -s CA -f myconfig.txt --skip-configuration
392 Then customize the files in the instance directory as needed. Finally,
396 finish the installation by running pkispawn again with the --skip-in‐
397 stallation parameter. For example:
398 $ pkispawn -s CA -f myconfig.txt --skip-installation
401
405 Installing Root CA
406 To install a root CA in a new instance execute the following command:
407 $ pkispawn -s CA -f myconfig.txt
410 where myconfig.txt contains the following text:
414 [DEFAULT]
417 pki_admin_password=Secret.123
418 pki_client_pkcs12_password=Secret.123
419 pki_ds_password=Secret.123
420 Prior to running this command, a Directory Server instance should be
424 created and running. This command assumes that the Directory Server
425 instance is using its default configuration:
426 • Installed on the local machine
429 • Listening on port 389
431 • The user is cn=Directory Manager, with the password specified
433 in pki_ds_password
434 This invocation of pkispawn creates a Tomcat instance containing a CA
438 running on the local machine with secure port 8443 and unsecure port
439 8080. To access this CA, simply point a browser to https://host‐
440 name:8443.
441 The instance name (defined by pki_instance_name) is pki-tomcat, and it
444 is located at /var/lib/pki/pki-tomcat. Logs for the instance are lo‐
445 cated at /var/log/pki/pki-tomcat, and an installation log is written to
446 /var/log/pki/pki-subsystem-spawn.timestamp.log.
447 A PKCS #12 file containing the administrator certificate is created in
450 $HOME/.dogtag/pki-tomcat. This PKCS #12 file uses the password desig‐
451 nated by pki_client_pkcs12_password in the configuration file.
452 To access the agent pages, first import the CA certificate by accessing
455 the CA End Entity Pages and clicking on the Retrieval Tab. Be sure to
456 trust the CA certificate. Then, import the administrator certificate in
457 the PKCS #12 file.
458 Installing Root CA using ECC
461 To install a root CA in a new instance using ECC execute the following
462 command:
463 $ pkispawn -s CA -f myconfig.txt
466 where myconfig.txt contains the following text:
470 [DEFAULT]
473 pki_admin_password=Secret.123
474 pki_admin_key_algorithm=SHA256withEC
475 pki_admin_key_size=nistp256
476 pki_admin_key_type=ecc
477 pki_client_pkcs12_password=Secret.123
478 pki_ds_password=Secret.123
479 pki_sslserver_key_algorithm=SHA256withEC
480 pki_sslserver_key_size=nistp256
481 pki_sslserver_key_type=ecc
482 pki_subsystem_key_algorithm=SHA256withEC
483 pki_subsystem_key_size=nistp256
484 pki_subsystem_key_type=ecc
485 [CA]
487 pki_ca_signing_key_algorithm=SHA256withEC
488 pki_ca_signing_key_size=nistp256
489 pki_ca_signing_key_type=ecc
490 pki_ca_signing_signing_algorithm=SHA256withEC
491 pki_ocsp_signing_key_algorithm=SHA256withEC
492 pki_ocsp_signing_key_size=nistp256
493 pki_ocsp_signing_key_type=ecc
494 pki_ocsp_signing_signing_algorithm=SHA256withEC
495 In order to utilize ECC, the SSL Server and Subsystem key algorithm,
499 key size, and key type should be changed from SHA256withRSA to
500 SHA256withEC, 2048 to nistp256, and rsa to ecc, respectively. To use
501 an ECC admin key size and key type, the values should also be changed
502 from 2048 to nistp256, and rsa to ecc.
503 Additionally, for a CA subsystem, both the CA and OCSP Signing key al‐
506 gorithm, key size, key type, and signing algorithm should be changed
507 from SHA256withRSA to SHA256withEC, 2048 to nistp256, rsa to ecc, and
508 SHA256withRSA to SHA256withEC, respectively.
509 Note: For all PKI subsystems including the CA, ECC is not supported for
512 the corresponding Audit Signing parameters. Similarly, for KRA subsys‐
513 tems, ECC is not supported for either of the corresponding Storage or
514 Transport parameters.
515 Installing KRA, OCSP, TKS, or TPS in Shared Instance
518 For this example, assume that a new CA instance has been installed by
519 executing the following command:
520 $ pkispawn -s CA -f myconfig.txt
523 where myconfig.txt contains the following text:
527 [DEFAULT]
530 pki_admin_password=Secret.123
531 pki_client_pkcs12_password=Secret.123
532 pki_ds_password=Secret.123
533 To install a shared KRA in the same instance used by the CA execute the
537 following command:
538 $ pkispawn -s KRA -f myconfig.txt
541 where myconfig.txt contains the following text:
545 [DEFAULT]
548 pki_admin_password=Secret.123
549 pki_client_database_password=Secret.123
550 pki_client_pkcs12_password=Secret.123
551 pki_ds_password=Secret.123
552 pki_security_domain_password=Secret.123
553 To install a shared OCSP in the same instance used by the CA execute
557 the following command:
558 $ pkispawn -s OCSP -f myconfig.txt
561 where myconfig.txt contains the following text:
565 [DEFAULT]
568 pki_admin_password=Secret.123
569 pki_client_database_password=Secret.123
570 pki_client_pkcs12_password=Secret.123
571 pki_ds_password=Secret.123
572 pki_security_domain_password=Secret.123
573 To install a shared TKS in the same instance used by the CA execute the
577 following command:
578 $ pkispawn -s TKS -f myconfig.txt
581 where myconfig.txt contains the following text:
585 [DEFAULT]
588 pki_admin_password=Secret.123
589 pki_client_database_password=Secret.123
590 pki_client_pkcs12_password=Secret.123
591 pki_ds_password=Secret.123
592 pki_security_domain_password=Secret.123
593 To install a shared TPS in the same instance used by the CA execute the
597 following command:
598 $ pkispawn -s TPS -f myconfig.txt
601 where myconfig.txt contains the following text:
605 [DEFAULT]
608 pki_admin_password=Secret.123
609 pki_client_database_password=Secret.123
610 pki_client_pkcs12_password=Secret.123
611 pki_ds_password=Secret.123
612 pki_security_domain_password=Secret.123
613 [TPS]
615 # Shared TPS instances optionally utilize their shared KRA
616 # for server-side keygen
617 pki_enable_server_side_keygen=True
618 pki_authdb_basedn=dc=example,dc=com
619 Note: For this particular example, the computed default values for a
623 PKI instance name including its ports, URLs, machine names, etc. were
624 utilized as defined in /usr/share/pki/server/etc/default.cfg. Each
625 subsystem in this example will reside under the /var/lib/pki/pki-tomcat
626 instance housed within their own ca, kra, ocsp, tks, and tps subdirec‐
627 tories, utilizing the same default port values of 8080 (http), 8443
628 (https), 8009 (ajp), 8005 (tomcat), using the same computed hostname
629 and URL information, and sharing a single common PKI Administrator Cer‐
630 tificate.
631 The pki_security_domain_password is the admin password of the CA in‐
634 stalled in the same instance. This command should be run after a CA is
635 installed. This installs another subsystem within the same instance us‐
636 ing the certificate generated for the CA administrator for the subsys‐
637 tem's administrator. This allows a user to access both subsystems on
638 the browser with a single administrator certificate. To access the new
639 subsystem's functionality, simply point the browser to https://host‐
640 name:8443 and click the relevant top-level links.
641 To install TPS in a shared instance the following section must be added
644 to myconfig.txt:
645 [TPS]
648 pki_authdb_basedn=dc=example,dc=com
649 TPS requires an authentication database. The pki_authdb_basedn speci‐
653 fies the base DN of the authentication database.
654 TPS also requires that a CA and a TKS subsystems are already installed
657 in the same instance. Since they are in the same instance, a shared
658 secret key will automatically be generated in TKS and imported into
659 TPS.
660 Optionally, server-side key generation can be enabled in TPS by adding
663 the following parameter in [TPS]:
664 pki_enable_server_side_keygen=True
667 Enabling server-side key generation requires that a KRA subsystem is
671 already installed in the same instance.
672 Installing KRA, OCSP, TKS, or TPS in Separate Instance
675 For this example, assume that a new CA instance has been installed by
676 executing the following command:
677 $ pkispawn -s CA -f myconfig.txt
680 where myconfig.txt contains the following text:
684 [DEFAULT]
687 pki_admin_password=Secret.123
688 pki_client_pkcs12_password=Secret.123
689 pki_ds_password=Secret.123
690 # Separated CA instance name and ports
691 pki_instance_name=pki-ca
692 pki_http_port=18080
693 pki_https_port=18443
694 # This Separated CA instance will be its own security domain
695 pki_security_domain_https_port=18443
696 [Tomcat]
698 # Separated CA Tomcat ports
699 pki_ajp_port=18009
700 pki_tomcat_server_port=18005
701 To install a separate KRA which connects to this remote CA execute the
705 following command:
706 $ pkispawn -s KRA -f myconfig.txt
709 where myconfig.txt contains the following text:
713 [DEFAULT]
716 pki_admin_password=Secret.123
717 pki_client_database_password=Secret.123
718 pki_client_pkcs12_password=Secret.123
719 pki_ds_password=Secret.123
720 pki_security_domain_password=Secret.123
721 # Separated KRA instance name and ports
722 pki_instance_name=pki-kra
723 pki_http_port=28080
724 pki_https_port=28443
725 # Separated KRA instance security domain references
726 pki_issuing_ca=https://pki.example.com:18443
727 pki_security_domain_hostname=pki.example.com
728 pki_security_domain_https_port=18443
729 pki_security_domain_user=caadmin
730 [Tomcat]
732 # Separated KRA Tomcat ports
733 pki_ajp_port=28009
734 pki_tomcat_server_port=28005
735 [KRA]
737 # A Separated KRA instance requires its own
738 # PKI Administrator Certificate
739 pki_import_admin_cert=False
740 To install a separate OCSP which connects to this remote CA execute the
744 following command:
745 $ pkispawn -s OCSP -f myconfig.txt
748 where myconfig.txt contains the following text:
752 [DEFAULT]
755 pki_admin_password=Secret.123
756 pki_client_database_password=Secret.123
757 pki_client_pkcs12_password=Secret.123
758 pki_ds_password=Secret.123
759 pki_security_domain_password=Secret.123
760 # Separated OCSP instance name and ports
761 pki_instance_name=pki-ocsp
762 pki_http_port=29080
763 pki_https_port=29443
764 # Separated OCSP instance security domain references
765 pki_issuing_ca=https://pki.example.com:18443
766 pki_security_domain_hostname=pki.example.com
767 pki_security_domain_https_port=18443
768 pki_security_domain_user=caadmin
769 [Tomcat]
771 # Separated OCSP Tomcat ports
772 pki_ajp_port=29009
773 pki_tomcat_server_port=29005
774 [OCSP]
776 # A Separated OCSP instance requires its own
777 # PKI Administrator Certificate
778 pki_import_admin_cert=False
779 To install a separate TKS which connects to this remote CA execute the
783 following command:
784 $ pkispawn -s TKS -f myconfig.txt
787 where myconfig.txt contains the following text:
791 [DEFAULT]
794 pki_admin_password=Secret.123
795 pki_client_database_password=Secret.123
796 pki_client_pkcs12_password=Secret.123
797 pki_ds_password=Secret.123
798 pki_security_domain_password=Secret.123
799 # Separated TKS instance name and ports
800 pki_instance_name=pki-tks
801 pki_http_port=30080
802 pki_https_port=30443
803 # Separated TKS instance security domain references
804 pki_issuing_ca=https://pki.example.com:18443
805 pki_security_domain_hostname=pki.example.com
806 pki_security_domain_https_port=18443
807 pki_security_domain_user=caadmin
808 [Tomcat]
810 # Separated TKS Tomcat ports
811 pki_ajp_port=30009
812 pki_tomcat_server_port=30005
813 [TKS]
815 # A Separated TKS instance requires its own
816 # PKI Administrator Certificate
817 pki_import_admin_cert=False
818 To install a separate TPS which connects to this remote CA execute the
822 following command:
823 $ pkispawn -s TPS -f myconfig.txt
826 where myconfig.txt contains the following text:
830 [DEFAULT]
833 pki_admin_password=Secret.123
834 pki_client_database_password=Secret.123
835 pki_client_pkcs12_password=Secret.123
836 pki_ds_password=Secret.123
837 pki_security_domain_password=Secret.123
838 # Separated TPS instance name and ports
839 pki_instance_name=pki-tps
840 pki_http_port=31080
841 pki_https_port=31443
842 # Separated TPS instance security domain references
843 pki_issuing_ca=https://pki.example.com:18443
844 pki_security_domain_hostname=pki.example.com
845 pki_security_domain_https_port=18443
846 pki_security_domain_user=caadmin
847 [Tomcat]
849 # Separated TPS Tomcat ports
850 pki_ajp_port=31009
851 pki_tomcat_server_port=31005
852 [TPS]
854 # Separated TPS instances require specifying a remote CA
855 pki_ca_uri=https://pki.example.com:18443
856 # Separated TPS instances optionally utilize a remote KRA
857 # for server-side keygen
858 pki_kra_uri=https://pki.example.com:28443
859 pki_enable_server_side_keygen=True
860 pki_authdb_basedn=dc=example,dc=com
861 # Separated TPS instances require specifying a remote TKS
862 pki_tks_uri=https://pki.example.com:30443
863 pki_import_shared_secret=True
864 # A Separated TPS instance requires its own
865 # PKI Administrator Certificate
866 pki_import_admin_cert=False
867 Note: For this particular example, besides passwords, sample values
871 were also utilized for PKI instance names, ports, URLs, machine names,
872 etc. Under no circumstances should these demonstrative values be con‐
873 strued to be required literal values.
874 A remote CA is one where the CA resides in another PKI server instance,
877 either on the local machine or a remote machine. In this case, mycon‐
878 fig.txt must specify the connection information for the remote CA and
879 the information about the security domain (the trusted collection of
880 subsystems within an instance).
881 The subsystem section is [KRA], [OCSP], [TKS], or [TPS]. This example
884 assumes that the specified CA hosts the security domain. The CA must
885 be running and accessible.
886 A new administrator certificate is generated for the new subsystem and
889 stored in a PKCS #12 file in $HOME/.dogtag/pki_instance_name.
890 As in a shared instance, to install TPS in a separate instance the au‐
893 thentication database must be specified in the [TPS] section, and op‐
894 tionally the server-side key generation can be enabled. If the CA,
895 KRA, or TKS subsystems required by TPS are running on a remote instance
896 the following parameters must be added into the [TPS] section to spec‐
897 ify their locations:
898 pki_ca_uri=https://<ca_hostname>:<ca_https_port>
901 pki_kra_uri=https://<kra_hostname>:<kra_https_port>
902 pki_tks_uri=https://<tks_hostname>:<tks_https_port>
903 If TPS and TKS are installed on separate instances the shared secret
907 key should be imported over the wire between the TKS and TPS automati‐
908 cally.
909 If the automated procedure fails for any unlikely reason the following
912 manual procedure will serve as a fallback. The key needs to be created
913 on the TKS side and imported into the TPS side in this case.
914 Generate the shared secret key (if needed) in TKS with the following
917 command:
918 $ tkstool -T -d /var/lib/pki/pki-tomcat/alias -n sharedSecret
921 Verify the shared secret key in TKS with the following command:
925 $ tkstool -L -d /var/lib/pki/pki-tomcat/alias
928 Once TPS is installed, shutdown TPS instance, then import the shared
932 secret key into TPS with the following command:
933 $ tkstool -I -d /var/lib/pki/pki-tomcat/alias -n sharedSecret
936 Verify the shared secret key in TPS with the following command:
940 $ tkstool -L -d /var/lib/pki/pki-tomcat/alias
943 The shared secret key nickname should be stored in the following prop‐
947 erty in the TPS's CS.cfg:
948 conn.tks1.tksSharedSymKeyName=sharedSecret
951 Finally, restart the TPS instance.
955 Installing CA, KRA, OCSP, TKS, or TPS using HSM
958 This section provides sample myconfig.txt files when a Hardware Secu‐
959 rity Module (HSM) is being utilized in a shared PKI instance.
960 For this example, assume that a new CA instance has been installed by
963 executing the following command:
964 $ pkispawn -s CA -f myconfig.txt
967 where myconfig.txt contains the following text:
971 [DEFAULT]
974 pki_admin_password=Secret.123
975 pki_client_pkcs12_password=Secret.123
976 pki_ds_password=Secret.123
977 # Provide HSM parameters
978 pki_hsm_enable=True
979 pki_hsm_libfile=<hsm_libfile>
980 pki_hsm_modulename=<hsm_modulename>
981 pki_token_name=<hsm_token_name>
982 pki_token_password=<pki_token_password>
983 # Provide PKI-specific HSM token names
984 pki_audit_signing_token=<hsm_token_name>
985 pki_sslserver_token=<hsm_token_name>
986 pki_subsystem_token=<hsm_token_name>
987 [CA]
989 # Provide CA-specific HSM token names
990 pki_ca_signing_token=<hsm_token_name>
991 pki_ocsp_signing_token=<hsm_token_name>
992 To install a shared KRA in the same instance used by the CA execute the
996 following command:
997 $ pkispawn -s KRA -f myconfig.txt
1000 where myconfig.txt contains the following text:
1004 [DEFAULT]
1007 pki_admin_password=Secret.123
1008 pki_client_database_password=Secret.123
1009 pki_client_pkcs12_password=Secret.123
1010 pki_ds_password=Secret.123
1011 pki_security_domain_password=Secret.123
1012 # Provide HSM parameters
1013 pki_hsm_enable=True
1014 pki_hsm_libfile=<hsm_libfile>
1015 pki_hsm_modulename=<hsm_modulename>
1016 pki_token_name=<hsm_token_name>
1017 pki_token_password=<pki_token_password>
1018 # Provide PKI-specific HSM token names
1019 pki_audit_signing_token=<hsm_token_name>
1020 pki_sslserver_token=<hsm_token_name>
1021 pki_subsystem_token=<hsm_token_name>
1022 [KRA]
1024 # Provide KRA-specific HSM token names
1025 pki_storage_token=<hsm_token_name>
1026 pki_transport_token=<hsm_token_name>
1027 To install a shared OCSP in the same instance used by the CA execute
1031 the following command:
1032 $ pkispawn -s OCSP -f myconfig.txt
1035 where myconfig.txt contains the following text:
1039 [DEFAULT]
1042 pki_admin_password=Secret.123
1043 pki_client_database_password=Secret.123
1044 pki_client_pkcs12_password=Secret.123
1045 pki_ds_password=Secret.123
1046 pki_security_domain_password=Secret.123
1047 # Provide HSM parameters
1048 pki_hsm_enable=True
1049 pki_hsm_libfile=<hsm_libfile>
1050 pki_hsm_modulename=<hsm_modulename>
1051 pki_token_name=<hsm_token_name>
1052 pki_token_password=<pki_token_password>
1053 # Provide PKI-specific HSM token names
1054 pki_audit_signing_token=<hsm_token_name>
1055 pki_sslserver_token=<hsm_token_name>
1056 pki_subsystem_token=<hsm_token_name>
1057 [OCSP]
1059 # Provide OCSP-specific HSM token names
1060 pki_ocsp_signing_token=<hsm_token_name>
1061 To install a shared TKS in the same instance used by the CA execute the
1065 following command:
1066 $ pkispawn -s TKS -f myconfig.txt
1069 where myconfig.txt contains the following text:
1073 [DEFAULT]
1076 pki_admin_password=Secret.123
1077 pki_client_database_password=Secret.123
1078 pki_client_pkcs12_password=Secret.123
1079 pki_ds_password=Secret.123
1080 pki_security_domain_password=Secret.123
1081 # Provide HSM parameters
1082 pki_hsm_enable=True
1083 pki_hsm_libfile=<hsm_libfile>
1084 pki_hsm_modulename=<hsm_modulename>
1085 pki_token_name=<hsm_token_name>
1086 pki_token_password=<pki_token_password>
1087 # Provide PKI-specific HSM token names
1088 pki_audit_signing_token=<hsm_token_name>
1089 pki_sslserver_token=<hsm_token_name>
1090 pki_subsystem_token=<hsm_token_name>
1091 To install a shared TPS in the same instance used by the CA execute the
1095 following command:
1096 $ pkispawn -s TPS -f myconfig.txt
1099 where myconfig.txt contains the following text:
1103 [DEFAULT]
1106 pki_admin_password=Secret.123
1107 pki_client_database_password=Secret.123
1108 pki_client_pkcs12_password=Secret.123
1109 pki_ds_password=Secret.123
1110 pki_security_domain_password=Secret.123
1111 # Provide HSM parameters
1112 pki_hsm_enable=True
1113 pki_hsm_libfile=<hsm_libfile>
1114 pki_hsm_modulename=<hsm_modulename>
1115 pki_token_name=<hsm_token_name>
1116 pki_token_password=<pki_token_password>
1117 # Provide PKI-specific HSM token names
1118 pki_audit_signing_token=<hsm_token_name>
1119 pki_sslserver_token=<hsm_token_name>
1120 pki_subsystem_token=<hsm_token_name>
1121 [TPS]
1123 # Shared TPS instances optionally utilize their shared KRA
1124 # for server-side keygen
1125 pki_enable_server_side_keygen=True
1126 pki_authdb_basedn=dc=example,dc=com
1127 Important: Since HSM keys are stored in the HSM, they cannot be backed
1131 up, moved, or copied to a PKCS #12 file. For example, if pki_hsm_en‐
1132 able is set to True, pki_backup_keys should be set to False and
1133 pki_backup_password should be left unset (the default values in
1134 /usr/share/pki/server/etc/default.cfg). Similarly, for the case of
1135 clones using an HSM, this means that the HSM keys must be shared be‐
1136 tween the master and its clones. Therefore, if pki_hsm_enable is set
1137 to True, both pki_clone_pkcs12_path and pki_clone_pkcs12_password
1138 should be left unset (the default values in
1139 /usr/share/pki/server/etc/default.cfg). Failure to comply with these
1140 rules will result in pkispawn reporting an appropriate error and exit‐
1141 ing.
1142 Installing CA Clone
1145 To install a CA clone execute the following command:
1146 $ pkispawn -s CA -f myconfig.txt
1149 where myconfig.txt contains the following text:
1153 [DEFAULT]
1156 pki_admin_password=Secret.123
1157 pki_client_database_password=Secret.123
1158 pki_client_pkcs12_password=Secret.123
1159 pki_ds_password=Secret.123
1160 pki_security_domain_password=Secret.123
1161 pki_security_domain_hostname=<master_ca_hostname>
1162 pki_security_domain_https_port=<master_ca_https_port>
1163 pki_security_domain_user=caadmin
1164 pki_security_domain_post_login_sleep_seconds=5
1165 [Tomcat]
1167 pki_clone=True
1168 pki_clone_pkcs12_password=Secret.123
1169 pki_clone_pkcs12_path=<path_to_pkcs12_file>
1170 pki_clone_replicate_schema=True
1171 pki_clone_uri=https://<master_ca_hostname>:<master_ca_https_port>
1172 A cloned CA is a CA which uses the same signing, OCSP signing, and au‐
1176 dit signing certificates as the master CA, but issues certificates
1177 within a different serial number range. It has its own internal data‐
1178 base -- separate from the master CA database -- but using the same base
1179 DN, that keeps in sync with the master CA through replication agree‐
1180 ments between the databases. This is very useful for load sharing and
1181 disaster recovery. To create a clone, the myconfig.txt uses pkiclone*
1182 parameters in its [Tomcat] section which identify the original CA to
1183 use as a master template. Additionally, it connects to the master CA
1184 as a remote CA and uses its security domain.
1185 Before the clone can be generated, the Directory Server must be created
1188 that is separate from the master CA's Directory Server. The example
1189 assumes that the master CA and cloned CA are on different machines, and
1190 that their Directory Servers are on port 389.
1191 In addition, since this example does not utilize an HSM, the master's
1194 system certs and keys have been stored in a PKCS #12 file that is
1195 copied over to the clone subsystem in the location specified in
1196 <path_to_pkcs12_file>. This file needs to be readable by the user the
1197 Certificate Server runs as (by default, pkiuser) and be given the
1198 SELinux context pki_tomcat_cert_t.
1199 The master's system certificates can be exported to a PKCS#12 file when
1202 the master is installed if the parameter pki_backup_keys is set to True
1203 and the pki_backup_password is set. The PKCS#12 file is then found un‐
1204 der /var/lib/pki/<instance_name>/alias. Alternatively, the PKCS#12
1205 file can be generated at any time post-installation using PKCS12Export.
1206 The pki_security_domain_post_login_sleep_seconds config specifies sleep
1209 duration after logging into a security domain, to allow the security
1210 domain session data to be replicated to subsystems on other hosts. It
1211 is optional and defaults to 5 seconds.
1212 An example invocation showing the export of the system certificates and
1215 keys, copying the keys to the replica subsystem, and setting the rele‐
1216 vant SELinux and file permissions is shown below. pwfile is a text
1217 file containing the password for the masters NSS DB (found in
1218 /etc/pki/instance_name/password.conf). pkcs12_password_file is a text
1219 file containing the password selected for the generated PKCS12 file.
1220 master# PKCS12Export -d /etc/pki/pki-tomcat/alias -p pwfile \
1223 -w pkcs12_password_file -o backup_keys.p12
1224 master# scp backup_keys.p12 clone:/backup_keys.p12
1225 clone# chown pkiuser: /backup_keys.p12
1227 clone# semanage -a -t pki_tomcat_cert_t /backup_keys.p12
1228 Note: From Dogtag 10.3, a slightly different mechanism has been pro‐
1232 vided to create and specify the required PKCS#12 file to the clone sub‐
1233 system. This new method is provided in addition to the method above,
1234 but will become the preferred method in future releases.
1235 This method can be used if both master and clone are 10.3 or above.
1238 To export the required keys from the master, use the pki-server command
1241 line tool.
1242 master# pki-server ca-clone-prepare -i pki-tomcat \
1245 --pkcs12-file backup_keys.p12 \
1246 --pkcs12-password Secret123
1247 master# scp backup_keys.p12 clone:/backup_keys.p12
1249 master# scp /etc/pki/pki-tomcat/external_certs.conf \
1250 clone:/external_certs.conf
1251 The external_certs.conf file contains information about third party
1255 certificates that were added to the master's certificate database using
1256 the pki-server command. The certificates themselves are stored in the
1257 backup_keys.p12 file. If there are no third-party certifcates that have
1258 been added, then the external_certs.conf file may not exist and should
1259 be ignored.
1260 The two files (backup_keys.p12 and external_certs.conf) are specified
1263 to pkispawn as below.
1264 [DEFAULT]
1267 pki_admin_password=Secret.123
1268 pki_client_database_password=Secret.123
1269 pki_client_pkcs12_password=Secret.123
1270 pki_ds_password=Secret.123
1271 pki_security_domain_password=Secret.123
1272 pki_security_domain_hostname=<master_ca_hostname>
1273 pki_security_domain_https_port=<master_ca_https_port>
1274 pki_security_domain_user=caadmin
1275 [Tomcat]
1277 pki_server_pkcs12_path=<path to pkcs12 file>
1278 pki_server_pkcs12_password=Secret.123
1279 pki_server_external_certs_path=<path to external_certs.conf file>
1280 pki_clone=True
1281 pki_clone_replicate_schema=True
1282 pki_clone_uri=https://<master_ca_hostname>:<master_ca_https_port>
1283 Note that the previous p12 parameters (pki_clonepkcs12*) are no longer
1287 needed, and will be ignored.
1288 Note: One current cloning anomaly to mention is the following scenario:
1291 1. Create a clone of a CA or of any other subsystem.
1294 2. Remove that just created clone.
1296 3. Immediately attempt the exact same clone again, in place of
1298 the recently destroyed instance. Before recreating this
1299 clone, make sure the pki_ds_remove_data=True is used in
1300 the clone's deployment config file. This will remove the
1301 old data from the previous clone.
1302 Here the Director Server instance may have worked itself in into a
1306 state where it no longer accepts connections, aborting the clone con‐
1307 figuration quickly.
1308 The fix to this is to simply restart the Directory Server instance be‐
1311 fore creating the clone for the second time. After restarting the Di‐
1312 rectory Server it should be possible to create the mentioned clone in‐
1313 stance.
1314 Installing KRA or TKS Clone
1317 To install a KRA or TKS (OCSP and TPS unsupported as of now) execute
1318 the following command:
1319 $ pkispawn -s <subsystem> -f myconfig.txt
1322 where subsystem is KRA or TKS and myconfig.txt contains the following
1326 text:
1327 [DEFAULT]
1330 pki_admin_password=Secret.123
1331 pki_client_database_password=Secret.123
1332 pki_client_pkcs12_password=Secret.123
1333 pki_ds_password=Secret.123
1334 pki_security_domain_password=Secret.123
1335 pki_security_domain_hostname=<master_ca_hostname>
1336 pki_security_domain_https_port=<master_ca_https_port>
1337 pki_security_domain_user=caadmin
1338 [Tomcat]
1340 pki_clone=True
1341 pki_clone_pkcs12_password=Secret.123
1342 pki_clone_pkcs12_path=<path_to_pkcs12_file>
1343 pki_clone_replicate_schema=True
1344 pki_clone_uri=https://<master_subsystem_host>:<master_subsystem_https_port>
1345 pki_issuing_ca=https://<ca_hostname>:<ca_https_port>
1346 As with a CA clone, a KRA or TKS clone uses the same certificates and
1350 basic configuration as the original subsystem. The configuration
1351 points to the original subsystem to copy its configuration. This exam‐
1352 ple also assumes that the CA is on a remote machine and specifies the
1353 CA and security domain information.
1354 The parameter pki_clone_uri should be modified to point to the required
1357 master (KRA or TKS).
1358 As of 10.3, a slightly different mechanism has been introduced to gen‐
1361 erate and specify the PKCS#12 file and any third-party certificates.
1362 See the Installing CA Clone section for details.
1363 Installing CA Clone on the Same Host
1366 For testing purposes, it is useful to configure cloned CAs which exist
1367 (with their internal databases) on the same host as the master CA. To
1368 configure the cloned CA execute the following command:
1369 $ pkispawn -s CA -f myconfig.txt
1372 where myconfig.txt contains the following text:
1376 [DEFAULT]
1379 pki_admin_password=Secret123
1380 pki_client_database_password=Secret123
1381 pki_client_pkcs12_password=Secret123
1382 pki_ds_password=Secret123
1383 pki_ds_ldap_port=<unique port different from master>
1384 pki_ds_ldaps_port=<unique port different from master>
1385 pki_http_port=<unique port different from master>
1386 pki_https_port=<unique port different from master>
1387 pki_instance_name=<unique name different from master>
1388 pki_security_domain_hostname=<master_ca_hostname>
1389 pki_security_domain_https_port=<master_ca_https_port>
1390 pki_security_domain_password=Secret123
1391 [Tomcat]
1393 pki_ajp_port=<unique port different from master>
1394 pki_clone=True
1395 pki_clone_pkcs12_password=Secret123
1396 pki_clone_pkcs12_path=<path_to_pkcs12_file>
1397 pki_clone_uri=https://<master_ca_hostname>:<master_ca_https_port>
1398 pki_tomcat_server_port=<unique port different from master>
1399 [CA]
1401 pki_ds_base_dn=<identical value as master>
1402 pki_ds_database=<identical value as master>
1403 In this case, because both CA Tomcat instances are on the same host,
1407 they must have distinct ports. Similarly, each CA must use a distinct
1408 directory server instance for its internal database. Like the Tomcat
1409 instances, these are distinguished by distinct ports. The suffix being
1410 replicated (pki_ds_base), however, must be the same for both master and
1411 clone.
1412 Installing Subordinate CA in Existing Security Domain
1415 To install a subordinate CA in an existing security domain execute the
1416 following command:
1417 $ pkispawn -s CA -f myconfig.txt
1420 where myconfig.txt contains the following text:
1424 [DEFAULT]
1427 pki_admin_password=Secret.123
1428 pki_client_database_password=Secret.123
1429 pki_client_pkcs12_password=Secret.123
1430 pki_ds_password=Secret.123
1431 pki_security_domain_password=Secret.123
1432 pki_security_domain_hostname=<security_domain_ca_hostname>
1433 pki_security_domain_https_port=<security_domain_ca_https_port>
1434 pki_security_domain_user=caadmin
1435 [CA]
1437 pki_subordinate=True
1438 pki_issuing_ca=https://<master_ca_hostname>:<master_ca_https_port>
1439 pki_ca_signing_subject_dn=cn=CA Subordinate Signing,o=example.com
1440 A sub-CA derives its certificate configuration -- such as allowed ex‐
1444 tensions and validity periods -- from a superior or root CA. Other‐
1445 wise, the configuration of the CA is independent of the root CA, so it
1446 is its own instance rather than a clone. A sub-CA is configured using
1447 the pki_subordinate parameter and a pointer to the CA which issues the
1448 sub-CA's certificates.
1449 Note: The value of pki_ca_signing_subject_dn of a subordinate CA should
1452 be different from the root CA's signing subject DN.
1453 Installing Subordinate CA in New Security Domain
1456 To install a subordinate CA in a new security domain execute the fol‐
1457 lowing command:
1458 $ pkispawn -s CA -f myconfig.txt
1461 where myconfig.txt contains the following text:
1465 [DEFAULT]
1468 pki_admin_password=Secret.123
1469 pki_client_database_password=Secret.123
1470 pki_client_pkcs12_password=Secret.123
1471 pki_ds_password=Secret.123
1472 pki_security_domain_password=Secret.123
1473 pki_security_domain_hostname=<master CA security domain hostname>
1474 pki_security_domain_https_port=<master CA security domain https port>
1475 pki_security_domain_user=caadmin
1476 [CA]
1478 pki_subordinate=True
1479 pki_issuing_ca=https://<master_ca_hostname>:<master_ca_https_port>
1480 pki_ca_signing_subject_dn=cn=CA Subordinate Signing,o=example.com
1481 pki_subordinate_create_new_security_domain=True
1482 pki_subordinate_security_domain_name=Subordinate CA Security Domain
1483 In this section, the subordinate CA logs onto and registers with the
1487 security domain CA (using parameters pki_security_domain_hostname,
1488 pki_security_domain_user and pki_security_domain_password) as in the
1489 previous section, but also creates and hosts a new security domain. To
1490 do this, pki_subordinate_create_new_security_domain must be set to
1491 True. The subordinate CA security domain name can also be specified by
1492 specifying a value for pki_subordinate_security_domain_name.
1493 Note: The value of pki_ca_signing_subject_dn of a subordinate CA should
1496 be different from the root CA's signing subject DN.
1497 Installing Externally-Signed CA
1500 To install an externally signed CA execute the following command:
1501 $ pkispawn -s CA -f myconfig.txt
1504 This is a two-step process.
1508 In the first step, a certificate signing request (CSR) is generated for
1511 the signing certificate and myconfig.txt contains the following text:
1512 [DEFAULT]
1515 pki_admin_password=Secret.123
1516 pki_client_database_password=Secret.123
1517 pki_client_pkcs12_password=Secret.123
1518 pki_ds_password=Secret.123
1519 pki_security_domain_password=Secret.123
1520 [CA]
1522 pki_external=True
1523 pki_ca_signing_csr_path=/tmp/ca_signing.csr
1524 pki_ca_signing_subject_dn=cn=CA Signing,ou=External,o=example.com
1525 The CSR is written to pki_ca_signing_csr_path. The pki_ca_signing_sub‐
1529 ject_dn should be different from the subject DN of the external CA that
1530 is signing the request. The pki_ca_signing_subject_dn parameter can be
1531 used to specify the signing certificate's subject DN.
1532 The CSR is then submitted to the external CA, and the resulting cer‐
1535 tificate and certificate chain are saved to files on the system.
1536 In the second step, the configuration file has been modified to install
1539 the issued certificates. In place of the original CSR, the configura‐
1540 tion file now points to the issued CA certificate and certificate
1541 chain. There is also a flag to indicate that this completes the in‐
1542 stallation process (pki_external_step_two).
1543 [DEFAULT]
1546 pki_admin_password=Secret.123
1547 pki_client_database_password=Secret.123
1548 pki_client_pkcs12_password=Secret.123
1549 pki_ds_password=Secret.123
1550 pki_security_domain_password=Secret.123
1551 [CA]
1553 pki_external=True
1554 pki_external_step_two=True
1555 pki_cert_chain_path=/tmp/ca_cert_chain.cert
1556 pki_ca_signing_cert_path=/tmp/ca_signing.cert
1557 pki_ca_signing_subject_dn=cn=CA Signing Certificate,ou=External,o=example.com
1558 Then, the pkispawn command is run again:
1562 $ pkispawn -s CA -f myconfig.txt
1565 Installing PKI Subsystem with Secure LDAP Connection
1569 There are three scenarios in which a PKI subsystem (e.g. a CA) needs to
1570 communicate securely via LDAPS with a directory server:
1571 Scenario 1: A directory server exists which is already running LDAPS
1574 using a CA certificate that has been issued by some other CA. For this
1575 scenario, the CA certificate must be made available via a PEM file
1576 (e.g. $HOME/dscacert.pem) prior to running pkispawn such that the new
1577 CA may be installed and configured to communicate with this directory
1578 server using LDAPS.
1579 Scenario 2: A directory server exists which is currently running LDAP.
1582 Once a CA has been created, there is a desire to use its CA certificate
1583 to issue an SSL certificate for this directory server so that this CA
1584 and this directory server can communicate via LDAPS. For this sce‐
1585 nario, since there is no need to communicate securely during the
1586 pkispawn installation/configuration, simply use pkispawn to install and
1587 configure the CA using the LDAP port of the directory server, issue an
1588 SSL certificate from this CA for the directory server, and then recon‐
1589 figure the CA and directory server to communicate with each other via
1590 LDAPS.
1591 Scenario 3: Similar to the previous scenario, a directory server exists
1594 which is currently running LDAP, and the desire is to create a CA and
1595 use it to establish LDAPS communications between this CA and this di‐
1596 rectory server. However, for this scenario, there is a need for the CA
1597 and the directory server to communicate securely during pkispawn in‐
1598 stallation and configuration. For this to succeed, the directory
1599 server must generate a temporary self-signed certificate which then
1600 must be made available via a PEM file (e.g. $HOME/dscacert.pem) prior
1601 to running pkispawn. Once the CA has been created, swap things out to
1602 reconfigure the CA and directory server to utilize LDAPS through the
1603 desired certificates.
1604 Set up a Directory Server instance with a self-signed CA certificate
1607 (see dscreate(8)), then export the certificate into a PEM file
1608 Once the self-signed CA certificate is obtained, add the following pa‐
1611 rameters into the [DEFAULT] section in myconfig.txt:
1612 pki_ds_secure_connection=True
1615 pki_ds_secure_connection_ca_pem_file=$HOME/dscacert.pem
1616 Then execute pkispawn to create the CA subsystem.
1620 Managing PKI instance
1623 To start a PKI instance named <pki_instance_name>:
1624 $ systemctl start pki-tomcatd@<pki_instance_name>.service
1627 To stop a PKI instance named <pki_instance_name>:
1631 $ systemctl stop pki-tomcatd@<pki_instance_name>.service
1634 To restart a PKI instance named <pki_instance_name>:
1638 $ systemctl restart pki-tomcatd@<pki_instance_name>.service
1641 To obtain the status of a PKI instance named <pki_instance_name>:
1645 $ systemctl status pki-tomcatd@<pki_instance_name>.service
1648 To obtain a detailed status of a Tomcat PKI instance named <pki_in‐
1652 stance_name>:
1653 $ pki-server status <pki_instance_name>
1656 To list all available PKI instances installed on a system:
1660 $ pki-server instance-find
1663
1667 pkidestroy(8)
1668 pki_default.cfg(5)
1669 pki(1)
1670 dscreate(8)
1671
1674 Ade Lee <alee@redhat.com> and Dinesh Prasanth M K <dmoluguw@redhat.com>
1675
1678 Copyright (c) 2020 Red Hat, Inc. This is licensed under the GNU Gen‐
1679 eral Public License, version 2 (GPLv2). A copy of this license is
1680 available at http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt.
1681PKI September 30, 2020 pkispawn(8)