[Freeipa-users] certmonger question

Tue Nov 11 11:57:03 UTC 2014

On 11/11/2014 08:48 AM, Natxo Asenjo wrote:
> Hi Nalin,
> 
> On Mon, Nov 10, 2014 at 5:19 PM, Nalin Dahyabhai <nalin at redhat.com> wrote:
>> On Mon, Nov 10, 2014 at 04:17:49PM +0100, Natxo Asenjo wrote:
>>> How can I debug this?
>>
>> First thing would be to run the daemon with additional logging - I
>> usually use '-d3' to watch what's going on while the daemon's running
>> various tasks.
> 
> wow, yes. Now you can debug ;-)
> 
> I got this sequential message until the certmonger daemon died (unly
> posting a small portion):
> 
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1020.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in
> 1481416576 seconds.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1022.
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1022.
> 2014-11-11 08:34:28 [8610] CA5('local').certs data is unchanged
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs now.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'ANALYZING'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1021.
> 2014-11-11 08:34:28 [11672] Certificate "Local Signing Authority"
> valid for 31473673s.
> 2014-11-11 08:34:28 [11672] Running result is 1481416576.
> 2014-11-11 08:34:28 [11672] Final result is 1481416576.
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs on traffic from 1021.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs in
> 1481416576 seconds.
> 2014-11-11 08:34:28 [8610] CA5('local').certs moved to state 'REFRESHING'
> 2014-11-11 08:34:28 [8610] Will revisit CA5('local').certs soon.
> 2014-11-11 08:34:33 [8610] CA5('local').certs data is unchanged
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs now.
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'ANALYZING'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 1022.
> 2014-11-11 08:34:33 [11677] Certificate "Local Signing Authority"
> valid for 31473668s.
> 2014-11-11 08:34:33 [11677] Running result is 1481416576.
> 2014-11-11 08:34:33 [11677] Final result is 1481416576.
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs on traffic from 1022.
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'NEED_TO_REFRESH'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs in
> 1481416576 seconds.
> 2014-11-11 08:34:33 [8610] CA5('local').certs moved to state 'REFRESHING'
> 2014-11-11 08:34:33 [8610] Will revisit CA5('local').certs soon.
> 2014-11-11 08:34:38 [8610] CA5('local').certs data is unchanged
> 2014-11-11 08:34:38 [8610] CA5('local').certs moved to state 'NEED_TO_ANALYZE'
> 2014-11-11 08:34:38 [8610] Will revisit CA5('local').certs now.
> Killed
> 
>> The data logged with the Decoding Error looks like a certificate that's
>> been base64-encoded, and then base64-encoded again, which is very odd,
>> since that error message is logged in cases where it fails to parse a
>> root certificate that it has just retrieved from the CA, and that data
>> shouldn't have been mangled like that.
>>
>> Can you check the contents of the "caCertificate" attribute in the
>> "cn=cacert,cn=ipa,cn=etc" entry under the IPA base DN in the directory
>> server, and perhaps provide them?  They can be retrieved using a command
>> like:
>>    ldapsearch -b cn=cacert,cn=ipa,cn=etc,$SUFFIX -s base -Y GSSAPI caCertificate
>>
>> The attribute values are supposed to be certificates in binary form,
>> which ldapsearch will likely base64-encode for display -- ldapsearch
>> will indicate that it's doing this by separating the attribute name from
>> the value using two colons ('::') instead of the usual one (':') in its
>> output, in accordance with ldif(5).
> 
> using the apache directory studio I see in the attr
> cacertificate;binary: invalid certificate (1240 bytes).
> 
> Using your command I get:
> 
> $ ldapsearch -b cn=cacert,cn=ipa,cn=etc,dc=domain,dc=tld -Y GSSAPI
> caCertificate -h kdc01.domain.tld
> SASL/GSSAPI authentication started
> SASL username: user.admin at DOMAIN.TLD
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <cn=cacert,cn=ipa,cn=etc,dc=domain,dc=tld> with scope subtree
> # filter: (objectclass=*)
> # requesting: caCertificate
> #
> 
> # CACert, ipa, etc, domain.tld
> dn: cn=CACert,cn=ipa,cn=etc,dc=domain,dc=tld
> cACertificate;binary:: TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkF
>  EQTdNUmt3RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZEWlhK
>  MGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUxV2hjTk1qQXhNVEEzT
>  WpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xTU1ZOYVQxSkhMazVNTVI0d0hBWURWUV
>  FERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJvYjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUF
>  BNElCRHdBd2dnRUtBb0lCQVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1
>  STlpdyt6QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51clVmZ
>  2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpRTC9yRVVxV2t0bVpqYW
>  5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcvengwZUFPWWdaVzV5eDNhQTVRNEZ1OHF
>  XcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJhN2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRv
>  azFHK1VWRXA0NUlOcGZ4cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSd
>  zBvN1UxeUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0eno3cU
>  0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIwVEFRSC9CQVV3QXdFQi96QU9CZ05WSFE4QkFmOEVCQU1DQWN
>  Zd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBXSTk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VC
>  QkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlvYUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjb
>  WN1Ym13Nk9EQXZZMkV2YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE
>  9NNVBUS0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1grankwOWM
>  5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitEYnBlcC9Sc1FqSHJaK3Vu
>  d0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRIMUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY
>  0hSc0dhZXJOU0NacC85MHlSSnlwQzNNT29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2
>  NpdWp3d1lITnpzU3FZY0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHV
>  qVnlCS2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ==
> 
> # search result
> search: 4
> result: 0 Success
> 
> So there is something wrong but how come I only see this in this
> client after upgrading it to centos 6.6?
> 
> Thanks for your assistance.

It is strange, yes. This bug is related to client certificate retrieval, fixed
in 6.5:

https://bugzilla.redhat.com/show_bug.cgi?id=924004

In 6.5, we also fixed certificate upload on upgrade is it sometimes could have
gone double encoded:
https://bugzilla.redhat.com/show_bug.cgi?id=948928

So if the lurking double encoded certificate is in LDAP, and thus Apache DS
shows is invalid (it shows as OK in my RHEL-7.0 server), maybe the easiest way
to fix it would be to:

- Open your Apache DS
- Back up cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com
- Delete the cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com entry
- Run
  # ipa-ldap-updater --upgrade --ldapi --quiet
  on your 6.5+ server and the certificate entry should get regenerated (tested
with 7.0).

Martin