In non-IPA environment, issuing a certificate on clone with lightweight sub CA does not work because the sub CA certificate does not automatically get transferred to the clone.
Steps to reproduce:
$ pki -d ~/.dogtag/pki-tomcat/ca/alias -n caadmin -c Secret.123 ca-authority-find
$ pki -d ~/.dogtag/pki-tomcat/ca/alias -n caadmin -c Secret.123 ca-authority-create CN=test --parent <root CA ID>
$ pki -c Secret.123 client-cert-request UID=testuser --issuer-id <sub CA ID>
$ pki -c Secret.123 -n caadmin ca-cert-request-review <request ID> --action approve
Actual result: The approval will fail with the following message:
PKIException: com.netscape.certsrv.base.ServiceUnavailableException.<init>(com.netscape.certsrv.base.PKIException$Data)
Expected result: The approval should succeed. If it requires additional manual process, there should be a proper documentation for that.
Note: The NSS database on master has the sub CA certificate, but the clone does not. Ideally it should have been transferred automatically to the clone.
$ certutil -L -d /etc/pki/pki-tomcat/alias ca_signing e4b98e40-4b66-40ee-addd-bc4202b5a107 u,u,u
See also:
Manual transfer using PKCS #12 file:
$ pki -d /etc/pki/pki-tomcat/alias/ -c Secret.123 pkcs12-cert-add "ca_signing e4b98e40-4b66-40ee-addd-bc4202b5a107" --pkcs12-file subca.p12 --pkcs12-password Secret.123
$ pki -d /etc/pki/pki-tomcat/alias/ -c Secret.123 pkcs12-import --pkcs12-file subca.p12 --pkcs12-password Secret.123
Metadata Update from @edewata: - Custom field component adjusted to None - Custom field feature adjusted to None - Custom field origin adjusted to None - Custom field proposedmilestone adjusted to None - Custom field proposedpriority adjusted to None - Custom field reviewer adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
Metadata Update from @mharmsen: - Issue set to the milestone: 0.0 NEEDS_TRIAGE
This is not a bug but an RFE. With IPA we configure Dogtag to use custodia to retrieve the LWCA signing key. The Dogtag team made a conscious decision to avoid transferring the keys through LDAP, even in encrypted form.
So essentially this ticket would be about revisiting how we want LWCA key replication to occur in non-IPA PKI deployments (or asking the question again about whether we want to support this at all, outside of IPA).
[20171025] edewata, ftweedal - FUTURE RFE
Metadata Update from @mharmsen: - Issue set to the milestone: FUTURE (was: 0.0 NEEDS_TRIAGE)
FUTURE usually means NEVER, so I'm going to close this WONTFIX. In the IPA context (which is the only context in which we currently support lightweight CAs) the key replication gets configured. For other contexts, the bits you need are there and you can build it yourself.
So I'm going to close this WONTFIX. We can reopen if someone is really kicking and screaming for this.
Metadata Update from @ftweedal: - Issue close_status updated to: wontfix
Metadata Update from @mharmsen: - Issue set to the milestone: 10.5.2 (was: FUTURE)
Added a note about this limitation in this page: http://pki.fedoraproject.org/wiki/PKI_CA_Authority_CLI
Thanks @edewata !
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/2956
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.