Bug 1491623
Summary: | pk12util fails to import a pkcs#12 file that contains two certificates with identical nickname | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | German Parente <gparente> |
Component: | nss | Assignee: | Daiki Ueno <dueno> |
Status: | CLOSED ERRATA | QA Contact: | Hubert Kario <hkario> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.4 | CC: | dueno, ekeck, frenaud, gparente, hkario, kengert, pvoborni, rcritten, rrelyea, szidek, tmihinto, tscherf |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | nss-3.34.0-0.1.beta1.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-10 09:46:29 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
German Parente
2017-09-14 09:47:17 UTC
It seems that ipa-cacert-manage renew sometimes leaves the NSSDB with the prev cert and the new cert obtained from renewal (not systematically reproduced). For instance: $ sudo certutil -L -d /etc/pki/pki-tomcat/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca CTu,Cu,Cu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu Here 'caSigningCert cert-pki-ca' appears twice and that will cause an issue during replica install, when custodia retrieves the keys for this cert. Not sure yet if it is a bug in certmonger (should it remove the old cert before adding the new one?) or a NSS issue. On the replica side, when custodia tries to retrieve the cert and key, it performs pk12util -d /etc/pki/pki-tomcat/alias -o <pk12file> -n 'caSigningCert cert-pki-ca' -k /etc/pki/pki-tomcat/alias/pwdfile.txt -w <pk12pwfile> on the master (ie take the cert from PKI nssdb and produce a pk12 file), and the custodia client receives the content from the pk12file and performs pk12util -d <nssdb> -k <nssdbpwdile> -n 'caSigningCert cert-pki-ca' -i <pk12file> -w <pk12pwfile> (ie extract the cert from pk12 file and put it in a temporary NSSDB). The issue can be reproduced manually with pk12util commands. What is strange, is that running the client-side pk12util command twice succeeds. $ sudo pk12util -d /tmp/nssdb/ -i /tmp/ca.p12 -n 'caSigningCert cert-pki-ca' Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: pk12util: PKCS12 decode import bags failed: SEC_ERROR_PKCS12_UNABLE_TO_IMPORT_KEY: Unable to import. Error attempting to import private key. $ sudo pk12util -d /tmp/nssdb/ -i /tmp/ca.p12 -n 'caSigningCert cert-pki-ca' Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: pk12util: PKCS12 IMPORT SUCCESSFUL So there may be an issue as well with pk12util. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:0679 |