A new setup by "puppetserver setup ca" results in a incomplete
certificate chain to be served by puppetserver.

| # openssl s_client -connect localhost:8140 -CAfile /var/lib/puppet/ssl/certs/ca.pem -cert /var/lib/puppet/ssl/certs/deb
| ian-sid..pem -key /var/lib/puppet/ssl/private_keys/debian-sid..pem
| CONNECTED(00000003)
| Can't use SSL_get_servername
| depth=2 CN = Puppet Root CA: 327ca764109ce8
| verify return:1
| depth=1 CN = Puppet CA: debian-sid.
| verify return:1
| depth=0 CN = debian-sid.
| verify return:1
| ---
| Certificate chain
|  0 s:CN = debian-sid.
|    i:CN = Puppet CA: debian-sid.
|    a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
|    v:NotBefore: Feb 26 08:40:57 2023 GMT; NotAfter: Feb 23 08:41:02 2038 GMT
| ---

The certifiate chain is:
- Server
- Puppet CA
- Puppet Root Ca

So a server must provide in it's TLS setup:
- Server
- Puppet CA

Only the root CA is left out as trust anchor.

However in this Puppet setup, the server only provides the server
certificate, not the intermediate.

Regards,
Bastian

Hello,

I'm not able to reproduce this issue.

This seems likely to be related to bug #1032060 where the certificate
name of "debian-sid." (with a trailing dot) was found to be the cause of
PKI issues in puppetserver.

Do you think we can close this as a duplicate of that bug?

Thanks,

Okay, then _what_ do you see?

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.

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.

This was worked around long ago, so no.  And then the ca setup would
also be unreliable.

Bastian

Le 2023-03-04 à 03 h 09, Bastian Blank a écrit :

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.
 >

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

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.