fingerprint changes after puppet cert --sign

[Tejas Gadaria]

Hi,

I have an issue where my cert finger prints changes after I sign it on the master. I removed all certs from master and deleted /var/lib/puppet/ssl stopped and started puppet master service. Later on client Stopped agent service and removed ssl directory, started puppet agent service and run "puppet agent -t" on client. but facing same issue.

I have time synchronized on master and agent. Need your help on this.

Regards,

Tejas

[Peter Kristolaitis]

This is expected behaviour.  SSL certificate fingerprints are just the cryptographic hash of the entire cert, including the signing info if present.    The hash of an unsigned cert is necessarily different than the hash of a signed cert, because they contain different information.

--
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 puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6ea26ca7-e70e-4b5a-b54c-1f76c6001a4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tejas Gadaria]

Hi Peter,

Thanks for reply,

After this while trying to run "puppet agent --test" on agent

Error: Could not request certificate: The certificate retrieved from the master
does not match the agent's private key.
Certificate fingerprint: D1:0A:9A:B6:48:1F:04:A1:CF:32:0F:0B:7D:8A:40:3C:58:F9:
6:4B:6A:CC:59:0F:ED:8F:85:1B:BD:C0:86:79
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 dtw-nnagarjuna.palyam.zeomega.loc
On the agent:
 1a. On most platforms: find C:/ProgramData/PuppetLabs/puppet/etc/ssl -name dt
-nnagarjuna.palyam.zeomega.loc.pem -delete
 1b. On Windows: del "C:/ProgramData/PuppetLabs/puppet/etc/ssl/dtw-nnagarjuna.
alyam.zeomega.loc.pem" /f
 2. puppet agent -t

Regards,

Tejas

[jcbollinger]

On Friday, February 20, 2015 at 2:41:10 AM UTC-6, Tejas Gadaria wrote:

Hi Peter,

Thanks for reply,

After this while trying to run "puppet agent --test" on agent

Error: Could not request certificate: The certificate retrieved from the master
does not match the agent's private key.
Certificate fingerprint: D1:0A:9A:B6:48:1F:04:A1:CF:32:0F:0B:7D:8A:40:3C:58:F9:
6:4B:6A:CC:59:0F:ED:8F:85:1B:BD:C0:86:79
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 dtw-nnagarjuna.palyam.zeomega.loc
On the agent:
 1a. On most platforms: find C:/ProgramData/PuppetLabs/puppet/etc/ssl -name dt
-nnagarjuna.palyam.zeomega.loc.pem -delete
 1b. On Windows: del "C:/ProgramData/PuppetLabs/puppet/etc/ssl/dtw-nnagarjuna.
alyam.zeomega.loc.pem" /f
 2. puppet agent -t

The advice right there in the error message is good.  Did you try doing that?


John

[Tejas Gadaria]

Hi,

Thanks for reply,

I tried this also, but issue was there. 

Though master and agent had same time, I sync both with my time server, & it worked. 

Just for information, how much time difference (would be in millisecond) is acceptable between agent and master

Regards,

Tejas

[jcbollinger]

On Sunday, February 22, 2015 at 10:31:53 PM UTC-6, Tejas Gadaria wrote:

Hi,

Thanks for reply,

I tried this also, but issue was there. 

Though master and agent had same time, I sync both with my time server, & it worked. 

Just for information, how much time difference (would be in millisecond) is acceptable between agent and master

I don't know specifically, but your question supposes the wrong scale.  In my experience, a skew of at least a few tens of seconds is accepted.  In principle, this is under the control of the party performing certificate validation, but Puppet does not expose it as a configuration parameter.

One thing to watch out for is that the time of day on each machine is correct for the time zone set on that machine.  Machines in different time zones are not inherently a problem, as long as time matches time zone.  However, if (say) a machine is configured with the wrong time zone for its geographic locality, but the correct local time for that locality, then that constitutes enough skew relative to the true time to make SSL certification validation fail.


John