Skip to content

Update ca/crl last_update on HTTP 304 so refresh intervals are respected (#435)#440

Open
SAY-5 wants to merge 1 commit into
OpenVoxProject:mainfrom
SAY-5:fix-ca-refresh-304
Open

Update ca/crl last_update on HTTP 304 so refresh intervals are respected (#435)#440
SAY-5 wants to merge 1 commit into
OpenVoxProject:mainfrom
SAY-5:fix-ca-refresh-304

Conversation

@SAY-5
Copy link
Copy Markdown

@SAY-5 SAY-5 commented May 12, 2026

Fixes #435.

When the CA endpoint responds 304 Not Modified, refresh_ca previously logged "CA certificate is unmodified" but never reset ca_last_update. Since that timestamp is backed by the mtime of ca.pem, and the mtime is only bumped on the 200 path through save_cacerts, in steady state (where 304 is the typical response) the mtime stayed pinned to the initial download. As a result needs_refresh? evaluated to true on every agent run, and the agent issued a conditional GET to the CA every cycle regardless of the configured ca_refresh_interval.

refresh_crl has the same structural issue but is latent in practice because CRL endpoints return 200 often enough that save_crls bumps the mtime naturally. Fixed for symmetry.

Reproduction (from the issue):

puppet agent -t --debug 2>&1 | grep -E 'Refreshing CA|unmodified'

Prior behavior: logs print on every run. With this patch: logs print at the configured ca_refresh_interval (default 24h).

Regression tests added:

  • updates the `last_update` time on 304 Not Modified so ca_refresh_interval is respected
  • updates the `last_update` time on 304 Not Modified so crl_refresh_interval is respected

Both fail without the patch and pass with it. Full spec/unit/ssl/state_machine_spec.rb is green (99 examples).

A 304 Not Modified response confirms the local CA certificate or CRL
is current, so the refresh-interval TTL should be reset. Previously
ca_last_update (backed by ca.pem's mtime) never advanced past the
initial download in steady state, so every agent run saw a stale
mtime and re-issued the conditional GET regardless of
ca_refresh_interval.

The CRL path had the same structural issue but was latent because CRL
endpoints typically respond 200 often enough that save_crls bumps the
mtime naturally. Fix it for symmetry.

Fixes OpenVoxProject#435

Signed-off-by: SAY-5 <say.apm35@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: ca_refresh_interval is not respected — agent refreshes CA on every run when server responds 304

1 participant