Webauthn Request Failing

[quexten]

Subject of the issue

On the new v1.22.0 image, registering a new Webauthn key does not work.
I am using a Yubikey, and when registering the put request to /api/two-factor/webauthn fails with a 404 400 error.
{"ErrorModel":{"Message":"Webauthn","Object":"error"},"Message":"","Object":"error","ValidationErrors":{"":["Webauthn"]},"error":"","error_description":""}

Deployment environment

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.22.0
• Web-vault version: v2.20.4b
• Running within Docker: true
• Environment settings overridden: true
• Uses a reverse proxy: true
• IP Header check: true (CF-Connecting-IP)
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Time Check: true
• Domain Configuration Check: true
• HTTPS Check: true
• Database type: SQLite
• Database version: 3.35.4
• Install method: Docker vaultwarden/server:1.22.0
• Clients used: For the bug: Web client.
• Reverse proxy and version: Traefik 2.4.8 and Cloudflare.
• MySQL/MariaDB or PostgreSQL version:

Config (Generated via diagnostics page)

Show Running Config

Environment settings which are overridden: WEBSOCKET_ENABLED

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_ip_header_enabled": true,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_max_conns": 10,
  "database_url": "****/**.*******",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*********.*******.***/",
  "domain_origin": "*****://*********.*******.***",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "invitation_org_name": "Quexlabs",
  "invitations_allowed": true,
  "ip_header": "CF-Connecting-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "org_attachment_limit": null,
  "org_creation_users": "",
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": true,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": true,
  "signups_allowed": true,
  "signups_domains_whitelist": "",
  "signups_verify": true,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_explicit_tls": false,
  "smtp_from": "*******.***@*****.***",
  "smtp_from_name": "Bitwarden",
  "smtp_host": "****.**********.***",
  "smtp_password": "***",
  "smtp_port": 587,
  "smtp_ssl": true,
  "smtp_timeout": 15,
  "smtp_username": "*******.***",
  "templates_folder": "data/templates",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": true,
  "websocket_port": 3012,
  "yubico_client_id": "54614",
  "yubico_secret_key": "***",
  "yubico_server": null
}

Steps to reproduce

Register a key with Webauthn. This results in a 404 400 error in the network log, and an error popping up in the web vault.

Expected behaviour

The key should be registered.

Actual behaviour

There was an error message.

Troubleshooting data

[2021-06-28 18:36:09.370][response][INFO] GET /api/accounts/revision-date (revision_date) => 200 OK
[2021-06-28 18:36:40.719][request][INFO] POST /api/two-factor/get-webauthn-challenge
[2021-06-28 18:36:40.910][response][INFO] POST /api/two-factor/get-webauthn-challenge (generate_webauthn_challenge) => 200 OK
[2021-06-28 18:36:45.748][request][INFO] PUT /api/two-factor/webauthn
[2021-06-28 18:36:45.833][error][ERROR] Webauthn.
[CAUSE] InvalidRPOrigin
[2021-06-28 18:36:45.833][response][INFO] PUT /api/two-factor/webauthn (activate_webauthn_put) => 400 Bad Request```

[BlackDex]

I don't see a 404 in the logs.
Cloud you clear/invalidate the Cloudflare cache and try again?
Also maybe try with an Incognito/Private browser/tab

[quexten]

I disabled Cloudflare and made sure my browser isn't connecting through Cloudflare. The issue still occurs. As shown in the troubleshooting data the cause seems to be an "InvalidRPOrigin", but I couldn't find a setting in the admin panel to set the RPOrigin. The rpid sent in the webauthn challenge is the domain that I'm accessing the web vault through though. And I had a typo in the issue above, it should be error 400, not 404.

[BlackDex]

Well that config is linked to the DOMAIN variable.
But it seems that when generating the support string that does seem to be correct.

Could you try to turn on log_level=debug? And check the logs there?

[BlackDex]

Just to be sure.
You do access the site via the browser on the exact same URL, including port, https:// etc... as configured via the DOMAIN config right?

[quexten]

Okay, enabling the debug logging helped track down the issue.
The domain URL I had configured was: https://bitwarden.MY_HOST.com/ while it should have been https://bitwarden.MY_HOST.com (without the trailing slash). Before Webauthn this didn't seem to cause an issue, but the debug log stated that this was the cause for the failure, and changing it fixed it.

Thanks for the help!

[BlackDex]

Ok, good to know, we may need to add some filtering there, or some validation.

[rouben]

I was able to track down the cause of this issue to the following line in webauth.rs:
https://docs.rs/webauthn-rs/0.2.5/src/webauthn_rs/error.rs.html?search=#24
That's line 24. The human comprehensible error message corresponding to InvalidRPOrigin Webauthn error code is "The clients relying party origin does not match our servers information"

So I have a couple of questions/requests:

1. What exactly does this error mean within the context of Vaultwarden? From reading about this error here Rough working login page kanidm/kanidm#417 I tried setting ROCKET_PORT to 443 instead of 80, since my Vaultwarden instance is behind an HTTPS reverse proxy, but that didn't make a difference...
2. It may be a good idea to use the human readable interpretations of Webauthn errors, as defined in error.rs, instead of a generic "Webauthn" error on the Vaultpass web front-end, and [CAUSE] InvalidRPOrigin in the logs.
3. Is there any way to decode the Webauthn internals to see what Webauthn-rs is expecting as its response origin? Poking around in the dark and trying random changes to "fix" things isn't the best approach...

FYI, my config used to work with the old Fido2 API. I am running my instance on Docker, with Rocket bound to port 80, and my reverse proxy doing HTTPS offloading. I also run Vaultwarden under a subpath (URL=https://foobar.example.com/vaultwarden and not URL=https://vaultwarden.foobar.example.com).

[BlackDex]

You can enable debug log_level, that is what the OP did and figured out that he has a / in the end of the DOMAIN variable which was causing this.

You need to make sure that the DOMAIN config matches the domain you use to go to within the browser.

[synaptiko]

I've just had the same issue and I also run my instance under a subpath. But when I set DOMAIN to just a domain without a subpath, then admin interface will stop loading CSS and will become hard to use. Does it mean that we shouldn't be running it under subpath?

[synaptiko]

Should maybe the code here use CONFIG.domain_origin() instead of CONFIG.domain()? I have found out that I cannot reconfigure DOMAIN without a subpath if I want to continue using subpath as after restart I'm getting 404 even on the login page.

[jjlin]

@synaptiko This should be fixed in #1950. Thanks for the report.

[oliverbayer]

Hi, I'm using Vaultwarden since some month. Setting up a webauthn 2FA fails since a couple of weeks with the cause: InvalidRPOrigin.
I'm using VW behind a reverse proxy via sub-domain.

[BlackDex]

The you have not configured your domain correctly.
Check the Vaultwarden Admin Backend /admin/diagnostics and see if there are any errors.

[oliverbayer]

Hey, that easy to solve 😊! Many Thanks. Now it is solved!