A certificate pin mismatch right after gateway sign-in deletes the fresh credential and exits with an explanation.
What's wrong with this entry?
If the first managed-settings request after signing in to an enterprise gateway hits a certificate pin mismatch, the credential that was just stored is deleted from secure storage and the session exits with an explanation instead of leaving a credential behind that will keep failing.
- The fetch extracts the pinned and presented certificate fingerprints into a
gatewayPinMismatchfield. - The exit message names both fingerprints (truncated) and the usual causes: several gateway nodes serving different certificates, or TLS interception on the network path.
- If the credential cannot be removed, a warning is logged and the session still ends.
[gateway-login] could not remove the discarded credential from secure storage
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Signing back into the same account keeps a pending auto-resume
Both mention auth
-
v2.1.234
Token screen reports actual remaining validity
Both mention auth
-
v2.1.234
Setup-token login result carries the expiry
Both mention auth