[Freeipa-users] Crazy Cert problem?

[Janelle]

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