[Freeipa-users] certmonger question

Nalin Dahyabhai nalin at redhat.com
Mon Nov 10 16:19:34 UTC 2014


On Mon, Nov 10, 2014 at 04:17:49PM +0100, Natxo Asenjo wrote:
> Nov 10 15:51:31 apachetest03 certmonger: Decoding error on
> "TUlJRG5EQ0NBb1NnQXdJQkFnSUJBVEFOQmdrcWhraUc5dzBCQVFzRkFEQTdNUmt3#012RndZRFZRUUtFeEJWVGtsWUxrbFNTVk5hVDFKSExrNU1NUjR3SEFZRFZRUURFeFZE#012WlhKMGFXWnBZMkYwWlNCQmRYUm9iM0pwZEhrd0hoY05NVEl4TVRBM01qRXlOREUx#012V2hjTk1qQXhNVEEzTWpFeU5ERTFXakE3TVJrd0Z3WURWUVFLRXhCVlRrbFlMa2xT#012U1ZOYVQxSkhMazVNTVI0d0hBWURWUVFERXhWRFpYSjBhV1pwWTJGMFpTQkJkWFJv#012YjNKcGRIa3dnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lC#012QVFDeTJXVnk3UWtIaXVFTlcvemtNZUQ0SUxvcU9ydXVZS3ZiMitycWV1STlpdyt6#012QkJ0NTY5WFN4cmdjeWVUcTBHNjNSamJYZ3JBem90NEVoWWc2TW9lcERWQ24wQm51#012clVmZ2JDZjVSMEVib2lnamJvaDVNR25QeWxIZWZMUkdBUk5VQ3djVEdBNHVSOVpR#012TC9yRVVxV2t0bVpqYW5ZRXZPUDhVQmV1cTVXUDVlbWFYOFUwM1N6TUErY1FUOXcv#012engwZUFPWWdaVzV5eDNhQTVRNEZ1OHFXcU1HR0FPQTZ5RFFXcW1JcGd4aUZISFJh#012N2hRSzRBamVIZ3ZhQ29sYVU5NzlMaDVqQXYvWHdyWXRvazFHK1VWRXA0NUlOcGZ4#012cjVkTGUwM29nblBGUFowL3h3YkJxdHQvMnFuNnJrNEw0dWtINFA5ZzRSdzBvN1Ux#012eUpWeC9TT0pBZ01CQUFHamdhb3dnYWN3SHdZRFZSMGpCQmd3Rm9BVW81ZmtpaTY0#012eno3cU0vSzhrOVlqM3FtRU5tZ3dEd1lEVlIw!
>  VEFRSC9CQVV3QXdFQi96QU9CZ05W#012SFE4QkFmOEVCQU1DQWNZd0hRWURWUjBPQkJZRUZLT1g1SW91dU04KzZqUHl2SlBX#012STk2cGhEWm9NRVFHQ0NzR0FRVUZCd0VCQkRnd05qQTBCZ2dyQmdFRkJRY3dBWVlv#012YUhSMGNEb3ZMMnRrWXpBeExuVnVhWGd1YVhKcGMzcHZjbWN1Ym13Nk9EQXZZMkV2#012YjJOemNEQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFKMjhnZG96ZC9wdE9NNVBU#012S0t3eVYrb3RPL3drM3lFcnNseHBOVWhSWmdTTlV3VCt0NnRmRi9qK2pKUlY1c1gr#012ankwOWM5RG8rcDNIeTlnUm5JVkpPTkRTY3ZNVjluRGM3NUM2SkdYVStGZE5KSitE#012YnBlcC9Sc1FqSHJaK3Vud0l5QVdvT3BCb2w4c0d6TjV0WGJlby9NNm1HRnhhQlRI#012MUdLdGd2NENLYnpRQW90dk1hR3h6S2pTY0hSc0dhZXJOU0NacC85MHlSSnlwQzNN#012T29zVUZjRmw0Q29ZSEI0MlhEVHpqdnpaUWNhRk5jZ1lYT2NpdWp3d1lITnpzU3FZ#012Y0lLRlNXdVd2TisrN2c0eXhRTWx1OFFXME1zL1BudG1UbU8yY0RkTkkxdHVqVnlC#012S2U1OTl5NE8vRXMvTUJHdER0VkE4NUFMa3NKT1UyN2JqdHZiQmc9PQ==#012"
> (1240 bytes)!
> 
> The certmonger service keeps stopping (nothing logged), I notice when running:
> 
> $ sudo getcert list
> Please verify that the certmonger service has been started.
> 
> This I got right after restarting it and getting a right result, with
> about 5 minutes in between. Now it's done i again:
> 
> ]$ sudo getcert list
> Number of certificates and requests being tracked: 1.
> Request ID '20140410142412':
>     status: MONITORING
>     stuck: no
>     key pair storage:
> type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate
> - apachetest03.domain.tld',token='NSS Certificate DB'
>     certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA
> Machine Certificate - apachetest03.domain.tld',token='NSS Certificate
> DB'
>     CA: IPA
>     issuer: CN=Certificate Authority,O=DOMAIN.TLD
>     subject: CN=apachetest03.domain.tld,O=DOMAIN.TLD
>     expires: 2016-04-10 14:24:15 UTC
>     key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>     eku: id-kp-serverAuth,id-kp-clientAuth
>     pre-save command:
>     post-save command:
>     track: yes
>     auto-renew: yes
> ]$ sudo getcert list
> Please verify that the certmonger service has been started.
> 
> 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.

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).

HTH,

Nalin




More information about the Freeipa-users mailing list