After certain alterations, the following was copied from the now defunct ticket PKI TRAC Ticket #1118 - Move 'pkispawn' to a separate package to allow remote access:

• The 'pkispawn' executable will be decoupled into two parts, 'pkispawn' and 'pkideploy' where:

* To prevent any disruption to existing products which integrate it,
  the 'pkispawn' executable will remain the CLI utilized to install
  and configure a PKI instance but will only consist of the portion
  which gathers all of the information for an instance and creates
  the master Python dictionary;  additionally, 'pkispawn' will now
  always perform the generation of the client Admin keys and produce
  a CSR for the Admin certificate.  Since the 'pkispawn' executable
  will now be allowed to be run remotely, it will no longer be
  contained within the 'pki-server' package.  However, it will
  probably need to package the '/etc/pki/default.cfg' file.  Per
  discussions, it was determined that it would be moved to the
  'pki-tools' package, and exist as a dependency of
  the 'pki-server' package.

* The 'pkideploy' executable will always have all of its data obtained
  from the 'pkispawn' executable, and will be responsible for exercising
  the appropriate 'scriptlets'.  Although the 'pkideploy' executable will
  remain a part of the 'pki-server' package, since it is not intended to be
  a directly executed program, it will therefore be located under
  the '/usr/libexec' directory, and will always run with 'root' privilege.

If 'pkispawn' is run on the server, it will gather its information, generate the Admin Certificate Keys and produce a CSR, and send all of this data to the 'pkideploy' executable in order to install and configure a PKI instance. This will be the default case.

Similarly, if 'pkispawn' is run remotely as a client (after the server-side admin has first setup remote access for the client-side admin), it will gather its information, generate Admin Certificate Keys and produce a CSR, prompt for access to the server, and relay this information to the 'pkideploy' executable on the server side. We may want to include something like a "--remote" switch to distinguish whether configuration is on the local host or on a remote host.

In either case, we may simply perform an 'ssh' with the appropriate options to have 'pkispawn' invoke 'pkideploy' with the appropriate data as arguments; it must still be determined what the best approach
should be to return the Administrative Certificate.

Note that the Admin Certificate keys will always be generated on the machine which invokes the 'pkispawn' executable.

This also implies that there will no longer be the notion of an installed PKI instance that has not been configured, so the 'pki_skip_installation' and 'pki_skip_configuration' options and their associated code will need to be removed.

The following requirement was moved into this ticket from PKI TRAC Ticket #1120 - Remove Firefox PKI GUI Configuration Panel Interface:

• add a description to the appropriate man page which describes how to obtain and import an Admin certificate into one's browser

Proposed Milestone: 10.2.2 (per CS Meeting of 09/17/2014)

Per Dogtag 10.2.X meeting of 01/14/2015: Milestone 10.3

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1682

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.