Every remote device is refused with
Connection failed: The environment credential is invalid.
while the host itself keeps working. The trigger is the host's OS locale. The report lists Latvian, Lithuanian, Basque and Azerbaijani hosts breaking while English ones work. This is pingdotgg/t3code#19610.
Why it happens
The shared stringify that builds canonical JSON sorted object keys with localeCompare() and no locale argument, so the sort order follows the host's default locale. RFC 7638 wants keys in code-unit order, and a handful of locales disagree about where certain letters sit. The keys of a DPoP thumbprint input are enough to see it:
const keys = ['crv', 'kty', 'x', 'y']
keys.sort((a, b) => a.localeCompare(b, 'lv'))
// -> ['crv', 'y', 'kty', 'x'], not ['crv', 'kty', 'x', 'y']
The host hashes one string, the client and the cloud hash another, and the credential bound to the real thumbprint fails the comparison. Nothing in the error mentions a locale, so the hunt starts at the network layer.
The fix
Sort keys by code unit, which is what RFC 7638 asks for and what never moves with the machine. PR #19616 switches the stringify to < and > comparisons, and the output is unchanged on English hosts.
Object.keys(obj).sort() // code-unit order, locale independent
The rule is wider than thumbprints. Any canonical JSON that feeds a hash, a signature or a cache key must sort by code unit. A locale-aware comparison is a presentation sort, and using one in a hash input turns the host's regional settings into part of your protocol.