Yubikey Bad Signature

[DaveSH12]

Here's the English translation of the provided text:

Hello community, I'm experiencing an issue with Vaultwarden and Yubikey.
We have our own Yubikey authentication server, and my requests are reaching it, but with a BAD_SIGNATURE error.
We've discovered that in the Yubico Validation Protocol Version 2, a signature of the actual request is included in the H parameter.
This is required for authentication. Apparently, Vaultwarden is not sending this signature, causing the server to reject the request.

Has anyone encountered this problem before, or is there perhaps something I need to configure on my end?

I've set the Yubikey variable in the Docker Compose file and also configured it in the admin interface.

Yubikey Settings

  - YUBICO_CLIENT_ID=ABCDEF
  - YUBICO_SECRET_KEY=123456789
  - YUBICO_SERVER=https://ossmfa-qs.testserver.de/ttype/yubikey

I hope anyone here can help me.

Thanks,
Kind regards,
David

[BlackDex]

I'm not sure how any self-hosted/alternative yubikey/yubico OTP Server works.
I just checked where the default is going to, which is api2.yubico.com/wsapi/2.0/verify

You might need to point to the correct verify endpoint for this to work, as you need to provide the full path to the verify URL.

[BlackDex]

Is the ossmfa-qs.testserver.de server using a self-signed certificate?

[DaveSH12]

We have our own CA in our company and our servers are using the certificates, generated by our CA

[BlackDex]

Might be that Vaultwarden doesn't trust this certificate.
What happens if you browse to this https://vw.your-domain.tld/icons/ossmfa-qs.testserver.de/icon.png, you already have DEBUG enabled, that might be enough and see if that generates some error.

Or, if running in a container, try to run curl -v https://ossmfa-qs.testserver.de within the container and see if that generates a certificate error. If that is the case, then i think Vaultwarden doesn't trust that certificate, and you need to add that CA to the trusted CA's

[DaveSH12]

Vaultwarden is running in a Docker Container. I run the curl command within the container.
SSL Certificate seems to be ok.

root@lbavita004:/homes/MGMT/jan-admin# docker exec -it vaultwarden curl -v https://ossmfa-qs.testserver.de

• Trying 10.62.139.47:443...
• Connected to ossmfa-qs.testserver.de (10.XX.XXX.XX) port 443 (#0)
• ALPN: offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
• ALPN: server accepted http/1.1
• Server certificate:
• subject: C=DE; ST=XXXXXXX; L=xxxxxx; O=xxxxxx; CN=ossmfa-qs.testserver.de
• start date: Feb 8 10:30:22 2024 GMT
• expire date: May 13 10:30:22 2026 GMT
• subjectAltName: host "ossmfa-qs.testserver.de" matched cert's "ossmfa-qs.testserver.de"
• issuer: C=DE; O=XXXX; CN=xxxxx CA 04
• SSL certificate verify ok.
• using HTTP/1.1

GET / HTTP/1.1
Host: ossmfa-qs.testserver.de
User-Agent: curl/7.88.1
Accept: /

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• old SSL session ID is stale, removing
  < HTTP/1.1 200 OK
  < Server: nginx
  < Date: Tue, 22 Oct 2024 12:37:36 GMT
  < Content-Type: text/html; charset=utf-8
  < Content-Length: 9543
  < Connection: keep-alive
  < Feature-Policy: geolocation 'none'; midi 'none'; camera 'none'; usb 'none'; magnetometer 'none'; accelerometer 'none'; vr 'none'; speaker 'none'; ambient-light-sensor 'none'; gyroscope 'none'; microphone 'none'
  < Strict-Transport-Security: max-age=15768000
  < X-XSS-Protection: 1; mode=block
  < Referrer-Policy: strict-origin-when-cross-origin
  < Content-Security-Policy: default-src 'self' http: https: ws: wss: data: blob: 'unsafe-inline' 'unsafe-eval'; frame-ancestors 'self';
  < X-Frame-Options: DENY
  < X-Content-Type-Options: nosniff
  <

[DaveSH12]

Hi,
when trying to set OTP via Yubikey (generating 44 signs) in Vaultwarden I always get "Invalid Yubikey OPT Provided".
Wenn only using the 12 chars from the Public Key, I can save the Key. But login after this is not possible.
I don't know it there is an issue with the 44char Key. It seems that Vaultwarden can not save this.

Is Vaultwarden Using the parameter H for the optional HMAC-SHA1 signature for the request.

[DaveSH12]

Hey BlackDex,
I have now some Information from my colleages, regarding the logfiles from our own Authentication Server:

The Request seems to be ok, in this code line the error occurs:
privacyidea/privacyidea/lib/tokens/yubikeytoken.py at 3712c767615691e0928bf9698670bdec29555162

This is the validation algoritm:
https://github.com/privacyidea/privacyidea/blob/3712c767615691e0928bf9698670bdec29555162/privacyidea/lib/tokens/yubikeytoken.py#L79

Can you please take a look to the class, to verify if the validation/signature has any differents on your site?

[BlackDex]

That only thing that i can think of is that the base64 is somehow different which you provide and which is stored in privacyIDEA.
I would double check if everything is 100% exactly the same. Because if the Base64 encoded API_KEY is even one character off, it will break everything.