Hide Forgot
Description of problem: If the CA signing cert does not have the Subject Key Identifier extension, issuance of certificates fails. Although such a CA certificate is not compliant with RFC 5280, this does happen in the wild, and we previously handled this case by computing the SHA-1 digest of the signing key as a last resort. This behaviour was broken in upstream commit 3c43b1119ca978c296a38a9fe404e1c0cdcdab63. Version-Release number of selected component (if applicable): The regression was introduced in pki-core-10.4.1-5 (pki-core-snapshot-1.patch) How reproducible: always Steps to Reproduce: 1. install PKI with externally signed CA cert. 2. try and sign a certificate with a profile that uses AuthorityKeyIdentifierExtDefault Actual results: Issuance fails with error ``Could not instantiate AuthorityKeyIdentifier extension'' Expected results: Issuance succeeds. Additional info:
How to test: - Install externally-signed CA with a missing Subject Key ID extension - Attempt to issue a cert using any profile that uses the `AuthorityKeyIdentifierExtDefault` profile component (which should be most/all of em!) - if issuance succeeds, fix is verified. Upstream Gerrit review: https://review.gerrithub.io/#/c/381619/
Fixed upstream: 8ec0cbd1bef372ed50e19f6c5b6332b75209beb0.
Hi Fraser, I'm trying to verify this bug, for the verification of the bug I followed [1] documentation. But while installing I'm getting certificate validation error (I attached log file). What I observe that it add the certificate in /var/lib/pki/pki-tomcat/alias and it have SKI extension (Which verifies the Bugzilla) (attached p12 file) but it is failed to validate the certificate. Am I following the correct steps to verify this bug? pki-version : 10.4.1-16.el7_4 [1]http://pki.fedoraproject.org/wiki/Installing_CA_with_External_CA_Signing_Certificate
Created attachment 1352443 [details] Installation failure log file.
Created attachment 1352444 [details] Certs in pki-tomcat directory
Hi Fraser, (In reply to Amol K from comment #14) > Hi Fraser, > > I'm trying to verify this bug, for the verification of the bug I followed > [1] documentation. > > But while installing I'm getting certificate validation error (I attached > log file). > > What I observe that it add the certificate in /var/lib/pki/pki-tomcat/alias > and it have SKI extension (Which verifies the Bugzilla) (attached p12 file) > but it is failed to validate the certificate. > > Am I following the correct steps to verify this bug? > > pki-version : 10.4.1-16.el7_4 > > > [1]http://pki.fedoraproject.org/wiki/ > Installing_CA_with_External_CA_Signing_Certificate When I was trying above steps I forget to provide the CA certificate/chain that's why this issue occurred. After providing the CA certificate, installation is successful. I'm able to see the SKI extension in Signing certificate. ``` Name: Certificate Subject Key ID Data: 54:72:85:a1:2d:3d:3f:f0:80:0b:4a:1b:6b:97:0b:e8: 67:f0:6c:43 ``` Verifying this bug. pki-version : 10.4.1-16.el7_4
I tested this bug on RHEL 7.5 I am able to see the SKI extension in Signing Certificate. ``` Name: Certificate Subject Key ID Data: aa:43:c8:c1:e6:56:0e:0f:31:3d:69:30:03:cc:f8:d4: f0:49:a8:86 ``` Verifying this bug. pki-version : 10.5.1-1.el7
Hi Fraser, Do you for above scenario, ipa external ca is a quick testing. Use a Different CA to sign the IPA CA certificate --(Here we can use any nssdb or another dogtag CA)to get certificate sign. # ipa-server-install --external-ca This will generate a CSR in /root/ipa.csr. This is the file you need to provide to your CA for signing. You will also need to obtain a PEM copy of your CA trust chain. Once you have both of these you can continue the installer: # ipa-server-install --external_cert_file=/root/ipa.crt --external_ca_file=/root/existing_ca.crt If this case is passed we are good to go for this bugzilla automation/testing. Thanks Geetika
Geetika, I don't think we can automate this in a FreeIPA context because FreeIPA adds some of its own sanity checks when installing/updating the CA signing certificate. The absolute simplest way to test this, in a way that will be forward-compatible with sanity check we may eventually implement in Dogtag, would be: 1. install Dogtag with external CA. The signed certificate should have SKI extension. 2. re-issue the signing certificate *without* SKI extension 3. shut down Dogtag 4. install the new signing certificate in Dogtag's NSSDB 5. restart Dogtag. 6. check that signing still works, even though the signing certificate does not have SKI extension. HTH, Fraser
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/RHBA-2018:0925