mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-07-16 08:54:01 -05:00
[GH-ISSUE #7387] FIDO2/WebAuthn passkey registration fails with DOMException across multiple browsers, OSes, and a fully fixed reverse proxy setup #35648
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @RNZB on GitHub (Jun 30, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7387
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Config:
Vaultwarden Build Version
v1.36.0
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
Traefik 3.3.7
Host/Server Operating System
Linux
Operating System Version
Raspberry Pi OS (Debian-based), linux/aarch64
Clients
Web Vault
Client Version
Web-Vault 2026.4.1
Steps To Reproduce
Expected Result
After clicking "Read key," the browser should prompt to touch the security key, then complete FIDO2 passkey registration successfully, the same way it does on Authentik and other WebAuthn-enabled sites with this same key.
Actual Result
Registration fails immediately with: DOMException: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
On macOS, the browser skips the expected "touch your key" prompt entirely and goes straight to a PIN prompt, which then incorrectly reports the PIN as wrong even though it's independently verified as correct via ykman.
On Windows, registration appears to "succeed," but subsequent login then hangs indefinitely on a spinning loading icon.
This has already been extensively debugged to rule out reverse proxy/config causes — WebSocket routing and security header issues (both confirmed real, separate problems) were found and fixed along the way, and Vaultwarden's own /admin/diagnostics page now reports a fully clean HTTP Response validation. Despite this, the WebAuthn registration failure persists identically across three browser engines (Firefox-based, WebKit, Chromium-based) and two OSes.
Other users have reported what looks like the same symptom specifically on Vaultwarden's own web vault while passkeys work fine elsewhere for them:
Happy to provide further logs, HAR captures, or test against a vanilla non-proxied instance if that would help isolate this further.
Logs
Screenshots or Videos
No response
Additional Context
No response