The "Example JWK Thumbprint Computation" at RFC 7638 - JSON Web Key (JWK) Thumbprint gives a nice example of going from an RS256 password JWK to the HWK SHA-256 Thumbprint value. Is there an example that takes it a step further and shows what the base64url SHA-256 of the keyAuthorization would look like? The example would have to provide its own token, but I could then plug those values into my logic and verify the code is building the same UTF-8 string.
I know it would seem trivial to take it that one extra step but I'm stuck for a day trying to figure out why LE keeps reporting my DNS challenge stays "pending". I've stared at the TXT record from the point of view of my DNS provider, and using 'dig'.I've tried with a P-256 account key and an RSA-2048 account key. I've printed the steps along the way to create the key and value in the TXT record. I believe I'm accounting for trimming leading zero octets when building the JWK. The JWK build does get accepted by LE when creating the account and sending POST-as-GET messages. I've limited myself to using the staging environment. Only my DNS provider side is not staged.
I get the DNS challenge body back with "pending" as the status, whether I send a POST-as-GET with an empty body, a "{}" body, or simply do a 'curl -X GET ' on the DNS challenge url.
Or is there an open source program for Linux or Mac where I can provide the account key and the token and have the value for the TXT record returned? So I could compare with the value(s) I'm creating?
That has nothing to do with how the thumbprint/key authorization is being calculated. The TXT RRs value is either good or it isn't when validating. If the value is incorrect, the LE validation servers error message would literally mention and show that.
To me this sounds more like some other issue. I'm assuming you're writing your own ACME client? I'm reckoning you're not triggering the challenge correctly. Can you show the code with regard to the ACME challenge, it's calculation and triggering?
Thanks for the response. It's Murphy's Law. As soon as I posted my question and went for a cup of coffee my reasoning and question were in jeopardy. Now it works! The last thing I tried seems to be what fixed it for me, but when I tried it before posting, I still got the "pending" status so I didn't think to wait a few seconds and try again (and now I read that I should have at least gotten "processing", not even "pending" so maybe my editor buffer hadn't been saved). I had mistakenly been sending an empty payload for the last day, not an empty structure payload. Big difference between ("") and ("{}"). When I saw your suggestion that it looked like I wasn't triggering the challenge correctly, I went and checked that I was Base64URL encoding the empty structure payload, and I was, but because I added another println to see the payload for myself, and reran, it just worked, now I get "ready" and even "valid"! And reasoning backwards, I see the last thing I did before posting was change the request payload from an empty string to "{}".
So very long winded question and follow up. Sorry. Thanks for the help!!
Yeah, that seems to be a common "gotcha" in client development. "" is POST-as-GET to get status, and {} is POST-to-initiate-action. Glad you figured it out.
(I've moved this post to the "client dev" category, since that seems more appropriate to me.)
