Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Unable to issue certificate on clone with LWCA #2956

Closed
pki-bot opened this issue Oct 3, 2020 · 11 comments
Closed

[RFE] Unable to issue certificate on clone with LWCA #2956

pki-bot opened this issue Oct 3, 2020 · 11 comments

Comments

@pki-bot
Copy link

pki-bot commented Oct 3, 2020

This issue was migrated from Pagure Issue #2836. Originally filed by edewata (@edewata) on 2017-10-18 12:14:36:

  • Closed at 2017-11-15 02:06:51 as wontfix
  • Assigned to nobody

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:

  • Install CA on master.
  • Find the root CA ID:
$ pki -d ~/.dogtag/pki-tomcat/ca/alias -n caadmin -c Secret.123 ca-authority-find
  • Create a lightweight sub CA:
$ pki -d ~/.dogtag/pki-tomcat/ca/alias -n caadmin -c Secret.123 ca-authority-create CN=test --parent <root CA ID>
  • Create CA clone and install CA admin cert on clone
  • On the clone, submit certificate request to the sub CA:
$ pki -c Secret.123 client-cert-request UID=testuser --issuer-id <sub CA ID>
  • On the clone, approve the request:
$ 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:

@pki-bot pki-bot added this to the 10.5.2 milestone Oct 3, 2020
@pki-bot pki-bot closed this as completed Oct 3, 2020
@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from edewata (@edewata) at 2017-10-18 12:58:52

Manual transfer using PKCS 12 file:

  • Export the sub CA cert & key from master:
$ 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
  • Import the sub CA cert & key into clone:
$ pki -d /etc/pki/pki-tomcat/alias/ -c Secret.123 pkcs12-import --pkcs12-file subca.p12 --pkcs12-password Secret.123
  • Restart clone

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from edewata (@edewata) at 2017-10-18 12:58:54

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

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-10-18 19:01:22

Metadata Update from @mharmsen:

  • Issue set to the milestone: 0.0 NEEDS_TRIAGE

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from ftweedal (@frasertweedale) at 2017-10-18 21:28:42

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).

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-10-25 12:12:51

[20171025] edewata, frasertweedale - FUTURE RFE

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-10-25 12:12:52

Metadata Update from @mharmsen:

  • Issue set to the milestone: FUTURE (was: 0.0 NEEDS_TRIAGE)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from ftweedal (@frasertweedale) at 2017-11-15 02:06:52

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.

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from ftweedal (@frasertweedale) at 2017-11-15 02:06:53

Metadata Update from @frasertweedale:

  • Issue close_status updated to: wontfix

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from mharmsen (@mharmsen) at 2017-11-15 11:02:47

Metadata Update from @mharmsen:

  • Issue set to the milestone: 10.5.2 (was: FUTURE)

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from edewata (@edewata) at 2017-11-15 11:29:47

Added a note about this limitation in this page:
http://pki.fedoraproject.org/wiki/PKI_CA_Authority_CLI

@pki-bot
Copy link
Author

pki-bot commented Oct 3, 2020

Comment from ftweedal (@frasertweedale) at 2017-11-16 04:03:15

Thanks @edewata !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant