Account public key discrepancy

I haven't seen that, and I can confirm that IPv6 doesn't play into the challenge calculation.

1 Like

The challenge response isn't correct here though. The key thumbprint portions (everything after the . in the middle) are different as if the client is getting the thumbprint from the wrong public key. It's a bit easier to see side by side like this.

Br5NVeKTTEgLaPoMCOXuAl-ivmlGBgPxbSvmeO0SKXw.4hOot_D7SDRumLJLG3sciREeT6z7Um0M-l-KsB73Q_E
Br5NVeKTTEgLaPoMCOXuAl-ivmlGBgPxbSvmeO0SKXw.AbVkbPD9c9j2MNbLLQVVhqNJlUdoGnJYME7Sv4A_PXc

Or is that the point and I misunderstood the question?

2 Likes

Well, it's hard to say, right? Because the thumbprint is based on the SHA256 digest of the JWK, the slightest change in the encoding of the same key (just like the original problem) will result in a totally different digest.

I even considered the wildly paranoid theory that Newtonsoft.Json was not deterministically ordering the x,y,crv parameters in the intermediate JWK object before it was hashed ... but that seems to be bunk.

I think @webprofusion might benefit from logging the intermediate JWKs in the key-authz calculation to try chase it down.

1 Like

Yeah so I can see LE thinks we’re giving the wrong response and I’ve given the user an updated version with more detailed logging to check that, but the question was more can LE give that response and have it be from a stale result? The reason I was considering that a possibility was an IPv6 comment on another thread which had a similar response.

Looking at the boulder code it has a couple of methods of fetching the challenge response but I haven’t dug into them to see if they cache anything.

Also could we update the error message in boulder to say which side is which (a!=b requires you to read the boulder code to see which one is which)?

Not that paranoid. I recall when doing stuff in PowerShell I had to explicitly use an "ordered" hashtable (technically OrderedDictionary) over a standard one for things like this to preserve the correct order when serializing to JSON. I'm not sure what Certes is doing under the hood for this. But I'd also assume that if this was the problem, there'd be a lot more cases where things went wrong.

There is probably a very simple mistake at hand or a foot…
Like when you count to any number do you start counting from zero or one?
If you start at zero then the 32nd number is 31.
Which may confuse another app when you request something to be of length/size “31”.
…buried deep in the codes…
No one knows how to “fix it”, so everyone just compensates around it.

Indeed, there’s a simple bug somewhere :slight_smile: I did consider the json serialization order because currently in certes the serialization order attribute is not set on the EcJsonWebKey properties, but usually it’s just the field order from reflection. Hmm.

Just as a follow up to this, the problem with the one user was indeed that the JSON serialisation of the EC Key object representation is happening in a different order (as serialised by .net & newtonsoft JSON.net) on his server, so it turn out this (property reflection order) can vary for some reason in .Net. This is easily fixed, which is great.

1 Like

Wild. Bugs like these makes you regret JOSE’s existence :laughing:.

2 Likes

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