Repository navigation
fix(ingress): retry a failed dns-01 issuance only after a new account - #159
Merged
Merged
Conversation
This was referenced Oct 16, 2026
kvinwang
force-pushed
the
fix/ingress-serve-first
branch
from
October 16, 2026 01:09
f2c5e0f to
9e8cf69
Compare
kvinwang
force-pushed
the
fix/ingress-issue-retry
branch
2 times, most recently
from
October 16, 2026 01:20
140173f to
829d9fa
Compare
kvinwang
force-pushed
the
fix/ingress-serve-first
branch
from
October 16, 2026 01:20
9e8cf69 to
8f49c1a
Compare
kvinwang
force-pushed
the
fix/ingress-issue-retry
branch
from
October 16, 2026 01:20
829d9fa to
ec5a04b
Compare
kvinwang
force-pushed
the
fix/ingress-serve-first
branch
from
October 16, 2026 01:20
8f49c1a to
c5e01e2
Compare
kvinwang
force-pushed
the
fix/ingress-issue-retry
branch
from
October 16, 2026 01:23
ec5a04b to
4f30b0a
Compare
kvinwang
force-pushed
the
fix/ingress-serve-first
branch
from
October 16, 2026 01:23
c5e01e2 to
bd162d4
Compare
kvinwang
force-pushed
the
fix/ingress-issue-retry
branch
from
October 16, 2026 01:25
4f30b0a to
88b936b
Compare
kvinwang
force-pushed
the
fix/ingress-serve-first
branch
from
October 16, 2026 01:25
bd162d4 to
7eb3401
Compare
process_domain retried every failed issuance once, after writing the CAA. The retry exists for one case: a fresh account refused by a CAA record naming an earlier one, which set_caa_record has just replaced. For any other failure it doubled the failed validations, so a domain that keeps failing reached Let's Encrypt's limit of five per hostname per hour within three passes. Retry only when the first attempt had to create the account and this container manages the CAA. Also drop the status 2 -> 0 mapping after the retry: run_pass already detects a saved certificate by checksum. Signed-off-by: Kevin Wang <wy721@qq.com>
kvinwang
force-pushed
the
fix/ingress-serve-first
branch
from
October 16, 2026 01:27
7eb3401 to
f01040e
Compare
kvinwang
force-pushed
the
fix/ingress-issue-retry
branch
from
October 16, 2026 01:27
88b936b to
d651b61
Compare
This was referenced Oct 16, 2026
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.
Why
process_domainretried every failed issuance once, after writing the CAA. The retry exists for one case: a fresh ACME account refused by a CAA record naming an earlier one, whichset_caa_recordhas just replaced. For any other failure it doubled the failed validations, so a domain that keeps failing hit Let's Encrypt's limit of 5 per hostname per hour within three passes.What
DELEGATION_ZONEorSET_CAA=true).run_passalready detects a saved certificate by checksum.Tests
Pebble end-to-end results will follow in a comment.
Stacked on #158.