Le 2023-03-04 à 03 h 09, Bastian Blank a écrit :
On Fri, Mar 03, 2023 at 04:04:55PM -0500, Jérôme Charaoui wrote:
I'm not able to reproduce this issue.
Okay, then _what_ do you see?
I'm seeing puppetserver generate its CA without errors, it's able to
sign agent signing requests and agents are able to retrieve their
catalogs from the server (including the server node itself) without any
kind of PKI errors or issues.
Easy check:
| # grep BEGIN /etc/puppet/puppetserver/ca/ca_crt.pem
/etc/puppet/puppetserver/ca/signed/*
| /etc/puppet/puppetserver/ca/ca_crt.pem:-----BEGIN CERTIFICATE-----
| /etc/puppet/puppetserver/ca/ca_crt.pem:-----BEGIN CERTIFICATE-----
| /etc/puppet/puppetserver/ca/signed/debian-sid.home.arpa.pem:-----BEGIN
CERTIFICATE-----
>
The CA file must only include one certificate, the trust root. The
entity file needs to contain two: the intermediate CA and the entity
cert.
In a Debian container with the upstream Puppetlabs agent/server
packages, running "puppetserver ca setup" results in a similiar (and
working) certificate setup as seen with the Debian packages.
The upstream documentation is light on details (it doesn't mention the
intermediate cert anywhere...) but it doesn't otherwise appear to
suggest that what we're seeing is wrong:
https://www.puppet.com/docs/puppet/7/dirs_ssldir.html
And using openssl:
| # openssl s_client -connect localhost:8140 -CAfile
/var/lib/puppet/ssl/certs/ca.pem -cert
/var/lib/puppet/ssl/certs/debian-sid.home.arpa.pem -key
/var/lib/puppet/ssl/private_keys/debian-sid.home.arpa.pem
| CONNECTED(00000003)
| Can't use SSL_get_servername
| depth=2 CN = Puppet Root CA: 74ab090112e6f0
| verify return:1
| depth=1 CN = Puppet CA: debian-sid.home.arpa
| verify return:1
| depth=0 CN = debian-sid.home.arpa
| verify return:1
| ---
| Certificate chain
| 0 s:CN = debian-sid.home.arpa
| i:CN = Puppet CA: debian-sid.home.arpa
| a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
| v:NotBefore: Mar 3 08:01:08 2023 GMT; NotAfter: Feb 28 08:01:12 2038 GMT
| ---
The certificate chain needs to contain two certificates, the entity one
and the intermediate CA, otherwise it's incomplete.
If the cert chain is indeed incomplete, we would see verification
errors, no? Is this what you're encountering?
Are you facing any failures in agent/server communications because of
this? Any logs or errors messages you could share?
Thanks.
-- Jérôme
