Fall back to the vendored PEM CA bundle for the system trust store - #558
Open
silug wants to merge 1 commit into
Open
Fall back to the vendored PEM CA bundle for the system trust store#558silug wants to merge 1 commit into
silug wants to merge 1 commit into
Conversation
include_system_store requests from the server (report processors posting to external HTTPS endpoints, and any Puppet.runtime[:http] caller passing the option) stopped trusting publicly-signed certificates in the 9.0.0 betas, failing with PKIX path building errors. This is what broke acceptance/suites/tests/https/client_may_use_external_cert_chains.rb on all platforms in acceptance run 31098859281. Root cause: Puppet::Server::Config.load_puppet_and_system_ssl_context builds the system trust by merging a vendored Java keystore from /opt/puppetlabs/puppet/ssl/puppet-cacerts, and puppet-runtime deliberately stopped shipping that keystore for the 9.x agent (puppet-runtime@066fd48, on the reasonable suspicion it was an unused PE-era artifact -- OpenVox does not package Java). The server was its one consumer; with the file absent the context silently degrades to puppet-CA-only trust with a single warning. Fall back to the PEM CA bundle the runtime still ships at /opt/puppetlabs/puppet/ssl/cert.pem, loaded through the same SSLUtils reader already used for the ssl_trust_store setting. The keystore is still preferred when present, so 8.x-era agents are unaffected. Trust content is identical either way (both forms are generated from the same Mozilla bundle). Verified against openvox-server 9.0.0~beta4 with the 9.0.0~beta2 agent on a local beaker rig: the isolated reproduction (puppetserver ruby fetching https://voxpupuli.org with include_system_store: true) fails with PKIX before and returns 200 after, and the full client_may_use_external_cert_chains.rb acceptance test passes with the patched jar. Longer term this pairs with openvox#554 (stop bundling CA certificates): when that lands, this method should grow a further fallback to the system trust anchors. This change keeps 9.0 compatible with the trust behavior 8.x shipped. Signed-off-by: Steven Pritchard <steven.pritchard@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Draft
bastelfreak
reviewed
Aug 10, 2026
|
|
||
| class Puppet::Server::Config | ||
| PUPPET_KEYSTORE_LOCATION = '/opt/puppetlabs/puppet/ssl/puppet-cacerts' | ||
| PUPPET_CA_BUNDLE_LOCATION = '/opt/puppetlabs/puppet/ssl/cert.pem' |
Contributor
There was a problem hiding this comment.
Personally I think it's better to have a shared truststore for agent and server instead of two. Also handling Java keystores is annoying. But I am wondering if this could lead to any issues.
Contributor
There was a problem hiding this comment.
If we stick to this, we can also remove PUPPET_KEYSTORE_LOCATION
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request (PR) description
include_system_storerequests from the server (report processors posting to external HTTPS endpoints, and anyPuppet.runtime[:http]caller passing the option) stopped trusting publicly-signed certificates in the 9.0.0 betas, failing with PKIX path building errors. This is what brokeacceptance/suites/tests/https/client_may_use_external_cert_chains.rbon all platforms in acceptance run 31098859281.Root cause:
Puppet::Server::Config.load_puppet_and_system_ssl_contextbuilds the system trust by merging a vendored Java keystore from/opt/puppetlabs/puppet/ssl/puppet-cacerts, and puppet-runtime deliberately stopped shipping that keystore for the 9.x agent (puppet-runtime@066fd48, on the reasonable suspicion it was an unused PE-era artifact -- OpenVox does not package Java). The server was its one consumer; with the file absent the context silently degrades to puppet-CA-only trust with a single warning.Fall back to the PEM CA bundle the runtime still ships at
/opt/puppetlabs/puppet/ssl/cert.pem, loaded through the same SSLUtils reader already used for thessl_trust_storesetting. The keystore is still preferred when present, so 8.x-era agents are unaffected. Trust content is identical either way (both forms are generated from the same Mozilla bundle).Verified against openvox-server
9.0.0~beta4with the9.0.0~beta2agent on a local beaker rig: the isolated reproduction (puppetserver ruby fetching https://voxpupuli.org withinclude_system_store: true) fails with PKIX before and returns 200 after, and the fullclient_may_use_external_cert_chains.rbacceptance test passes with the patched jar.Longer term this pairs with openvox#554 (stop bundling CA certificates): when that lands, this method should grow a further fallback to the system trust anchors. This change keeps 9.0 compatible with the trust behavior 8.x shipped.
Generated by Claude Code
This Pull Request (PR) fixes the following issues
N/A