Repository navigation
fix(ingress): skip the issuance retry when no account was created - #163
Merged
Merged
Conversation
The retry after the CAA write is for a fresh account refused by a CAA naming an earlier one. It checked only that the account was missing before the first attempt, so when that attempt never got as far as creating one -- the CA unreachable, say -- it still ran a second certbot and logged that the CAA now names the new account, which it does not. Also require the account to exist after the first attempt. Signed-off-by: Kevin Wang <wy721@qq.com>
kvinwang
added a commit
that referenced
this pull request
Oct 16, 2026
CAA handling had grown a branch per setup. Plain dns-01 issued, wrote the CAA if SET_CAA, then retried under conditions (#159, #163); delegation ignored SET_CAA and always wrote it; neither checked the CAA in force before asking the CA, except delegation through dnsguide. The retry existed only because the account was created as a side effect of the first order, so the CAA could not name it in time. Now every dns-01 pass runs the same steps: 1. register the ACME account on its own (new `certman.py register`); 2. publish the records, including the CAA pinned to that account when SET_CAA is on -- at the name, or in the delegation zone; 3. check that the CAA in force lets this account issue (new `dnsguide.py --caa-only`; exit 3 only on a definite refusal), so a refusal the CA would give does not cost a failed validation; 4. issue once. SET_CAA means the same thing everywhere. It defaults to true under DELEGATION_ZONE, where anyone else who can write the delegation zone could otherwise pass the delegated challenge, and setting it false there now works, with a warning. A failed CAA write fails the pass in both setups rather than issuing without the pin that was asked for. Since an account now always exists before renewal, certman replaces a lineage when the account it records is gone, instead of when no account exists at all. Signed-off-by: Kevin Wang <wy721@qq.com>
kvinwang
added a commit
that referenced
this pull request
Oct 16, 2026
CAA handling had grown a branch per setup. Plain dns-01 issued, wrote the CAA if SET_CAA, then retried under conditions (#159, #163); delegation ignored SET_CAA and always wrote it; neither checked the CAA in force before asking the CA, except delegation through dnsguide. The retry existed only because the account was created as a side effect of the first order, so the CAA could not name it in time. Now every dns-01 pass runs the same steps: 1. register the ACME account on its own (new `certman.py register`); 2. publish the records, including the CAA pinned to that account when SET_CAA is on -- at the name, or in the delegation zone; 3. check that the CAA in force lets this account issue (new `dnsguide.py --caa-only`; exit 3 only on a definite refusal), so a refusal the CA would give does not cost a failed validation. With SET_CAA the record was just written and resolvers may still cache the one it replaced, so the check waits up to DNS_SETUP_TIMEOUT for it; otherwise it checks once. This is the only CAA gate in dns-01: dnsguide's record check no longer also checks CAA unless asked, as tls-alpn-01 still does; 4. issue once. SET_CAA means the same thing everywhere. It defaults to true under DELEGATION_ZONE, where anyone else who can write the delegation zone could otherwise pass the delegated challenge, and setting it false there now works, with a warning. A failed CAA write fails the pass in both setups rather than issuing without the pin that was asked for. Since an account now always exists before renewal, certman replaces a lineage when the account it records is gone, instead of when no account exists at all. Signed-off-by: Kevin Wang <wy721@qq.com>
kvinwang
added a commit
that referenced
this pull request
Oct 16, 2026
CAA handling had grown a branch per setup. Plain dns-01 issued, wrote the CAA if SET_CAA, then retried under conditions (#159, #163); delegation ignored SET_CAA and always wrote it; neither checked the CAA in force before asking the CA, except delegation through dnsguide. The retry existed only because the account was created as a side effect of the first order, so the CAA could not name it in time. Now every dns-01 pass runs the same steps: 1. register the ACME account on its own (new `certman.py register`); 2. publish the records, including the CAA pinned to that account when SET_CAA is on -- at the name, or in the delegation zone; 3. check that the CAA in force lets this account issue (new `dnsguide.py --caa-only`; exit 3 only on a definite refusal), so a refusal the CA would give does not cost a failed validation. With SET_CAA the record was just written and resolvers may still cache the one it replaced, so the check waits up to DNS_SETUP_TIMEOUT for it; otherwise it checks once. This is the only CAA gate in dns-01: dnsguide's record check no longer also checks CAA unless asked, as tls-alpn-01 still does; 4. issue once. SET_CAA means the same thing everywhere. It defaults to true under DELEGATION_ZONE, where anyone else who can write the delegation zone could otherwise pass the delegated challenge, and setting it false there now works, with a warning. A failed CAA write fails the pass in both setups rather than issuing without the pin that was asked for. Since an account now always exists before renewal, certman replaces a lineage when the account it records is gone, instead of when no account exists at all. Signed-off-by: Kevin Wang <wy721@qq.com>
kvinwang
added a commit
that referenced
this pull request
Oct 16, 2026
CAA handling had grown a branch per setup. Plain dns-01 issued, wrote the CAA if SET_CAA, then retried under conditions (#159, #163); delegation ignored SET_CAA and always wrote it; neither checked the CAA in force before asking the CA, except delegation through dnsguide. The retry existed only because the account was created as a side effect of the first order, so the CAA could not name it in time. Now every dns-01 pass runs the same steps: 1. register the ACME account on its own (new `certman.py register`); 2. publish the records, including the CAA pinned to that account when SET_CAA is on -- at the name, or in the delegation zone; 3. check that the CAA in force lets this account issue (new `dnsguide.py --caa-only`; exit 3 only on a definite refusal), so a refusal the CA would give does not cost a failed validation. With SET_CAA the record was just written and resolvers may still cache the one it replaced, so the check waits up to DNS_SETUP_TIMEOUT for it; otherwise it checks once. This is the only CAA gate in dns-01: dnsguide's record check no longer also checks CAA unless asked, as tls-alpn-01 still does; 4. issue once. SET_CAA means the same thing everywhere. It defaults to true under DELEGATION_ZONE, where anyone else who can write the delegation zone could otherwise pass the delegated challenge, and setting it false there now works, with a warning. A failed CAA write fails the pass in both setups rather than issuing without the pin that was asked for. Since an account now always exists before renewal, certman replaces a lineage when the account it records is gone, instead of when no account exists at all. Signed-off-by: Kevin Wang <wy721@qq.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.
Follow-up to #159, found in the end-to-end run: with the CA unreachable on a fresh start, the first attempt never creates the account, yet the retry still ran a second certbot and logged "retrying now that the CAA record names the new account". Now the retry also requires the account to exist after the first attempt.
Tests:
process_domainstubbed withSET_CAA=trueand no account beforehand: 1 attempt when the first one creates no account, 2 when it does.