Trouble with keyAuthorization for DNS ("Provided key authorization was incorrect") [SOLVED]


This is all on the staging server…

Given a public RSA key:


And a challenge token:


I compute DNS TXT field to be:


And keyAuthorization to be:


When I post to /acme/challenge/$STRING/$NUMBER I post the following JSON body (signed and wrapped the same way as all the other requests that succeed):


Response is:

  "type": "urn:acme:error:malformed",
  "detail": "Unable to update challenge :: Provided key authorization was incorrect",
  "status": 400

Given these inputs, am I supposed to compute something different?


We had a release go to staging today that caused issues and was reverted. If this happened around ~19:00 UTC and isn’t happening anymore then I suspect the bad release was at fault.


Unfortunately I received the Provided key authorization was incorrect response yesterday, and confirmed that is what I’m getting back, again, just now. (I did see the staging release, but that demonstrated itself via 500s)


I’ve also noticed similar problem being reported in the dehydrated repo.


I have now compared the output of my code with go-jose implementation and I can verify that I’m computing the same thumbprint as computed in go-jose jwk_test.go for the key

Is my input incorrect in some way? I don’t understand why “Provided key authorization was incorrect” is what I’m getting.


Hi @tristanls

Can you provide me your registration ID or the domain you’re testing this with? I can check the server-side logs and see if there is any information that might help identify what the problem you’re facing is.


registrationID: 315305,

the challenge I’ve been pounding against:



@cpu I compared what I’ve been doing with certbot/acme/acme/jose … I think I might know what the problem is.

In the input I provided for the n parameter of RSA key:


I use this urlbase64 encoding of the number n to calculate the thumbprint. What I assume your server is doing, and this is what is doing, is that instead of using the provided urlbase64 encoding to calculate the thumbprint, it is parsed into a number, and leading zeros are removed and then encoded into urlbase64, and thumbprint is calculated from that.

When I removed leading zeros, I end up with the same thumbprint as .

Yup… just confirmed that’s the case. I was able to initiate the challenge check.

Java Let's encrypt client problem with jre 1.8
DNS Verification

Hi @tristanls

I’m glad you were able to figure out a solution!

I checked into what Boulder was doing and it does appear that the library we’re using for Jose will strip leading zeroes as you suspected.

Thanks for your patience! I learned something new too :slight_smile:


I opened Issue 275 with dehydrated to help address this for their code base (and to help with the issue you found while debugging).

Thanks again!


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.