Stop using a certificate the signed-in account does not own (GRYT-905)

[sivert-io]

Signed in as test@sivert.io, the desktop client joined community.gryt.chat as Sivert — the owner, who is root@sivert.io. The member list was right. The identity was not.

⚠️ Review-required path: packages/client/src/packages/common/src/auth/.

What was wrong

getValidCertificate checked a cached certificate two ways — not close to expiry, and the JWK inside it still names the keypair on this device. It never checked who the certificate was for, even though parseJwtSub sits in the same file.

answer-challenge.ts then signs the assertion with the sub it reads back out of that certificate:

const certificate = await getValidCertificate();
const sub = getCertificateSub() || "";
const assertion = await signAssertion(sub, challenge.serverHost, challenge.nonce, { kind: "account" });

So the server is handed a real certificate, signed by the CA, for a key the client genuinely holds, naming somebody who is not at the keyboard. Every check the server can make passes. There is no server-side fix for this one.

The two halves drift because they live apart and are cleared by different code — keypair in IndexedDB, certificate in localStorage — and signOut is the only path that takes both. A certificate outlives a session by a wide margin. The file already documented the other direction of this same drift; the guard written for it only compared the key.

The shape

The rule moves to certificate-verdict.ts, which imports nothing. Needing Keycloak, IndexedDB, fetch and a keychain to reach this decision is how it went unchecked long enough to ship.

Four answers rather than two, because the repairs differ:

use	ours, current, matches the key
stale	ours and old — fetch, and leave the old one in place until the new one lands
wrong-key	ours but names a key we no longer hold — drop it
wrong-account	somebody else's — drop it and the keypair under it

What to look at

• Dropping the keypair on wrong-account. This is the part that changes behaviour rather than shape, and the part I am least sure about. The reasoning: a certificate binds one sub to one key, so minting a new one over the previous account's key hands two accounts the same key, and a server that pinned it sees one key arrive under a second name. I believe it is safe to drop — an account key is crypto.subtle.generateKey, random rather than derived; the CA certifies a fresh one on the next sign-in; DM keys come off the seed, which this does not touch. If you would rather keep the key and only re-certify it, that is a one-line change and the check has a case for it.
• stale deliberately not clearing storage. That preserves today's behaviour: a renewal that fails offline should not also cost us the sub that getCertificateSub reads back. It does mean an expired certificate for the current account stays on disk, which it already did.
• Null is not a mismatch. Signed out, session lapsed and Keycloak unreachable all answer null. Treating that as "somebody else" would discard the real user's identity on the strength of a failed token refresh — a worse bug than the one being fixed. Asserted in the check.

Verification

yarn lint (which is tsc -b + eslint) passes. scripts/check-identity-certificate.mjs is new, wired into package.json and CI, and mutation-tested — five mutations, all caught:

mutation
no account check at all (the shipped bug)	caught
account checked after the key and expiry	caught
null signed-in sub treated as somebody else	caught
wrong-account no longer clears the keypair	caught
consumer stops calling certificateVerdict	caught

Not verified end to end. Reproducing the original needs two real Keycloak accounts on one device, which I cannot drive. The diagnosis is read off the source and the reported symptom, and the fix is checked at the unit and source level.

🤖 Generated with Claude Code