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(a)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(a)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.exa...
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.exa...
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.exa...,
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fipa2.exa...
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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org