On 11/11/2014 08:48 AM, Natxo Asenjo wrote: > Hi Nalin, > > On Mon, Nov 10, 2014 at 5:19 PM, Nalin Dahyabhai <[email protected]> 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: [email protected] > 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 -- 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
