Skip to content

Use fresh account state for ACME auth - #8796

Closed
akshithg wants to merge 2 commits into
letsencrypt:mainfrom
trailofbits:patch/issues-8-9-fresh-account-auth
Closed

Use fresh account state for ACME auth#8796
akshithg wants to merge 2 commits into
letsencrypt:mainfrom
trailofbits:patch/issues-8-9-fresh-account-auth

Conversation

@akshithg

Copy link
Copy Markdown
Contributor

Closes #8795.
Refs #6144.

Use current read-only SA account state when authenticating account-keyed ACME requests that can mutate account, authorization, challenge, order, revocation, or issuance state. This keeps the WFE-local account cache for cacheable account lookups, but avoids relying on cached account status or cached account keys before authorization-sensitive operations.

The fresh path still uses WFE2's existing StorageAuthorityReadOnlyClient; it only bypasses the WFE-local account cache. It does not add direct primary database access from WFE2.

Also purge this WFE's local cached account entry after successful account update/deactivation and key rollover. That purge improves same-WFE freshness, while the authorization boundary is the fresh read-only SA lookup on mutation and issuance paths.

Tests:

  • go test -mod=vendor ./wfe2 -run '^(TestCache|TestWrongId|TestErrorPassthrough|TestValidPOSTForCurrentAccountRejectsCached(DeactivatedAccount|PreRolloverKey))' -count=1 -v
  • go test -mod=vendor ./wfe2 -run '^$' -count=1

@jsha

jsha commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Looks like the CI failures are probably legit:

    key_rollover_test.go:45: rolling over account key: acme: error code 400 "urn:ietf:params:acme:error:malformed": Unable to validate JWS :: JWS signature header algorithm "ES256" does not match expected algorithm "RS256" for JWK

@akshithg

Copy link
Copy Markdown
Contributor Author

@jsha fixed in 29fac42

@akshithg

Copy link
Copy Markdown
Contributor Author

cc @aarongable @beautifulentropy

@beautifulentropy

Copy link
Copy Markdown
Member

cc @aarongable @beautifulentropy

I've reviewed the change and started a discussion with the team about it. I'll get back to you soon, thanks!

@aarongable

Copy link
Copy Markdown
Contributor

I've created a PR to greatly simplify the changes in this PR: trailofbits#1. I think with that simplification in place, it's very likely that this PR will LGTM.

@akshithg

akshithg commented Jul 3, 2026

Copy link
Copy Markdown
Contributor Author

Love the improvement/simplification in trailofbits#1 . Given the CLA, please feel free to move the PR from the trailofbits fork to the original repo. Once merged I can close #8796 as superseded by the new PR.

@aarongable

Copy link
Copy Markdown
Contributor

I've opened #8852 as the combination of this PR plus trailofbits#1

pull Bot pushed a commit to Jankyboy/boulder that referenced this pull request Aug 20, 2026
Delete the code implementing the WFE's in-memory account cache. This
cache was introduced when our primary bottleneck and source of
reliability issues was database reads. We have since improved database
performance in a variety of ways, and this minor reduction in read
volume is no longer necessary. At the same time, the account cache
causes numerous issues: it does not have proper cache invalidation when
accounts change state, and it is not shared across multiple WFE
instances, so it frequently leads to stale reads which can cause
security and correctness issues.

This uncovered a long-standing bug in the integration tests, which had
accidentally been relying upon the WFE account cache to authorize two
consecutive key rollover requests both signed by the same original key.

Fixes letsencrypt#6144
Fixes letsencrypt#8795

Closes letsencrypt#6744
Closes letsencrypt#8132
Closes letsencrypt#8852
Closes letsencrypt#8796

The corresponding production config changes were made in IN-12897.
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.

wfe2: stale account cache can authenticate mutations with old account state

4 participants