Re-enrolling clients after major version upgrade

[Bret Wortman]

So I'm trying to use Ansible to automate the process of re-enrolling all my systems after the upgrade from 3.8.6 to 4.3, and many (though not all) of my clients are reporting thusly:

# rpm -rf /var/lib/puppet/ssl /etc/puppet/ssl /etc/puppetlabs/puppet/ssl

# ssh puppet puppet cert list host.internal.net

Error: Could not find a certificate for host.internal.net

# puppet agent -t --noop

Info: Creating a new SSL key for host.internal.net

Info: Caching certificate for ca

Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml

Info: Creating a new SSL certificate request for host.internal.net

Info: Certificate Request fingerprint (SHA256): 75:6A:17:...

Info: Caching certificate for host.internal.net

Error: Could not request certificate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [unable to get local issuer certificate for /CN=puppet.internal.net]

Exiting: failed to retrieve certificate and waitforcert is disabled

# ssh root@puppet puppet cert list -a | grep host.internal.net

+ "host.internal.net" (SHA256) 42:AF:68:...

# puppet agent --version

3.8.6
#

I'm having success on other 3.8.6 clients and others as far back as 3.8.1. What's going on here that I'm not understanding?

[Christopher Wood]

To your specific issue, it looks like your agent's CA cert doesn't match the issuer of the new puppetmaster's CA cert ("unable to get local issuer certificate"). If I recall correctly, an agent without a CA cert will download one from the puppetmaster the first time and thereafter check it. You might check the cert chains to see what's going on, or if you downloaded the CA cert at all.

Otherwise I noticed this bit:

# rpm -rf /var/lib/puppet/ssl /etc/puppet/ssl /etc/puppetlabs/puppet/ssl
# ssh puppet puppet cert list host.internal.net
Error: Could not find a certificate for host.internal.net

Is it supposed to say rpm not rm? I Presume it's just the logging which is removing the quotes too.

Rhubarbing more generally, I had some success syncing the ssl directory during our own 3->4 update. I never found a reason to use a new cert for the same host when I already had one.

file { '/etc/puppetlabs/puppet/ssl':
ensure => directory,
backup => false,
recurse => true,
recurselimit => 99,
require => Package[$package],
source => '/var/lib/puppet/ssl',
}

The catalog with that class was only a during-update thing, of course.

if versioncmp($::puppetversion, '4.0.0') >= 0 {
include "role::${::stype}"
}
else {
include ::puppet_upgrade
}

Otherwise you could:

rsync -a --delete /var/lib/puppet/ssl /etc/puppetlabs/puppet/

> --
> 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 [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/6717bc33-381d-4890-90c0-a9be684dc9e5%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/6717bc33-381d-4890-90c0-a9be684dc9e5%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Bret Wortman]

I did the following (which I'd done before) and it seems to have helped:

# puppet resource service upppetserver ensure=stopped

# rm -rf /etc/puppetlabs/puppet/ssl

# puppet cert list -a

# puppet master --no-daemonize --verbose

^C
# puppet resource servcie puppetserver ensure=running

#

>    1. mailto:puppet-users+unsub...@googlegroups.com

[Bret Wortman]

Well, I _thought_ it helped. Many systems are connecting fine, others are still getting a different ca.pem file. I suspect for some reason the server is getting its copy overwritten somehow. I'm going to keep an eye on it now.