Repository navigation
refactor(ingress): one CAA flow for every dns-01 setup - #167
Merged
Merged
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| match = re.match(r"\s*account\s*=\s*(\S+)", line) | ||
| if match: | ||
| recorded = match.group(1) | ||
| except OSError: |
kvinwang
force-pushed
the
refactor/ingress-caa-flow
branch
3 times, most recently
from
October 16, 2026 02:53
0403227 to
7714c81
Compare
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
force-pushed
the
refactor/ingress-caa-flow
branch
from
October 16, 2026 02:56
7714c81 to
a89d1c8
Compare
Collaborator
Author
|
End-to-end, PR scripts mounted on the 2.8 image (
Pebble does not enforce CAA, so refusals are judged by the container's check. |
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
2 participants
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.
Supersedes #166.
Why
CAA handling differed per setup, and
SET_CAAmeant different things:SET_CAASET_CAA(#159, #163)SET_CAAignoredThe retry existed only because the account was created by the first order, too late for the CAA to name it.
What
Every dns-01 pass: register the account (
certman.py register) → publish records, with the CAA pinned to the account whenSET_CAA(at the name, or in the delegation zone) → check the CAA in force (dnsguide.py --caa-only, exit 3 only on a definite refusal) → issue once.SET_CAAdefaults totrueunderDELEGATION_ZONE;falsethere now works, with a warning that anyone who can write the delegation zone can get certificates.Tests
--caa-only, replaced-account re-obtain);test_sanitizers.sh; shellcheck nothing new.process_domainstubbed: plain with/withoutSET_CAA, wildcard, delegation with default andSET_CAA=false, CAA refusal, failed registration — each runs the expected steps.