木偶中的SSL证书验证失败

Question

I have a docker container running with puppet master in it. Its created from the image puppet/puppetserver .

CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS                    PORTS                    NAMES
1a3e942655e0        puppet/puppetserver   "dumb-init /docker-e…"   32 minutes ago      Up 32 minutes (healthy)   0.0.0.0:8140->8140/tcp   puppet

Details of the puppetserver container:

Hostname: puppet
FQDN: puppet.openvpn

The puppet agent is running from a vagrant box on the same host as the docker. When I run puppet agent -td from the vagrnat box I get the following error -

Info: Creating a new SSL key for localhost.localdomain
Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for localhost.localdomain
Info: Certificate Request fingerprint (SHA256): A8:F0:9D:F2:2C:A0:AC:0B:66:55:90:64:64:B2:62:47:7F:DC:F0:18:18:A6:79:C0:BE:1D:00:B6:5E:F4:C3:18
Info: Downloaded certificate for localhost.localdomain from puppetserver
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate rejected): [ok for /CN=puppet.openvpn]
Info: Retrieving pluginfacts
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Failed to generate additional resources using 'eval_generate': SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate rejected): [ok for /CN=puppet.openvpn]
Error: /File[/opt/puppetlabs/puppet/cache/facts.d]: Could not evaluate: Could not retrieve file metadata for puppet:///pluginfacts: SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate rejected): [ok for /CN=puppet.openvpn]
Info: Retrieving plugin
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Failed to generate additional resources using 'eval_generate': SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate rejected): [ok for /CN=puppet.openvpn]
Error: /File[/opt/puppetlabs/puppet/cache/lib]: Could not evaluate: Could not retrieve file metadata for puppet:///plugins: SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate rejected): [ok for /CN=puppet.openvpn]
Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate rejected): [ok for /CN=puppet.openvpn]
Error: Could not retrieve catalog; skipping run

Details of vagrant puppet agent:

Hostname: localhost.localdomain

/etc/hosts:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.100.2.1 puppetserver

192.100.2.1 -> ip of host machine from within vagrant

/etc/puppetlabs/puppet/puppet.conf

[agent]
server = puppetserver

I am able to see the signed certificates generated for the vagrant puppet agent in the master and also in the logs when I run puppet agent -t .

• Are these certificates generated wrongly?
• What certificate exactly is getting rejected here?

Answer 1

Per its configuration, the agent is using the name 'puppetserver' to identify and contact the server. Its output confirms this.

The agent successfully creates a CSR, submits it to machine 'puppetserver', and receives a signed certificate. This shows that it is contacting the server successfully, and there is every reason to expect that the server will accept the cert that it just signed itself.

Presumably, then, the problem is with the master's certificate. Most likely, it is related to the fact that the puppetserver machine self-identifies as 'puppet.openvpn', so this is probably the name to which the master's certificate is issued, whereas the agent uses a different name to contact the master. A mismatch between the name on the cert and the agent's idea of the name of the machine it's talking to is good reason for the agent to reject the cert.

It is possible, with some attention to custom configuration, to arrange for the master's certificate to bear a different name than its own idea of its host name. Easier, though, is to just be consistent with the name used to identify that machine. And along those lines, I recommend relying consistently on fully-qualified names.

As a separate matter, you'll also run into trouble going forward with agents that have the same hostname as each other (ie localhost.localdomain) unless, again, you take care with their puppet configuration to ensure that they use different, unique names on their certificates. The path of least resistance is to give proper names to your machines, and to do so before registering them with a Puppet master.