Is this a critical security issue?
Describe the Bug
puppet ssl renew_cert exits 0 and prints nothing when the CA refuses the renewal request, so an operator (or a cron job) has no way to notice that the renewal did not happen.
When allow-auto-renewal is not enabled on the CA (the packaged ca.conf ships it as false), the certificate_renewal endpoint returns 404. The renew_cert action rescues that 404 and returns nil without any message, even with --verbose, and exits 0 (lib/puppet/application/ssl.rb, the rescue Puppet::HTTP::ResponseError branch in renew_cert).
The background renewal path handles the same case better: NeedRenewedCert in lib/puppet/ssl/state_machine.rb logs Certificate autorenewal has not been enabled on the server. at info level on a 404. The explicit CLI action, where the user has specifically asked for a renewal, says nothing at all.
Expected Behavior
When the user explicitly runs puppet ssl renew_cert and the server refuses or does not support renewal, the command should say so and exit nonzero, for example:
Error: The server does not allow certificate renewal (is allow-auto-renewal enabled in ca.conf?)
Silently swallowing the 404 makes sense for the background agent-run path (older servers without the endpoint should not produce warnings on every run), but the explicit action should report the outcome so scripts and operators can tell renewal apart from a no-op.
Steps to Reproduce
On a default openvox-server install (packaged ca.conf, allow-auto-renewal: false) with an enrolled agent holding a valid certificate:
agent# puppet ssl renew_cert --verbose; echo exit=$?
exit=0
agent# openssl x509 -enddate -noout -in "$(puppet config print hostcert)"
notAfter=Aug 10 11:06:16 2031 GMT # unchanged
No output, exit 0, certificate not renewed. After setting allow-auto-renewal: true on the CA and restarting, the same command renews as expected:
agent# puppet ssl renew_cert
Notice: Downloaded certificate 'voxagent.test' with fingerprint (SHA256) 1F:32:44:41:...
Environment
- Version: openvox-agent 8.28.1, openvox-server 8.15.2 (packaged ca.conf defaults)
- Platform: Ubuntu 24.04
Additional Context
Found while container-verifying the certificate renewal documentation (OpenVoxProject/openvox-docs#447; the collapsed transcript there includes this reproduction). Related: OpenVoxProject/openvox-server#560 proposes shipping allow-auto-renewal: true, which would make the silent path rarer but not fix it; the CLI would still hide genuine refusals from older or differently configured servers.
Relevant log output
agent# puppet ssl renew_cert --verbose; echo exit=$?
exit=0
Is this a critical security issue?
Describe the Bug
puppet ssl renew_certexits 0 and prints nothing when the CA refuses the renewal request, so an operator (or a cron job) has no way to notice that the renewal did not happen.When
allow-auto-renewalis not enabled on the CA (the packaged ca.conf ships it asfalse), thecertificate_renewalendpoint returns 404. Therenew_certaction rescues that 404 and returnsnilwithout any message, even with--verbose, and exits 0 (lib/puppet/application/ssl.rb, therescue Puppet::HTTP::ResponseErrorbranch inrenew_cert).The background renewal path handles the same case better:
NeedRenewedCertinlib/puppet/ssl/state_machine.rblogsCertificate autorenewal has not been enabled on the server.at info level on a 404. The explicit CLI action, where the user has specifically asked for a renewal, says nothing at all.Expected Behavior
When the user explicitly runs
puppet ssl renew_certand the server refuses or does not support renewal, the command should say so and exit nonzero, for example:Silently swallowing the 404 makes sense for the background agent-run path (older servers without the endpoint should not produce warnings on every run), but the explicit action should report the outcome so scripts and operators can tell renewal apart from a no-op.
Steps to Reproduce
On a default openvox-server install (packaged ca.conf,
allow-auto-renewal: false) with an enrolled agent holding a valid certificate:No output, exit 0, certificate not renewed. After setting
allow-auto-renewal: trueon the CA and restarting, the same command renews as expected:Environment
Additional Context
Found while container-verifying the certificate renewal documentation (OpenVoxProject/openvox-docs#447; the collapsed transcript there includes this reproduction). Related: OpenVoxProject/openvox-server#560 proposes shipping
allow-auto-renewal: true, which would make the silent path rarer but not fix it; the CLI would still hide genuine refusals from older or differently configured servers.Relevant log output