In many cases one person might be both the installer and the admin. When he runs pkispawn it will install the server, configure the server, and request a certificate for the admin user. As an admin he will likely need to use CLI to do administrative tasks.
Currently to request a certificate pkispawn creates a temporary database and then remove it when everything is done. If the admin later needs to use the CLI, he will need to manually create a new database and import the certificate. To simplify the process, it would be better to keep the database that was originally created to request the certificate.
Here are the proposed changes:
Keep the client database by default. The pki_client_database_purge parameter should be False by default, or be removed altogether.
To simplify things further, by default the client database should be stored in ~/.pki/nssdb. The certificate should have a unique name so it won't conflict with certificates for other instances. This way when using the CLI the admin won't need to specify the database path.
By default the client database password and PKCS #12 password will be made identical to the admin user password, so it's not necessary to specify them in the deployment configuration. If the certificate is to be stored in an existing database or PKCS #12, the pki_client_database_password and pki_client_pkcs12_password parameters can be used to specify their passwords.
The client password files (password.conf and pkcs12_password.conf) should be removed once pkispawn is done. This way it's more secure. If the admin needs to use the certificate database or the PKCS #12 file he would need to supply the password. Since the password files are temporary, the pki_client_password_conf and pki_client_pkcs12_password_conf parameters are not needed, pkispawn can generate temporary file names.
In the future the PKCS #12 file could be made optional once the CLI become mature enough and can provide all functionalities currently provided by Web UI.
We should also consider splitting pkispawn into separate tools for installer and admin in case they are different people. The installer should not need to deal with parameters for admin certificate or passwords.
Discuss this with the PKI team before proceeding with this ticket.
[06/04/2014] - Moving to Milestone 10.3 due to schedule restrictions.
Metadata Update from @edewata: - Issue assigned to mharmsen - Issue set to the milestone: UNTRIAGED
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/1135
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)