Originally created by @Jellyfrog on GitHub (Nov 28, 2018).
When registering an U2F key (Yubikey) server fails with `Error: NotTrustedAnchor`, which seems to come from here: https://github.com/wisespace-io/u2f-rs/blob/193de35093a44576edba6cc94d9b54f2a1cbdcd1/src/register.rs#L50
At first I thought it was the reverse proxy, but same result using it directly with Rocket.
bitwarden_rs @ 0f6ab01f777700c68aee8fcf0cbf0be742c286e1
web-vault @ v2.5.0
FreeBSD 11.2-RELEASE-p5
Config
```ini
DOMAIN=https://site:8000
ROCKET_TLS={certs="/usr/local/etc/letsencrypt/live/site/fullchain.pem",key="/usr/local/etc/letsencrypt/live/site/privkey.pem"}
````
Log:
```
POST /api/two-factor/get-u2f application/json; charset=utf-8:
=> Matched: POST /api/two-factor/get-u2f
=> Outcome: Success
=> Response succeeded.
GET /images/4.png image/webp:
=> Matched: GET /<p..>
=> Outcome: Success
=> Response succeeded.
POST /api/two-factor/get-u2f-challenge application/json; charset=utf-8:
=> Matched: POST /api/two-factor/get-u2f-challenge
=> Outcome: Success
=> Response succeeded.
GET /app-id.json:
=> Matched: GET /app-id.json
=> Outcome: Success
=> Response succeeded.
PUT /api/two-factor/u2f application/json; charset=utf-8:
=> Matched: PUT /api/two-factor/u2f
Error: NotTrustedAnchor
ERROR: Error activating u2f
=> Outcome: Success
=> Response succeeded.
```
PUT request returns:
```json
{"ErrorModel":{"ExceptionMessage":null,"ExceptionStackTrace":null,"InnerExceptionMessage":null,"Message":"Error activating u2f","Object":"error","ValidationErrors":null},"error":"unknown_error","error_description":"unknown_error"}
```
@Jellyfrog commented on GitHub (Nov 28, 2018):
This is probably due to broken certs in the key;
https://github.com/briansmith/webpki/pull/34#issuecomment-273727506
https://github.com/tstranex/u2f/issues/8#issuecomment-366842256
Will try to verify if this is the case.
Seeing as this is a problem for more people, I'm looking into a possible solution. Checking the other libraries that already deal with this issue, I published a new branch that should hopefully detect it (but not fix it, for now):
And if it detected the cert as one of the broken ones, it would also print Detected broken cert, fixing... (It won't fix anything yet, I want to make sure this is the right way first).
@mprasil Can you get a docker image built, so those using docker can test this issue?
@neoautomata, @Jellyfrog can you check this branch and see if it detects the issue?
@dani-garcia commented on GitHub (Jan 21, 2019):
Seeing as this is a problem for more people, I'm looking into a possible solution. Checking the other libraries that already deal with this issue, I published a new branch that should hopefully detect it (but not fix it, for now):
https://github.com/dani-garcia/bitwarden_rs/tree/trustanchor-fix
Running this should print in the console something like:
```
CERT HASH: [34, 9B, CA, 10, 31, F8, C8, 2C, 4C, EC, A3, 8B, 9C, EB, F1, A6, 9D, F9, FB, 3B, 94, EE, D9, 9E, B3, FB, 9A, A3, 82, 2D, 26, E8]
```
And if it detected the cert as one of the broken ones, it would also print `Detected broken cert, fixing...` (It won't fix anything yet, I want to make sure this is the right way first).
@mprasil Can you get a docker image built, so those using docker can test this issue?
@neoautomata, @Jellyfrog can you check this branch and see if it detects the issue?
The image is just being built, give it about an hour and then you can use mprasil/bitwarden:trustanchor-fix to test it.
@mprasil commented on GitHub (Jan 22, 2019):
The image is just being built, give it about an hour and then you can use `mprasil/bitwarden:trustanchor-fix` to test it.
With Firefox it always works for me, and it returns the same cert each time:
CERT LEN: 561
CERT: b"0\x82\x02-0\x82\x01\x17\xa0\x03\x02\x01\x02\x02\x04\x05\xb6\x05y0\x0b\x06\t*\x86H\x86\xf7\r\x01\x01\x0b0.1,0*\x06\x03U\x04\x0
3\x13#Yubico U2F Root CA Serial 4572006310 \x17\r140801000000Z\x18\x0f20500904000000Z0(1&0$\x06\x03U\x04\x03\x0c\x1dYubico U2F EE Ser
ial 958150330Y0\x13\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\xfd\xb8\xde\xb3\xa1\xedp\xebcl\x06n\xb6\0i\x
....
With Chrome it returns different data each time and never works;
@Jellyfrog commented on GitHub (Jan 24, 2019):
With Firefox it always works for me, and it returns the same cert each time:
```
CERT LEN: 561
CERT: b"0\x82\x02-0\x82\x01\x17\xa0\x03\x02\x01\x02\x02\x04\x05\xb6\x05y0\x0b\x06\t*\x86H\x86\xf7\r\x01\x01\x0b0.1,0*\x06\x03U\x04\x0
3\x13#Yubico U2F Root CA Serial 4572006310 \x17\r140801000000Z\x18\x0f20500904000000Z0(1&0$\x06\x03U\x04\x03\x0c\x1dYubico U2F EE Ser
ial 958150330Y0\x13\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\xfd\xb8\xde\xb3\xa1\xedp\xebcl\x06n\xb6\0i\x
....
```
With Chrome it returns different data each time and never works;
```
CERT LEN: 287
CERT: b"0\x82\x01\x1b0\x81\xc2\xa0\x03\x02\x01\x02\x02\n\x06\xd9\xe5* O8v8\x1f0\n\x06\x08*\x86H\xce=\x04\x03\x020\x151\x130\x11\x06\x
03U\x04\x03\x13\nU2F Issuer0\x1a\x17\x0b0001010000Z\x17\x0b0001010000Z0\x151\x130\x11\x06\x03U\x04\x03\x13\nU2F Device0Y0\x13\x06\x07
*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04\x97\x98>\xc6qRR\xfee\xc7Y\xf3\x8d\xbaz\x84\xe7J\xae\xec\x06\xa1\xb0K#lH
...
```
```
CERT LEN: 287
CERT: b"0\x82\x01\x1b0\x81\xc2\xa0\x03\x02\x01\x02\x02\n \xc8^\xdb\xb3m\xdc\x89\x9e\x070\n\x06\x08*\x86H\xce=\x04\x03\x020\x151\x130\
x11\x06\x03U\x04\x03\x13\nU2F Issuer0\x1a\x17\x0b0001010000Z\x17\x0b0001010000Z0\x151\x130\x11\x06\x03U\x04\x03\x13\nU2F Device0Y0\x1
3\x06\x07*\x86H\xce=\x02\x01\x06\x08*\x86H\xce=\x03\x01\x07\x03B\0\x04m\xdf\xce[\xef\xc7}A\xd3\xc2-\x10e\xdcH\xe2-\x17\xc68}R\t\x8a\\
...
```
Note the different cert length also.
@dani-garcia commented on GitHub (Jan 25, 2019):
This should have been fixed now in https://github.com/dani-garcia/bitwarden_rs/commit/9d027b96d84c25ffef3e3494f69ad655fd3f36f5, hopefully.
Just pulled down :latest and I was able to register one of my keys, but not the other. I think it's the second hash above which didn't work. It does work on Github, so I don't think it's the key.
@neoautomata commented on GitHub (Jan 25, 2019):
Just pulled down `:latest` and I was able to register one of my keys, but not the other. I think it's the second hash above which didn't work. It does work on Github, so I don't think it's the key.
Yes, same NotTrustedAnchor error. I also got a pop up from chrome asking to read make and model of the key, which I've never seen on any site before.
@neoautomata commented on GitHub (Jan 25, 2019):
Yes, same NotTrustedAnchor error. I also got a pop up from chrome asking to read make and model of the key, which I've never seen on any site before.
The popup is expected, it's to avoid Chrome from sending us self-signed certificates instead of the devices actual certificate.
Can you tell me what do you get now running the :trustanchor-fix image with both keys? (Make sure to pull it to use the newest one)
@dani-garcia commented on GitHub (Jan 25, 2019):
The popup is expected, it's to avoid Chrome from sending us self-signed certificates instead of the devices actual certificate.
Can you tell me what do you get now running the `:trustanchor-fix` image with both keys? (Make sure to pull it to use the newest one)
Okay, with some more testing using that cert, I found the cause of the problem, the cert doesn't have an extensions field with a SubjectAltName, and webpki requires it, there is a recent bug about it here: https://github.com/briansmith/webpki/issues/90. This makes sense for SSL certificates, which is what the library was made for, but apparently some U2F devices don't have those required values.
I'm not sure there is something we can do here for now, and I don't think it would be particularly safe for us to try to add a random SubjectAltName whenever we get an error.
@dani-garcia commented on GitHub (Feb 3, 2019):
Okay, with some more testing using that cert, I found the cause of the problem, the cert doesn't have an extensions field with a SubjectAltName, and webpki requires it, there is a recent bug about it here: https://github.com/briansmith/webpki/issues/90. This makes sense for SSL certificates, which is what the library was made for, but apparently some U2F devices don't have those required values.
There is a pending issue for U2F attestation support that mentions that change, but it hasn't seen activity in a while: https://github.com/briansmith/webpki/issues/57.
I'm not sure there is something we can do here for now, and I don't think it would be particularly safe for us to try to add a random SubjectAltName whenever we get an error.
Just bumped into this. The weirdest thing is, I've only seen this upon trying to add a second key to my account - which is weird, as I somehow was able to add the first one :D
Just to make sure I get the whole picture: does this effectively preclude usage of fido u2f until the referenced bugs are resolved?
@yacoob commented on GitHub (Jun 9, 2019):
Just bumped into this. The weirdest thing is, I've only seen this upon trying to add a second key to my account - which is weird, as I somehow was able to add the first one :D
Just to make sure I get the whole picture: does this effectively preclude usage of fido u2f until the referenced bugs are resolved?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Jellyfrog on GitHub (Nov 28, 2018).
When registering an U2F key (Yubikey) server fails with
Error: NotTrustedAnchor, which seems to come from here: https://github.com/wisespace-io/u2f-rs/blob/193de35093a44576edba6cc94d9b54f2a1cbdcd1/src/register.rs#L50At first I thought it was the reverse proxy, but same result using it directly with Rocket.
bitwarden_rs @ 0f6ab01f777700c68aee8fcf0cbf0be742c286e1
web-vault @ v2.5.0
FreeBSD 11.2-RELEASE-p5
Config
Log:
PUT request returns:
@Jellyfrog commented on GitHub (Nov 28, 2018):
This is probably due to broken certs in the key;
https://github.com/briansmith/webpki/pull/34#issuecomment-273727506
https://github.com/tstranex/u2f/issues/8#issuecomment-366842256
Will try to verify if this is the case.
@dani-garcia commented on GitHub (Jan 21, 2019):
Seeing as this is a problem for more people, I'm looking into a possible solution. Checking the other libraries that already deal with this issue, I published a new branch that should hopefully detect it (but not fix it, for now):
https://github.com/dani-garcia/bitwarden_rs/tree/trustanchor-fix
Running this should print in the console something like:
And if it detected the cert as one of the broken ones, it would also print
Detected broken cert, fixing...(It won't fix anything yet, I want to make sure this is the right way first).@mprasil Can you get a docker image built, so those using docker can test this issue?
@neoautomata, @Jellyfrog can you check this branch and see if it detects the issue?
@Jellyfrog commented on GitHub (Jan 22, 2019):
Weirdest thing, I can now register my key.
Will try later on my other laptop where it didn't work...
@mprasil commented on GitHub (Jan 22, 2019):
The image is just being built, give it about an hour and then you can use
mprasil/bitwarden:trustanchor-fixto test it.@neoautomata commented on GitHub (Jan 22, 2019):
Using that Image I get the following in the server logs:
@neoautomata commented on GitHub (Jan 22, 2019):
My other key has a different hash:
@Jellyfrog commented on GitHub (Jan 23, 2019):
Same key, different computer:
@Jellyfrog commented on GitHub (Jan 24, 2019):
With Firefox it always works for me, and it returns the same cert each time:
With Chrome it returns different data each time and never works;
Note the different cert length also.
@dani-garcia commented on GitHub (Jan 25, 2019):
This should have been fixed now in https://github.com/dani-garcia/bitwarden_rs/commit/9d027b96d84c25ffef3e3494f69ad655fd3f36f5, hopefully.
@neoautomata commented on GitHub (Jan 25, 2019):
Just pulled down
:latestand I was able to register one of my keys, but not the other. I think it's the second hash above which didn't work. It does work on Github, so I don't think it's the key.@dani-garcia commented on GitHub (Jan 25, 2019):
Do you still get the NotTrustedAnchor error, or is it something different this time?
@neoautomata commented on GitHub (Jan 25, 2019):
Yes, same NotTrustedAnchor error. I also got a pop up from chrome asking to read make and model of the key, which I've never seen on any site before.
@dani-garcia commented on GitHub (Jan 25, 2019):
The popup is expected, it's to avoid Chrome from sending us self-signed certificates instead of the devices actual certificate.
Can you tell me what do you get now running the
:trustanchor-fiximage with both keys? (Make sure to pull it to use the newest one)@neoautomata commented on GitHub (Feb 3, 2019):
Sorry it has taken me a bit to respond, was out of town.
Here's the error from the lastest
trustanchor-fiximage:@dani-garcia commented on GitHub (Feb 3, 2019):
Okay, with some more testing using that cert, I found the cause of the problem, the cert doesn't have an extensions field with a SubjectAltName, and webpki requires it, there is a recent bug about it here: https://github.com/briansmith/webpki/issues/90. This makes sense for SSL certificates, which is what the library was made for, but apparently some U2F devices don't have those required values.
There is a pending issue for U2F attestation support that mentions that change, but it hasn't seen activity in a while: https://github.com/briansmith/webpki/issues/57.
I'm not sure there is something we can do here for now, and I don't think it would be particularly safe for us to try to add a random SubjectAltName whenever we get an error.
@yacoob commented on GitHub (Jun 9, 2019):
Just bumped into this. The weirdest thing is, I've only seen this upon trying to add a second key to my account - which is weird, as I somehow was able to add the first one :D
Just to make sure I get the whole picture: does this effectively preclude usage of fido u2f until the referenced bugs are resolved?