Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
CA certificates without SKI extension no longer causes issuance failures
A previous update of Certificate System incorrectly removed a fallback procedure, which generated the Issuer Key Identifier. Consequently, the Certificate Authority (CA) failed to issue certificates if the CA signing certificate does not have the Subject Key Identifier (SKI) extension set. With this update, the missing procedure has been added again. As a result, issuing certificates no longer fails if the CA signing certificate does not contain the SKI extension.
DescriptionFraser Tweedale
2017-10-06 00:07:37 UTC
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/
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
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