When the KRA is in keywrap (ie. not encrypt) mode, when a key is recovered from the KRA using the UI, the resulting pk12 file can be downloaded, but cannot be viewed in firefox.
The popup in which the password is entered reports that the contents are "invalid or corrupted". The downloaded p12 file on the other hand appears to be fine in that it: --- can be imported into firefox and used for clinet auth --- can be imported into an nss db and used for client auth -- has the same keyid as in the original certdb where it was created.
So, we're pretty sure the key retrieved is correct and valid, it just does not get viewed by firfox on the retrieval UI page. Interestingly, though,, this problem does nor arise when the KRA is in encrypted mode.
Are you sure this is Firefox and not gcr-viewer? The "View file" option actually invokes the /usr/bin/gcr-viewer; the behaviour and error message described above match what gcr-viewer does.
gcr-viewer
/usr/bin/gcr-viewer
Metadata Update from @ftweedal: - Custom field component adjusted to General - Custom field feature adjusted to '' - Custom field origin adjusted to Community - Custom field proposedmilestone adjusted to '' - Custom field proposedpriority adjusted to '' - Custom field reviewer adjusted to '' - Custom field type adjusted to defect - Custom field version adjusted to ''
You could be correct about the viewere, we just reported what was said by the little box the firefox popped up to view the p12 file. The hsm case is more troubling of course, where the kra crashes.
If this is gcr-viewer as I suspect, try downloading the file and then invoking gcr-viewer from a terminal. I get the following console output when I enter the passphrase (coincident with the error message in UI, as described above):
[dhcp-40-8:~/scratch] ftweedal% gcr-viewer getPk12.p12 p11-kit: softhsm: module failed to initialize, skipping: Internal error ** Message: unsupported or invalid cipher: 1.2.840.113549.1.5.13
1.2.840.113549.1.5.13 is PBES2. I think this is a limitation in the GNOME crypto libs, therefore not a bug in Dogtag.
1.2.840.113549.1.5.13
Note that it still works for encrypt/decrypt mode because that path has not been updated to produce AES-encrypted PKCS #12 files yet (https://pagure.io/dogtagpki/issue/2664).
After discussion with alee, closing invalid.
Metadata Update from @ftweedal: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
Metadata Update from @mharmsen: - Issue set to the milestone: 0.0 NEEDS_TRIAGE
A separate documentation bug has been filed for this issue.
Metadata Update from @mharmsen: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1460026 - Issue set to the milestone: 10.4.8 (was: 0.0 NEEDS_TRIAGE)
Metadata Update from @mharmsen: - Custom field cc adjusted to vakwetu@redhat.com,jmagne@redhat.com - Issue assigned to ftweedal
Metadata Update from @mharmsen: - Issue priority set to: blocker
Metadata Update from @mharmsen: - Issue priority set to: critical (was: blocker)
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/2847
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.
Login to comment on this ticket.