On 6/17/15 6:21 AM, Rob Crittenden wrote:
Janelle wrote:
On 6/17/15 6:14 AM, Rob Crittenden wrote:
Janelle wrote:
Hi,

Had a server - named ipa001.example.com -- it was a replica. It died. It
was re-installed. However, prior to the re-install it was saying the
wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install (NOT a
replica or trying to join it back in to the existing ring of servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error????

But this is a brand new system, with brand new OS and the install was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no "peer" to be not
trusted?

What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually matter).

What does /etc/openldap/ldap.conf look like? Normally it should have
TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob
4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR    /etc/openldap/certs

Going to investigate.
~J


That should be fine assuming there aren't any certs in there (and on a brand new system I'd think you'd have empty NSS databases).

rob
So this gets interesting now...

Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all working fine. Something happens to 002. It dies. You "ipa-replica-manage del --clean --force ipa002" to get rid of it.

A period of time, say a month, goes by. You have lost a couple of other replicas for whatever reason, say 3 and 6. You decide you want to rebuild. You start with 002 - leaving the others up and running because you have users working. You firewall off 002 why you rebuild it.

You reinstall OS, reinstall FreeIPA. But no matter what, when you start to configure IPA it comes up with the error of being untrusted. Now, you try the same thing on 003 and 006. SAME problem.

For fun - you shutdown 005 and uninstall freeipa --unattended and then try to re-install it. Guess what - no issues.

Is this somehow related to:
Same domain and realm names floating around the net - so is it querying for a name somehow and one of the "still running" servers is saying - "NO NO NO -- that CERT is revoked!!!" - even though it never tries to connect to that server.

Or am I just thinking far too outside the box? And this is exactly what has happened. Rebuilding one of the servers that was never REMOVED is working just fine.

~J

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to