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

Ohad Levy
Thu, 21 May 2009 04:02:31 -0000

comment out the SSLCARevocationFile option in apache.

cheers,
Ohad

On Thu, May 21, 2009 at 11:25 AM, jeff <jeff.adams@kw.com> wrote:

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