Thanks for your reply Andrew, sadly I guess that wont be an option as the
pain of resigning the actual certificate for erroneous hosts are less the
re-signing every certificate for all existing hosts. After all we are in
the process of upgrading to Puppet 4 so hopefully one of the side effects
of that upgrade is that this error goes away as a part of the process.
Thanks though, one should always train ones cut'n'paste skills ;-).
Den måndag 10 oktober 2016 kl. 04:30:32 UTC+2 skrev Andrew:
>
> I recently had a similar issue, but not on windows. To fix, I replaced the
> puppet root ca with a sha256 cert instead of the older sha1.
> This or course meant re-signing *all* the client certs, which for me was
> about 4 hours worth of logging into every computer. My cut'n'paste fu is
> strong now ....
>
> Replacing the puppet ca with the newer one fixed the errors tho. Sorry I
> dont have an easier fix for you :(
>
> Andrew.
>
> On Friday, 7 October 2016 17:33:23 UTC+10, Fredrik Nilsson wrote:
>
>> Hi Guys,
>>
>> Hopefully one of you have a splendid idea on how to solve this...
>>
>> The problem is that I'm getting this error message a lot (to much is more
>> like it):
>>
>>
>> *Error: Could not request certificate: The certificate retrieved from the
>> master does not match the agent's private key.Certificate fingerprint:
>> FINGERPRINT*
>>
>>
>>
>>
>>
>>
>>
>> *To fix this, remove the certificate from both the master and the agent
>> and then start a puppet run, which will automatically regenerate a
>> certficate.On the master: puppet cert clean SERVERNAMEOn the agent: 1a.
>> On most platforms: find C:/ProgramData/PuppetLabs/puppet/etc/ssl -name
>> SERVERNAME.pem -delete 1b. On Windows: del
>> "C:/ProgramData/PuppetLabs/puppet/etc/ssl/SERVERNAME" /f 2. puppet agent
>> -t*
>>
>> Some characteristics:
>> This is on newly provisioned hosts (provisioned from Foreman)
>> The machinses is running Windows Server of different flavours
>> Puppet Agent version is 3.8.7 (upgrade to a 4 release is in the pipe)
>> We have two VmWare clusters and this occurs on both (the checkbox for
>> time sync with hardware host is NOT checked)
>>
>> I actually had this problem from start, but back then it was so seldomly
>> occuring so I decided to live with it, say it occured like 1/20 or so
>> machines. But now it has escalated and it is rather 1/20 that got a working
>> certificate from start, actually when starting to banging my head against
>> the wall again yesterday I had two machines working, after adding an extra
>> timesync in the provisioning workflow, but that was shortlived happiness as
>> I've made 3 more machines after that with no success.
>>
>> So my first suspects on this was time and change of "security context",
>> but I think they're of the hook for the moment as I'm pretty confident in
>> that my time is right and that I to my knowledge have stayed in the same
>> security context.
>>
>> To make sure that I got the time right I have this runing under the
>> oobeSystem step in my provisioning workflow :
>> *powershell.exe -noprofile -executionpolicy bypass -command "&
>> {Start-Service W32Time -ErrorAction SilentlyContinue; .\w32tm.exe /resync}"*
>>
>> After installing chocolatey and the puppet agent the agent phones home
>> like this (command composed from how this is done in the Linux half of our
>> department):
>> *powershell.exe -noprofile -executionpolicy bypass -command " & {&
>> 'C:\Program Files\Puppet Labs\Puppet\bin\puppet.bat' agent -o --tags
>> no_such_tag --no-daemonize}"*
>>
>> The user loging on and running the commands are the local administrator
>> account, to be extra thorough I logged on as that account trying to run a
>> *puppet
>> agent -t *after the host is built, just to be sure there was no logon
>> account related stuff going on, but no difference.
>>
>> Following the steps in the error message, generating a new certificate,
>> ofcourse works, but we can all see the inconvinience of dowing that
>> constantly on newly provisioned hosts, right?
>>
>> I think that sums things up quite good, as said I've been baning my head
>> against this, while not ignoring it, could still be something fishy going
>> on on the puppetmaster that is not managed by me, but me colleauges in the
>> linux neighborhood don't ecperience this so it is seemingly something to do
>> with the Windows hosts.
>>
>> Cheers,
>> Fredrik
>>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/32f574fb-69eb-41af-bd75-25cdcacd6745%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
