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.
Description of problem:
A RHEL-7.3 IdM system was updated to RHEL-7.4, and there are reports of SSL errors:
failed update on "ipactl restart" with error
"[SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1783)"
other related errors from httpd:
"SSL Library Error: -8172 Certificate is signed by an untrusted issuer"
"Bad remote server certificate: -8172"
The problem is CA certificate and SSL server certificate that have been used by RHEL-7.3 IdM before the RHEL-7.4 update are invalid:
A CA certificate has those extensions and signature algorithm:
"
Signed Extensions:
Name: Certificate Type
Data: <SSL CA,S/MIME CA,ObjectSigning CA>
Name: Certificate Basic Constraints
Critical: True
Data: Is a CA with no maximum path length.
Name: Certificate Key Usage
Critical: True
Usages: Digital Signature
Non-Repudiation
Certificate Signing
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
"
And a HTTPD SSL server cert has those extensions and signature algorithm:
"
Signed Extensions:
Name: Certificate Type
Data: <SSL Server>
Name: Certificate Key Usage
Usages: Key Encipherment
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
"
Both certs are invalid in PKI, and could NOT have been issued by Dogtag.
The CA cert was probably generated by OpenSSL.
We should add requirements on any third party or non IPA Dogtag issued certificate in IPA installer and updater, for certificate extensions that must be present before installing or updating an IdM master or replica.
Not doing so result in a severly broken IdM deployment, the CA must be renewed and deployed, then the server certificates must be renewed.
It may not be clear what is an invalid or valid CA or SSL server certificate, but we should make sure a minimum set of extensions are present to allow for a working PKI trust chain validation.
A CA cert should have:
- Certificate Authority Key Identifier
- Certificate Basic Constraints
Critical: True
a length
- Certificate Key Usage
Critical: True
Usages: Digital Signature
Non-Repudiation
Certificate Signing
CRL Signing
- Certificate Subject Key ID
- Authority Information Access
with method PKIX with oid 1.3.6.1.5.5.7.48.1 and a URI
A SSL sever cert should have:
- Certificate Authority Key Identifier
- Authority Information Access
with method PKIX with oid 1.3.6.1.5.5.7.48.1 and a URI
- Certificate Key Usage
Critical: True
Usages: Digital Signature
Non-Repudiation
Key Encipherment
Data Encipherment
- Extended Key Usage
TLS Web Server Authentication Certificate
TLS Web Client Authentication Certificate
- CRL Distribution Points with URI and "CRL issuer"
- Certificate Subject Key ID
and at least a signature algorithm with SHA-256 With RSA Encryption
added upstream ticket
https://pagure.io/freeipa/issue/7147
and linked to sf case 01922306
Version-Release number of selected component (if applicable):
RHEL-7.4 IdM update from RHEL-7.3
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Comment 6Kanwar Ranbir Sandhu
2017-09-21 17:22:50 UTC
I just did an IdM install on an RH 7.3 system and ran into the same problem on my first replica. However, I also saw these errors in /var/log/httpd/error_log:
p11-kit: couldn't open and map file: /etc/pki/ca-trust/source/ipa.p11-kit: Permission denied
On the master and replica, the permissions were set like so:
-rw-r-----. 1 root root 3559 Sep 21 11:06 ipa.p11-kit
On another working IdM domain (CentOS 7.3.1611), the permissions on that file are:
-rw-r--r--. 1 root root 3546 Jun 10 2015 ipa.p11-kit
So I changed the permissions on ipa.p11-kit on the two RHEL servers to 644. The errors went away and my replica was working again (i.e. my ipa commands were actually completing instead of hanging).
The RHEL 7.3 servers are running ipa-server-4.4.0-14.el7_3.7.x86_64.
Thank you taking your time and submitting this request for Red Hat Enterprise Linux 7. Unfortunately, this bug cannot be kept even as a stretch goal and was postponed to RHEL8.
Thank you taking your time and submitting this request for Red Hat Enterprise Linux. The request was cloned to the upstream tracker a long time ago (see link to the upstream ticket above), but it was unfortunately not given priority either in the upstream project, nor in Red Hat Enterprise Linux.
Given that this request is not planned for a close release, it is highly unlikely it will be fixed in this major version of Red Hat Enterprise Linux. We are therefore closing the request as WONTFIX.
To request that Red Hat reconsiders the decision, please reopen the Bugzilla with the help of Red Hat Customer Service and provide additional business and/or technical details about it's importance to you. Please note that you can still track this request or even offer help in the referred upstream Pagure ticket to expedite the solution.
Description of problem: A RHEL-7.3 IdM system was updated to RHEL-7.4, and there are reports of SSL errors: failed update on "ipactl restart" with error "[SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1783)" other related errors from httpd: "SSL Library Error: -8172 Certificate is signed by an untrusted issuer" "Bad remote server certificate: -8172" The problem is CA certificate and SSL server certificate that have been used by RHEL-7.3 IdM before the RHEL-7.4 update are invalid: A CA certificate has those extensions and signature algorithm: " Signed Extensions: Name: Certificate Type Data: <SSL CA,S/MIME CA,ObjectSigning CA> Name: Certificate Basic Constraints Critical: True Data: Is a CA with no maximum path length. Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Certificate Signing Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption " And a HTTPD SSL server cert has those extensions and signature algorithm: " Signed Extensions: Name: Certificate Type Data: <SSL Server> Name: Certificate Key Usage Usages: Key Encipherment Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption " Both certs are invalid in PKI, and could NOT have been issued by Dogtag. The CA cert was probably generated by OpenSSL. We should add requirements on any third party or non IPA Dogtag issued certificate in IPA installer and updater, for certificate extensions that must be present before installing or updating an IdM master or replica. Not doing so result in a severly broken IdM deployment, the CA must be renewed and deployed, then the server certificates must be renewed. It may not be clear what is an invalid or valid CA or SSL server certificate, but we should make sure a minimum set of extensions are present to allow for a working PKI trust chain validation. A CA cert should have: - Certificate Authority Key Identifier - Certificate Basic Constraints Critical: True a length - Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Certificate Signing CRL Signing - Certificate Subject Key ID - Authority Information Access with method PKIX with oid 1.3.6.1.5.5.7.48.1 and a URI A SSL sever cert should have: - Certificate Authority Key Identifier - Authority Information Access with method PKIX with oid 1.3.6.1.5.5.7.48.1 and a URI - Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment - Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate - CRL Distribution Points with URI and "CRL issuer" - Certificate Subject Key ID and at least a signature algorithm with SHA-256 With RSA Encryption added upstream ticket https://pagure.io/freeipa/issue/7147 and linked to sf case 01922306 Version-Release number of selected component (if applicable): RHEL-7.4 IdM update from RHEL-7.3 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: