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:
we have some issues with RHEL6 clients to retrieve the CA certificates, when external CA installed but not only.
In fact, the RHEL6 clients are retrieving from LDAP only one CA certificate, the one stored in:
cn=CAcert,cn=ipa,cn=etc,<dc=domain,dc=name>
here we have only ONE ca certificate. When we have external CA, we need to retrieve the full CA chain.
We see in the code of RHEL6 client:
==============================================
def get_ca_cert_from_ldap(url, basedn, ca_file):
'''
Retrieve th CA cert from the LDAP server by binding to the
server with GSSAPI using the current Kerberos credentials.
Write the retrieved cert into the CACERT file.
Raises errors.NoCertificateError if cert is not found.
Raises errors.NetworkError if LDAP connection can't be established.
Raises errors.LDAPError for any other generic LDAP error.
Raises errors.OnlyOneValueAllowed if more than one cert is found.
Raises errors.FileError if unable to write cert.
'''
ca_cert_attr = 'cAcertificate;binary'
dn = DN(('cn', 'CAcert'), ('cn', 'ipa'), ('cn', 'etc'), basedn)
SASL_GSSAPI = ldap.sasl.sasl({},'GSSAPI')
root_logger.debug("trying to retrieve CA cert via LDAP from %s", url)
...
if len(result) != 1:
raise errors.OnlyOneValueAllowed(attr=ca_cert_attr)
attrs = result[0][1]
==============================================
And it's expecting to find only one certificate.
This fails in two scenarios:
1) external CA. We have a full chain and the chain is not stored anymore in cn=CAcert but rather in cn=certificates
2) in case of certificate expiration and resubmition, it seems this entry (cn=CAcert,...) is not updated. So, the expired certificate is still stored there.
What is the consequence ?
ipa-client-install in RHEL6 could, in some cases be successfully installed, since the certificate is retrieved and stored. But a ssl authentication will not work.
And if we re-install the client, without deleting the /etc/ipa/ca.crt we won't be able to do a right authentication at re running ipa-client-install
In RHEL7, we have changed completely the retrieval by using this subtree:
===================
config_dn = DN(('cn', 'ipa'), ('cn', 'etc'), base_dn)
container_dn = DN(('cn', 'certificates'), config_dn)
try:
===================
Version-Release number of selected component (if applicable): ipa-client-3.0.0-51.el6.x86_64
How reproducible: always
Steps to Reproduce: install external CA + RHEL6 client.
Actual results:
only the root CA of the chain is retrieved. But it could be an expired version of the root CA.
Expected results:
The full chain has to be retrieved and stored as in RHEL7.
Additional info:
The workaround is to manually copy the /etc/ipa/ca.crt certificate from the master to the client before install. But this is NOT always working. Why ?
Because the certificate retrieved from LDAP will be compared with the first certificate in /etc/ipa/ca.crt (of the chain). So, we could have this issue, for instance:
====================================================
The CA cert available from the IPA server does not match the
local certificate available at /etc/ipa/ca.crt
Existing CA cert:
Subject: CN=mycacertificate
Issuer: CN=mycacertificate
Valid From: Wed Feb 07 14:24:45 2018 UTC
Valid Until: Mon May 07 14:24:45 2018 UTC
Retrieved CA cert:
Subject: CN=Certificate Authority,O=PARENTE.LOCAL
Issuer: CN=mycacertificate
Valid From: Wed Feb 07 14:24:45 2018 UTC
Valid Until: Mon May 07 14:24:45 2018 UTC
Do you want to replace the local certificate with the CA
certificate retrieved from the IPA server? [yes]: no
Cannot obtain CA certificate
'ldap://newserver.parente.local' doesn't have a certificate.
======================================================
So, the real workaround is to copy the /etc/ipa/ca.crt from the master but change the order of the certificates to make the first one in the file, the one that matches with the one stored in ldap under cn=caCert.
Description of problem: we have some issues with RHEL6 clients to retrieve the CA certificates, when external CA installed but not only. In fact, the RHEL6 clients are retrieving from LDAP only one CA certificate, the one stored in: cn=CAcert,cn=ipa,cn=etc,<dc=domain,dc=name> here we have only ONE ca certificate. When we have external CA, we need to retrieve the full CA chain. We see in the code of RHEL6 client: ============================================== def get_ca_cert_from_ldap(url, basedn, ca_file): ''' Retrieve th CA cert from the LDAP server by binding to the server with GSSAPI using the current Kerberos credentials. Write the retrieved cert into the CACERT file. Raises errors.NoCertificateError if cert is not found. Raises errors.NetworkError if LDAP connection can't be established. Raises errors.LDAPError for any other generic LDAP error. Raises errors.OnlyOneValueAllowed if more than one cert is found. Raises errors.FileError if unable to write cert. ''' ca_cert_attr = 'cAcertificate;binary' dn = DN(('cn', 'CAcert'), ('cn', 'ipa'), ('cn', 'etc'), basedn) SASL_GSSAPI = ldap.sasl.sasl({},'GSSAPI') root_logger.debug("trying to retrieve CA cert via LDAP from %s", url) ... if len(result) != 1: raise errors.OnlyOneValueAllowed(attr=ca_cert_attr) attrs = result[0][1] ============================================== And it's expecting to find only one certificate. This fails in two scenarios: 1) external CA. We have a full chain and the chain is not stored anymore in cn=CAcert but rather in cn=certificates 2) in case of certificate expiration and resubmition, it seems this entry (cn=CAcert,...) is not updated. So, the expired certificate is still stored there. What is the consequence ? ipa-client-install in RHEL6 could, in some cases be successfully installed, since the certificate is retrieved and stored. But a ssl authentication will not work. And if we re-install the client, without deleting the /etc/ipa/ca.crt we won't be able to do a right authentication at re running ipa-client-install In RHEL7, we have changed completely the retrieval by using this subtree: =================== config_dn = DN(('cn', 'ipa'), ('cn', 'etc'), base_dn) container_dn = DN(('cn', 'certificates'), config_dn) try: =================== Version-Release number of selected component (if applicable): ipa-client-3.0.0-51.el6.x86_64 How reproducible: always Steps to Reproduce: install external CA + RHEL6 client. Actual results: only the root CA of the chain is retrieved. But it could be an expired version of the root CA. Expected results: The full chain has to be retrieved and stored as in RHEL7. Additional info: The workaround is to manually copy the /etc/ipa/ca.crt certificate from the master to the client before install. But this is NOT always working. Why ? Because the certificate retrieved from LDAP will be compared with the first certificate in /etc/ipa/ca.crt (of the chain). So, we could have this issue, for instance: ==================================================== The CA cert available from the IPA server does not match the local certificate available at /etc/ipa/ca.crt Existing CA cert: Subject: CN=mycacertificate Issuer: CN=mycacertificate Valid From: Wed Feb 07 14:24:45 2018 UTC Valid Until: Mon May 07 14:24:45 2018 UTC Retrieved CA cert: Subject: CN=Certificate Authority,O=PARENTE.LOCAL Issuer: CN=mycacertificate Valid From: Wed Feb 07 14:24:45 2018 UTC Valid Until: Mon May 07 14:24:45 2018 UTC Do you want to replace the local certificate with the CA certificate retrieved from the IPA server? [yes]: no Cannot obtain CA certificate 'ldap://newserver.parente.local' doesn't have a certificate. ====================================================== So, the real workaround is to copy the /etc/ipa/ca.crt from the master but change the order of the certificates to make the first one in the file, the one that matches with the one stored in ldap under cn=caCert.