Obtain new certificate when renewal's issuer has changed#393
Open
TowyTowy wants to merge 1 commit into
Open
Conversation
When the configured issuer is changed between config reloads (e.g. a different ACME CA), a previously-obtained certificate can remain cached and managed while its stored resources live under the OLD issuer's storage path. Renewal reuses the stored certificate resource, so it looks for the resource only under the currently-configured issuer(s), never finds it (fs.ErrNotExist), and retries in vain until the certificate expires (up to 30 days), leaving auto-renewal stuck. Fix renewCert to detect when no certificate resources exist in storage for any currently-configured issuer and, in that case, obtain a fresh certificate from the current issuer instead of endlessly failing to renew a resource that will never appear. Adds a regression test that reproduces the stuck-renewal state (a cert stored under an old issuer key with a different issuer now configured) and asserts renewal falls back to obtaining from the new issuer. The test fails without this change with the same "no such file or directory" error reported in the issue. Fixes caddyserver/caddy#6732 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
What / why
Fixes caddyserver/caddy#6732. When the configured issuer is changed between config reloads (e.g. switching ACME CA), a previously-obtained certificate stays cached and managed, but its stored resources live under the old issuer's storage path.
renewCertreuses the stored resource and therefore looks for it only under the currently-configured issuer(s), never finds it (fs.ErrNotExist), and retries with backoff until the cert expires — auto-renewal gets permanently stuck. This reproduces the maintainer analysis in the issue by @WeidiDeng.Change
In
renewCert, before attempting renewal, check whether any currently-configured issuer actually has the certificate resources in storage. If none do, there is nothing to renew, so obtain a fresh certificate from the current issuer(s) instead of failing forever. The check runs before lock acquisition and delegates toobtainCert, which re-guards under its own storage lock (idempotent, distributed-safe).Tests
Adds
TestRenewCertObtainsWhenIssuerChanged, which seeds a cert under an old issuer key, reconfigures with a different issuer, and asserts renewal falls back to obtaining from the new issuer. Confirmed it fails without the change with the sameno such file or directoryerror from the issue, and passes with it. Full package suite,go vet, andgofmtare clean.Assistance Disclosure
AI assistance (Claude) was used to investigate the issue, trace the certmagic renewal path, and draft this fix and its regression test. The change and test output have been reviewed and verified for correctness.