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: 
>> *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 view this discussion on the web visit
For more options, visit

Reply via email to