Puppet CSR Issue using external certificates

Question

I am hoping that someone might be able to help me with a CSR (Certificate Singing Request) issue that I am facing. I currently have a Puppet server and Puppet agent on a single server. However, I am using external certificates for these. The Puppet server and Puppet agent should have there own individual certificates. I am hopping for some advice on how to stop the agent trying to send a CSR as we are not using puppet's internal Certificates.

The Issue that I am seeing is when I run /opt/puppetlabs/bin/puppetserver ca list --all I see the following error:

Fatal error when running action 'list'
  Error: Failed connecting to https://server.altname.example.com:8140/puppet-ca/v1/certificate_statuses/any_key
  Root cause: SSL_read: sslv3 alert certificate unknown

I then went on to check the status of the agent and when I run service puppet status I can see the following error:

server puppet-agent[7056]: Failed to submit the CSR, HTTP response was 404

Note; the puppet server and agent are in a running state.

This is showing that there is a CSR issue. However, I don't think this should be happening as I am using external Certificates that I have set up on the machine.

I have also updated the ca.cfg file to disable the certificate authority as I had read this need to be done when using external certificates. This file looks like this:

#puppetlabs.services.ca.certificate-authority-service/certificate-authority-service
puppetlabs.services.ca.certificate-authority-disabled-service/certificate-authority-disabled-service
puppetlabs.trapperkeeper.services.watcher.filesystem-watch-service/filesystem-watch-service

I have also updated the webserver.conf file to point to where the certificates are located.

webserver: {
    access-log-config: /etc/puppetlabs/puppetserver/request-logging.xml
    client-auth: want
    ssl-host: 0.0.0.0
    ssl-port: 8140
    ssl-cert: /etc/puppetlabs/puppet/ssl/certs/server.altserver.example.com.puppetserver.pem
    ssl-key: /etc/puppetlabs/puppet/ssl/private_keys/server.altserver.example.com.puppetserver.pem
    ssl-ca-cert: /etc/puppetlabs/puppet/ssl/certs/ca.pem
}

The certificates are located at /etc/puppetlabs/puppet/ssl/ When running a tree on the directory this looks like:

/etc/puppetlabs/puppet/ssl/
├── certificate_requests
├── certs
│   ├── ca.pem
│   ├── server.altserver.example.com.pem
│   └── server.altserver.example.com.puppetserver.pem
├── crl.pem
├── private
├── private_keys
│   ├── puppet.altserver.example.com.pem
│   ├── server.altserver.example.com.pem
│   └── server.altserver.example.com.puppetserver.pem
└── public_keys

Any help on this issue would be greatly appreciated, If you need any more information please ask.

Thank you.

I am running this on a Ubuntu 22.04 server, and the puppet version is 7.28.0.

Answer 1

If the agent is issuing a CSR, then that means it doesn't think it has a valid certificate yet. As described in the Puppet documentation, you shouldn't need to change the agent's configuration file, but you do need to store in the appropriate locations: the agent's cert, the corresponding private key, the cert for the CA that signed it (which must be the same for agent and server), and the CA's CRL (or at least a CRL for the CA).

I can't tell you whether the names and locations in which you've stored the necessary files are correct for your installation, but Puppet can:

• puppet config print hostcert --section agent
• puppet config print hostprivkey --section agent
• puppet config print localcacert --section agent
• puppet config print hostcrl --section agent

If you change --section agent to --section server in those commands then Puppet will tell you where the puppetserver's documents should reside. For server and agent on the same host, the CA cert and CRL might be the same location for server and agent.

IMPORTANT NOTE: execute those commands as the appropriate user. That's root for the agent commands, and the puppetserver user (maybe "puppet") for the server commands.

Do also make sure that the permissions on those files and the directories in the path to them allow the relevant processes to access them. The agent ordinarily runs as root, so there is probably no issue on that side, but the server ordinarily runs as an unprivileged user.