[Freeipa-users] Crazy Cert problem?

[Rob Crittenden]

Janelle wrote:
> On 6/17/15 2:00 PM, Rob Crittenden wrote:
>> Janelle wrote:
>>> 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.
>>
>> You just jumped to a completely different scenario: from a fresh
>> standalone install to a replica install. We should probably pick one
>> and solve it.
>>
>> I think the leap you're making is that the issue is that it notices
>> some previous cert. A revoked service cert wouldn't have any effect as
>> those service certs aren't in use.
>>
>> It very well could be finding the "wrong" realm based on DNS SRV
>> records. The logs should show you what the client discovered. Things
>> happen in multiple steps so perhaps there is a disconnect where the
>> right server is used in some, but not all, cases.
>>
>> rob
>>
> ALL the problems were all related. Even after building brand new
> servers, the problem persisted and then started cropping up with client
> installs.
>
> The solution traced to bad NSS packages. A simple "yum downgrade nss
> nss-sysinit nss-tools" solved it.. Something is up with the 3.18 verion
> and downgrading to 3.16 seems to have resolved. Should have known it
> would all be related to an upgrade.  Sometimes a slightly older version
> is best.
>
> ~Janelle

Can you open a bugzilla about this?

rob