SSO and ADFS. Server returned invalid response: unexpected HTTP status code

[Seekinsj]

I am getting a Server returned invalid response: unexpected HTTP status code.

I have followed the ADFS OIDC setting by Bitwarden. https://bitwarden.com/help/adfs-oidc-implementation/
And tried to adjust it according to the vaultwarden SSO Wiki.

The main difference I believe is that the callback is supposed to be https://your.domain/identity/connect/oidc-signin instead of https://your.domain.com/sso/oidc-signin.

Below is the logs I pulled from my docker container.

vaultwarden | [2025-09-19 15:31:34.750][request][INFO] GET /api/config
vaultwarden | [2025-09-19 15:31:34.767][response][INFO] (config) GET /api/config => 200 OK
vaultwarden | [2025-09-19 15:31:44.019][request][INFO] GET /api/config
vaultwarden | [2025-09-19 15:31:44.019][response][INFO] (config) GET /api/config => 200 OK
vaultwarden | [2025-09-19 15:31:44.031][request][INFO] GET /api/devices/knowndevice
vaultwarden | [2025-09-19 15:31:44.066][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK
vaultwarden | [2025-09-19 15:31:45.616][request][INFO] POST /api/organizations/domain/sso/verified
vaultwarden | [2025-09-19 15:31:45.637][response][INFO] (get_org_domain_sso_verified) POST /api/organizations/domain/sso/verified => 200 OK
vaultwarden | [2025-09-19 15:31:45.659][request][INFO] GET /identity/sso/prevalidate?domainHint=Vaultwarden
vaultwarden | [2025-09-19 15:31:45.671][response][INFO] (prevalidate) GET /identity/sso/prevalidate => 200 OK
vaultwarden | [2025-09-19 15:31:45.702][request][INFO] GET /identity/connect/authorize?client_id=web&redirect_uri=htt
vaultwarden | [2025-09-19 15:31:45.927][response][INFO] (authorize) GET /identity/connect/authorize?<data..> => 307 Temporary Redirect
vaultwarden | [2025-09-19 15:31:59.266][request][INFO] GET /identity/connect/oidc-signin?code="Ideletedthiskeyjustbecause"
vaultwarden | [2025-09-19 15:31:59.276][response][INFO] (oidcsignin) GET /identity/connect/oidc-signin?& => 307 Temporary Redirect
vaultwarden | [2025-09-19 15:31:59.878][request][INFO] POST /identity/connect/token
vaultwarden | [2025-09-19 15:32:02.451][vaultwarden::sso_client][ERROR] Request to user_info endpoint failed: Server returned invalid response: unexpected HTTP status code
vaultwarden | [2025-09-19 15:32:02.452][response][INFO] (login) POST /identity/connect/token => 400 Bad Request
vaultwarden | [2025-09-19 15:32:02.604][request][INFO] GET /api/devices/knowndevice
vaultwarden | [2025-09-19 15:32:02.606][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK

I have vaultwarden behind Nginx Proxy Manager. I am guessing that I am getting the error because I need to do something to NPM.
I have added the below to the custom Nginx Configuration advanced setting.
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_ssl_session_reuse off;

I am wondering if anyone might have an idea if I am headed in the right direction, or might have a suggestion on fixing this issue.

Thank you

[Seekinsj]

I have now tried removing Ngnix Proxy Manager from the equation.

That has not fixed the situation.

I am still getting these errors

vw | [2025-09-19 22:44:27.542][vaultwarden::sso_client][ERROR] Request to user_info endpoint failed: Server returned invalid response: unexpected HTTP status code
vw | [2025-09-19 22:44:27.542][response][INFO] (login) POST /identity/connect/token => 400 Bad Request

[Seekinsj]

If anyone is running into this issue while connecting Vaultwarden to an on-prem ADFS server (or any OIDC provider using an internal Certificate Authority), the root cause is likely an SSL handshake failure.

Because Vaultwarden relies on the underlying Debian OS certificate store inside the container, it doesn't automatically trust certificates issued by an internal ADCS (Active Directory Certificate Services) or other personal CA Server. It quietly drops the connection during the OIDC discovery phase, resulting in the 400 Bad Request or Server returned invalid response errors.

Here is how to fix it by injecting your internal CA into the container's trust store using Docker Compose:

1. Export your Internal CA Chain
   Export your Root CA (and Intermediate CA, if applicable) in Base-64 encoded X.509 format.

If you need to combine a Root and Intermediate CA, concatenate them into a single file called ca-chain.crt.
(Crucial note: If you use the cat command in Linux to combine them, ensure there is a carriage return/blank line at the end of the first certificate so the header and footer don't share the same line, or OpenSSL will reject the whole file).

2. Update your docker-compose.yml
   Place the ca-chain.crt file in your Vaultwarden directory and mount it directly into the Debian ca-certificates folder inside the container.

services: vaultwarden: image: vaultwarden/server:latest container_name: vaultwarden # ... your other configuration ... volumes: - ./vw-data:/data # Map your CA chain into the container's trusted directory - ./ca-chain.crt:/usr/local/share/ca-certificates/ca-chain.crt:ro

3. Update the Container's Trust Store
   Bring your container up (docker compose up -d).

Because the official vaultwarden/server image doesn't automatically process new certificates on boot, you need to manually tell the container's OS to update its trust store. Run this from your Docker host:

docker exec -u root vaultwarden update-ca-certificates

You should see output similar to: 1 added, 0 removed; done.

4. Verify the Connection
   To prove the trust bridge is working, run a curl command from inside the container targeting your ADFS discovery endpoint:

docker exec -it vaultwarden curl -I https://your-adfs-server.com/adfs/.well-known/openid-configuration

If it returns HTTP/1.1 200 OK, the container now fully trusts your ADFS server. Your SSO login flow should now successfully redirect!

(Note: Just remember that due to Bitwarden's zero-knowledge architecture, ADFS only handles authentication. Users will still be prompted for their Master Password to locally decrypt their vault after the SSO token is accepted).