dogtagpki

#2826 ClientCertImportCLI.importPKCS7 cannot find cert
Closed: fixed Opened by ftweedal.

Closed: fixed
Reopen Issue

The ClientCertImportCLI.importPKCS7 method imports all certificates
from the PKCS #7 file, then finds one of the imported certs by nickname
to perform other actions such as setting trust args.

JSS/NSS may import a certificate under a nickname other than the requested
nickname. The code handles this fine, but if the preferred nickname was never
used, then the certificate lookup fails and the program crashes with NSS ObjectNotFoundException.

This causes subsequent installation failure (when installing with externally-signed CA).

Metadata Update from @ftweedal:
- Issue assigned to ftweedal

Gerrit review: https://review.gerrithub.io/#/c/380767/

Metadata Update from @ftweedal:
- 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 @edewata:
- Issue priority set to: blocker
- Issue set to the milestone: 10.5

More info from the Gerrit review:

Any idea why the preferred nickname was never used?

I think the current code was assuming the first cert will be the
leaf cert and it will be imported using the preferred nickname.
Your patch assumes that the leaf cert will be the last.

IIRC, according to cfu the order of the certificates in the PKCS #7
is not guaranteed. So we probably will need to do this:

  • sort the certificates based on the subject DNs & issuer DNs (we
    probably can't use buildCertificateChain() since we'd have to
    provide the leaf cert, which we don't have yet at this point)
  • trust the leaf cert with the trust flags provided
  • trust the root cert with CT,C,C

Reading the JSS docs[1] it says that the nickname is ignored if there is no
user certificate, i.e. certificate with corresponding private key. This is
the case here.

[1] https://www-archive.mozilla.org/projects/security/pki/jss/javadoc/org/mozilla/jss/CryptoManager.html#importCertPackage(byte[],%20java.lang.String)

So it looks like this regression was introduced in
47a4e34f8f98249ef0eb6defbaf108220e22a7d0. Previously the PKCS #7
file was broken down into individual certs, each imported using
NSSDatabase.add_cert (which invokes certutil -A).

Metadata Update from @ftweedal:
- Issue priority set to: None (was: blocker)
- Issue set to the milestone: None (was: 10.5)

New gerrit review: https://review.gerrithub.io/#/c/381204/

Metadata Update from @edewata:
- Issue priority set to: blocker
- Issue set to the milestone: 10.5

Pushed to master:

  • https://github.com/dogtagpki/pki/commit/311fe5926de4b7177a2a18821afce7c80a6c2def

Metadata Update from @edewata:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5.0 (was: 10.5)

Metadata Update from @mharmsen:
- Custom field fixedinversion adjusted to pki-core-10.5.0-1.fc27

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/2946

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.
Metadata
None
None
None
Lowest
None
None
None
None
None
None
None
None
pki-core-10.5.0-1.fc27
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.