ACMEv2: Don't echo keyAuthorization (or unmarshal from chal. POSTs)
#3514
Labels
Milestone
Comments
This was referenced Mar 6, 2018
rolandshoemaker
pushed a commit
that referenced
this issue
Mar 6, 2018
This commit updates the RA to make the notion of submitting a KeyAuthorization value as part of the ra.UpdateAuthorization call optional. If set, the value is enforced against expected and an error is returned if the provided authorization isn't correct. If it isn't set the RA populates the field with the computed authorization for the VA to enforce against the value it sees in challenges. This retains the legacy behaviour of the V1 API. The V2 API will never unmarshal a provided key authorization. The ACMEv2/WFEv2 prepChallengeForDisplay function is updated to strip the ProvidedKeyAuthorization field before sending the challenge object back to a client. ACMEv1/WFEv1 continue to return the KeyAuthorization in challenges to avoid breaking clients that are relying on this legacy behaviour. For deployability ease this commit retains the name of the core.Challenge.ProvidedKeyAuthorization field even though it should be called core.Challenge.ComputedKeyAuthorization now that it isn't set based on the client's provided key authz. This will be easier as a follow-up change. Resolves #3514
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Boulder needs to catch up to this recent ACME change: ietf-wg-acme/acme@4bdfe04
The text was updated successfully, but these errors were encountered: