[Puppet Users] Re: Certificate issue for puppetd on same node as puppetmasterd

jeff
Thu, 21 May 2009 03:25:03 -0000

Hey Greg,

What a timely email. Just this afternoon I was working on bringing a new
.24.8 puppetmaster online in effort to test migrating to using
apache/passenger as a frontend.

While troubleshooting, I tried running the tried and true puppetmasterd
in lieu of the apache/passenger frontend in order to verify that I had
indeed set everything up properly, and ran into exactly this.

This was attempted by using the new puppetmaster as the puppet client
(i.e. there is only one system I''m working with). I mention this only
because the only reference I could find to the SSL error message had to
do with clocks being out of sync between clients and server. Clearly not
the case in my scenario. For completeness, this particular environment
is Debian Lenny, running the .24.8 puppet and puppetmaster packages from
SID.

I must admit it''s a bit un-nerving, as I had always assumed I could
spin
up a new (or replacement) puppetmaster at anytime, should the need arise.

Anyhow, count me as a very interested party to learning how to get this
working.

Thanks,

- Jeff

Greg wrote:
> Hi all,
>
> I''m trying to get a puppet daemon to run on the same host as a
> puppetmaster, and I''m seeing an interesting problem on 0.24.8 on
> Solaris.
>
> One of the rules is to push out a current puppet.conf - heres the rule
> I''m using:
>
> file { puppetconf:
>                 path => $operatingsystem ? {
>                         solaris =>
"/etc/opt/csw/puppet/puppet.conf",
>                         default => "/etc/puppet/puppet.conf",
>                 },
>                 owner => root,
>                 group => root,
>                 mode => 644,
>                 source => [ "puppet:///puppetdaemon/puppet.conf-
> $hostname",
>                         "puppet:///puppetdaemon/puppet.conf-
> $kernelrelease",
>                         "puppet:///puppetdaemon/puppet.conf" ]
>         }
>
> Now the issue I am seeing is with the actual file transfer. When it
> comes to actually
> update the puppet config file, the messages file shows this:
>
> May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.warning]
> Certificate validation failed; consider using the certname
> configuration option
> May 21 09:37:50 puppetmaster puppetd[3644]: [ID 702911 daemon.error]
> (//Node[default]/puppetdaemon/File[puppetconf]/source) change from
> {md5}846ec1befda534749269c6ec294bad40 to
puppet:///puppetdaemon/puppet.conf-puppetmaster
> puppet:///puppetdaemon/puppet.conf-5.10 puppet:///puppetdaemon/puppet.conf
> failed: Certificates were not trusted: SSL_connect returned=1 errno=0
> state=SSLv3 read server certificate B: certificate verify failed
>
> The weird thing here is that it seems to handle the initial handshakes
> and perform the rest of the work,
> its only when it comes to replacing a file... Running the
> puppetmasterd in debug mode yields this bit of info:
>
> debug: Using cached node for puppetmaster.domain.com
> debug: mount[puppetdaemon]: Describing /puppetdaemon/puppet.conf-
> puppetmaster for puppetmaster.domain.com
> debug: Overriding puppetmaster with cert name puppetmaster.domain.com
> debug: Allowing authenticated client puppetmaster.domain.com(10.1.2.3)
> access to fileserver.retrieve
> debug: Using cached node for puppetmaster.domain.com
> info: mount[puppetdaemon]: Sending /puppetdaemon/puppet.conf-
> puppetmaster to puppetmaster.domain.com
> debug: Overriding puppetmaster with cert name puppetmaster.domain.com
> debug: Allowing authenticated client mplops1prd.domain.com(10.1.2.3)
> access to fileserver.describe
>
> So it appears that the file is being sent to the client, and it is the
> client that is rejecting the file on the basis of the invalid
> certificate. Heres the weird thing - its happy with the certificate
> for everything else...
>
> The only other bit I will point out is that both the client and the
> server appear to be using the same
> certificate. I have this working without issue at a seperate site
> using the same configuration (as far
> as I can tell...)
>
> Has anyone seen something like this before?
>
> thanks,
>
> Greg
> >