Bug 1549187

Summary: IdM servers:/usr/share/ipa/html/ca.crt does not include the complete chain
Product: Red Hat Enterprise Linux 7 Reporter: Brian J. Atkisson <batkisso>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: akarimi, cheimes, frenaud, myusuf, ndehadra, pasik, pvoborni, rcritten, rvdwees, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.6.4-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 10:57:12 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 Brian J. Atkisson 2018-02-26 16:06:11 UTC
Description of problem:


We have an externally signed CA cert in IdM, resulting in the following
chain:

1. CN=Red Hat IT Root CA/O=Red Hat, Inc.
2. CN=Intermediate Certificate Authority/O=Red Hat
3. O=IPA.REDHAT.COM/CN=Certificate Authority

This is the chain stored in /etc/ipa/ca.crt.  However, the cert stored
in /usr/share/ipa/html/ca.crt only consists of #3 (the IPA CA cert). As
such, when clients are prompted to download the CA cert during the
ipa-client-install from http://$IPA_SERVER/ipa/config/ca.crt, they fetch
only #3.  This kind of works, but then the install fails at:

======================

Do you want to download the CA cert from
http://$IPA_SERVER/ipa/config/ca.crt?
(this is INSECURE) [no]: yes
Downloading the CA certificate via HTTP, this is INSECURE
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=IPA.REDHAT.COM
    Issuer:      CN=Intermediate Certificate Authority,OU=prod,O=Red Hat
    Valid From:  2017-10-16 19:19:57
    Valid Until: 2037-10-11 19:19:57

Enrolled in IPA realm IPA.REDHAT.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm IPA.REDHAT.COM
trying https://$IPA_SERVER/ipa/json
Connection to https://$IPA_SERVER/ipa/json
failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
(_ssl.c:579)
[...]
cannot connect to 'any of the configured servers':
https://$IPA_SERVER/ipa/json,
[...]
The ipa-client-install command failed. See
/var/log/ipaclient-install.log for more information

Comment 2 Florence Blanc-Renaud 2018-03-01 15:11:43 UTC
The installation with external-ca only adds IPA CA in master:/usr/share/ipa/html/ca.crt. Note that if ipa-certupdate is run on the master, the whole chain will be written to this file.

The other workaround is to copy master:/etc/ipa/ca.crt to client:/tmp/ca.crt and call ipa-client-install --ca-cert-file=/tmp/ca.crt (or copy directly to /etc/ipa/ca.crt and it will be reused).

Comment 3 Petr Vobornik 2018-03-20 17:27:55 UTC
In renewal case, it is documented to run ipa-certupdate on all replicas.

It is documented in renewal procedure: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/cert-renewal#manual-cert-renewal-ext

Do I understand it correctly that the bug is that on install, usr/share/ipa/html/ca.crt is not updated with full chain? And it is still valid on RHEL 7.4 and further? And correct fix would be to update it automatically during master installation and all subsequent replica installations?

Comment 4 Florence Blanc-Renaud 2018-03-22 10:00:17 UTC
In reply to comment #c3: yes, the issue happens on install with --external-ca and is present on RHEL 7.4:
ipa-server.x86_64                    4.5.0-22.el7_4

and RHEL 7.5:
ipa-server.x86_64               4.5.4-10.el7

We should automatically update it during master installation.

Comment 5 fbarreto 2018-05-02 18:17:10 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/7526

Comment 14 Mohammad Rizwan 2018-08-23 10:36:49 UTC
version:
ipa-server-4.6.4-6.el7.x86_64

Steps:
Execute upstream test:

IPATEST_YAML_CONFIG=/root/mh_cfg.yaml ipa-run-tests -v -r a --with-xunit test_integration/test_external_ca.py::TestExternalCA --logging-level=DEBUG

console log:

[..]
[ipatests.pytest_plugins.integration.host.Host.client.cmd11] RUN ['rm', '-rvf', '/root/ipatests/file_backup', '/root/ipatests/file_remove']
[ipatests.pytest_plugins.integration.host.Host.client.cmd11] Exit code: 0
[ipatests.pytest_plugins.integration.host.Host.client.OpenSSHTransport] GET /root/ipatests/backup_hostname
[ipatests.pytest_plugins.integration.host.Host.client.cmd12] RUN ['cat', '/root/ipatests/backup_hostname']
[ipatests.pytest_plugins.integration.host.Host.client.cmd12] cat: /root/ipatests/backup_hostname: No such file or directory
[ipatests.pytest_plugins.integration.host.Host.client.cmd12] Exit code: 1
[ipatests.pytest_plugins.integration.host.Host.client.OpenSSHTransport] RUN ['kdestroy', '-A']
[ipatests.pytest_plugins.integration.host.Host.client.cmd13] RUN ['kdestroy', '-A']
[ipatests.pytest_plugins.integration.host.Host.client.cmd13] Exit code: 0
[ipatests.pytest_plugins.integration.host.Host.client.OpenSSHTransport] RUN ['rm', '-rvf', '/root/ipatests']
[ipatests.pytest_plugins.integration.host.Host.client.cmd14] RUN ['rm', '-rvf', '/root/ipatests']
[ipatests.pytest_plugins.integration.host.Host.client.cmd14] removed ‘/root/ipatests/env.sh’
[ipatests.pytest_plugins.integration.host.Host.client.cmd14] removed directory: ‘/root/ipatests’
[ipatests.pytest_plugins.integration.host.Host.client.cmd14] Exit code: 0


---------------------------------------------------- generated xml file: /root/nosetests.xml -----------------------------------------------------
=========================================================== 2 passed in 629.47 seconds ===========================================================

Full console logs are attached.

Based on above observations, marking the bug as verified.

Comment 16 errata-xmlrpc 2018-10-30 10:57:12 UTC
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:3187

Comment 17 Chris Williams 2018-11-05 22:07:37 UTC
*** Bug 1626583 has been marked as a duplicate of this bug. ***