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://ipa1.example.de/ipa/xml 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://ipa2.example.de/ipa/xml 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://ipa1.example.de/ipa/xml, https://ipa2.example.de/ipa/xml 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
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
Hi Charles,
On 11/16/17 7:59 PM, Charles Hedrick via FreeIPA-users wrote:
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
Unfortunately this option doesn't exist for freeipa 3.0.2 :-(.
Anyway, I highly appreciate your response.
Regards Harri
Hi folks,
its always worth reading the code.
ipa-client-install of freeipa 3.0.2 uses
wget http://ipa1.example.de/ipa/config/ca.crt
to grab the CA certificate. It seems that ipa-cacert-manage (CentOS 7.3) did not upgrade /usr/share/ipa/html/ca.crt on the servers when I migrated to the new root CA. Would anybody mind to fix?
Thanx very much Harri
On 11/16/17 9:28 AM, Harald Dunkel via FreeIPA-users 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://ipa1.example.de/ipa/xml 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://ipa2.example.de/ipa/xml 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://ipa1.example.de/ipa/xml, https://ipa2.example.de/ipa/xml 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
freeipa-users@lists.fedorahosted.org