I’ve seen the same thing. Or at least I think it seems like it’s related.
We have three servers, all on Centos. The initial one was installed under 7.3, using defaults. That caused it to generate a self-signed CA. We later added a commercial cert for HTTP and LDAP. When we upgraded to 7.4, it generated a self-signed cert to handle anonymous KINIT.
We had no trouble with ipa-client-install under 7.3, but the first time I tried it after the 7.4 upgrade, ipa-client-install said it was getting a cert from the server, displayed a self-signed cert, and then failed with a cert error. My conjecture is that it was trying to make an HTTP or LDAP connection using the self-signed cert rather than the commercial cert.
The workaround is to generate a file containing the CA path for the commercial cert, and pass it to ipa-client-install
ipa-client-install --ca-cert-file=/home/hedrick/certs --no-sudo -w password
You can generate this using
openssl s_client -connect krb2.cs.rutgers.edu:443 -showcerts > ~/certs
Then edit certs and remove everything except the certs themselves (including the —— lines at the beginning and end of each).
I suspect the same workaround might work for you.
On Nov 16, 2017, at 3:28 AM, Harald Dunkel via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi folks,
a few months ago I had replaced the externally signed root certificate on my servers (CentOS 7.3) using ipa-cacert-manage. Problem:
ipa-client-install on a freshly bootstrapped Debian 7 (Wheezy, freeipa 3.0.2) fails. Apparently it stumbles over the old root certificate:
# ipa-client-install --domain=example.de --realm=EXAMPLE.DE --no-ssh --no-sshd --no-ntp Discovery was successful! Hostname: pobde7i001.vs.example.de Realm: EXAMPLE.DE DNS Domain: example.de IPA Server: ipa1.example.de BaseDN: dc=example,dc=de
Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Password for admin@EXAMPLE.DE: Enrolled in IPA realm EXAMPLE.DE Created /etc/ipa/default.conf Domain example.de is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm EXAMPLE.DE trying https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fipa1.exampl... cert validation failed for "CN=ipa1.example.de,O=example AG,C=DE" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) trying https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fipa2.exampl... cert validation failed for "CN=ipa2.example.de,O=example AG,C=DE" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) Cannot connect to the server due to generic error: cannot connect to Gettext('any of the configured servers', domain='ipa', localedir=None): https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fipa1.exampl..., https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fipa2.exampl... Installation failed. Rolling back changes.
/etc/ipa/ca.crt on the client shows it somehow picked up the old certificate. On the servers /etc/ipa/ca.crt is the new root cert. "getcert list" on the servers shows only certificates based upon the new root ca, too. I wonder where ipa-client-install picked up the unwanted certificate?
Of course I tried putting the new ca.crt into place before running ipa-client-install, but it was overwritten.
Of course there is no such problem for ipa 4.4.4 on Stretch.
Every heplful hint is highly appreciated Harri _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org