-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "dns-account-01" support from draft-ietf-acme-scoped-dns-challenges #435
Conversation
@aarongable @jsha this change is ready to begin a review. As some of the fixes are unrelated to the direct problem at hand, and possibly controversial, feel free to excise anything that doesn't fit. Also note that the method for passing the additional scoping attributes from WFE to VA seems suboptimal and there may be a better fit for how the Pebble code aligns with Boulder. Any feedback in this area would be greatly appreciated. |
Awesome, I'm exciting to do a full review of this! I'm on vacation this week, but will be able to do a full review on Monday (and other folks should be able to review before then). In the mean time, a bunch of CI improvement and fixes have been landed, so let's get this rebased on top of those / get those merged into this branch so it's just the code changes without accompanying infrastructure changes. |
2923c70
to
ffadbd9
Compare
@aarongable it's only the relevant code changes here. The integration tests have been moved to #444. |
ffadbd9
to
97ea757
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few small nits remaining at the point!
@@ -157,11 +160,13 @@ func New( | |||
return va | |||
} | |||
|
|||
func (va VAImpl) ValidateChallenge(ident acme.Identifier, chal *core.Challenge, acct *core.Account) { | |||
func (va VAImpl) ValidateChallenge(ident acme.Identifier, chal *core.Challenge, acct *core.Account, acctURL string, wildcard bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels slightly awkward to pass both a *core.Account and an acctURL, given that one can be constructed from the other, but also given that the construction method is acctURL := wfe.relativeEndpoint(request, fmt.Sprintf("%s%s", acctPath, newAcct.ID))
and half of those values are inaccessible here in the VA, I think this is fine.
Co-authored-by: Aaron Gable <[email protected]>
b6c0da6
to
25c0824
Compare
// Submit a validation job to the VA, this will be processed asynchronously | ||
wfe.va.ValidateChallenge(ident, existingChal, existingAcct) | ||
wfe.va.ValidateChallenge(ident, existingChal, existingAcct, acctURL, wildcard) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same feedback here: letsencrypt/boulder#7387 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using the KID from the JWT is probably the way to go here.
Good points @aaomidi. Other than that the code looks good to me, and we have an earlier approval from @aarongable. I'm going to land this, and we can explore plumbing the KID from the JWT as a separate PR. |
This change implements the
dns-account-01
ACME challenge as specified in draft-ietf-acme-scoped-dns-challenges.The relevant validation label computation is:
where SCOPE is one of {
host
,wildcard
}. A SCOPE of {domain
} is unimplemented.This implementation is interoperable with the https://github.com/eggsampler/acme changes in eggsampler/acme#21 and passes the
TestWildcardDNSAccount
test.Solves #425.