[Freeipa-users] Crazy Cert problem?

[Janelle]

On 6/22/15 7:37 AM, Rob Crittenden wrote:
> 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
This looks like the fix - besides downgrading:

https://bugzilla.mozilla.org/show_bug.cgi?id=1132941