Connecting to a server with TLS Client Authentication crashes app

[gRWNCB0OuEbPryspm82L34rtVjif1NtOrU7rLBW]

Hello,

When connecting to a Bitwarden server that's behind an nginx proxy that requires a client cert, the app just crashes when pressing the Log In button. The same server works fine on Firefox, requesting access to my certificate as expected, and when I disable the requirement to have client authentication through my reverse proxy, the app works fine too. I see this is a known issue based on a few forum posts (https://community.bitwarden.com/t/client-certificates/427, https://community.bitwarden.com/t/mobile-app-cant-access-server-behind-reverse-proxy-with-client-cert-authentification/2071 etc) so thought I'd raise an issue.

[8CNE0UERGm7r87wrrXoBqbil23FnE7WupZlWEKR]

1) Android version

Android 13 LineageOS 20 custom rom , rooted

2) How the cert you picked from system certs installed into there?

Settings >security>encryption and cedentials>install a certificate

The changes doesn't support install a cert into system cert store but it supports use installed ones

Sorry if I wasn't clear. Thats what I meant. Entered my email selected selfhosted under region Continue Advanced There are two options under udvanced

• Import and use a new certificate
• use a system certificate

It is the second option that is failing

Also I forgot to mention that I have to clear app data after that to be able to use the app again

Error on logcat

ANR in com.x8bit.bitwarden (com.x8bit.bitwarden/.MainActivity)
PID: 11537
Reason: Input dispatching timed out (7dec55b com.x8bit.bitwarden/com.x8bit.bitwarden.MainActivity (server) is not responding. Waited 5002ms for MotionEvent)
Parent: com.x8bit.bitwarden/.MainActivity
ErrorId: c6b0539b-84e5-4e5a-84a4-98e40cdcd43f
Frozen: false
Load: 5.08 / 6.51 / 6.4
CPU usage from 1ms to 13916ms later (2023-07-20 18:23:04.612 to 2023-07-20 18:23:18.527):

!

3) The cert format in system cert store?

It is a pkcs 12 bundle

the certificate you select from system cert should had been instlled with the private key

Yes

sudo openssl pkcs12 -info -nodes -in /storage/emulated/0/certs/client_cert.p12

MAC: sha256, Iteration 2048
MAC length: 32, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Certificate bag
Bag Attributes
    localKeyID:reducted
subject=C = gr, ST = gr, L = gr, O = client-cert, OU = ippo, CN = client-cert, emailAddress = reducted
issuer=C = gr, ST = gr, L = gr, O = client-cert, OU = ippo, CN = client-cert, emailAddress = reducted
-----BEGIN CERTIFICATE-----
Reducted
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Bag Attributes
    localKeyID: reducted
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
Reducted
-----END PRIVATE KEY-----

if you install a cert in pkcs#12 legacy format to system cert store and then, use it on the app, do you still getting issue?

The "original" pkcs12 cant be saved in the android system store It is password protected and the system can't decrypt the password

The legacy cert is installed on android certificate store And the one that crashes the app if the second option is used (as described above)

[INJCfSaaW0WAY4Nih2WCxK9C8YObEXjHUXZuce8]

I'm able to install a certificate to system store and use it from the app. The system was able to decrypt the cert and the app can pick this one up to use. # 1 # 2 # 3 # 4

$ openssl pkcs12 -info -nodes -in client.b.pfx

MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
...
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

I think the issue here seem to be either your cert's encryption type not supported or related to LineageOS.

Following is commands i use to generate client certificate from ca. it produces pem file. you have to convert to pfx that recognized by Android.

$ openssl version
OpenSSL 1.1.1l  24 Aug 2021

  openssl genrsa -out client.key 2048
  openssl req -new -key client.key -days 3650 -out client.csr \
    -subj "/C=SO/ST=Earth/L=Mountain/O=$O/OU=$OU/CN=localhost"
  openssl x509  -req -in client.csr \
    -extfile <(printf "subjectAltName=DNS:localhost") \
    -CA ca.crt -CAkey ca.key -out client.crt -days 3650 -sha256 -CAcreateserial
  cat client.crt client.key > client.pem

[mzpqnxow]

5 years later, with both ad-hoc patches/code and formal PRs submitted by various contributors, and we're back at square one... this is a bummer

Trying my best to be constructive, rather than give up:

1. Is there a "proper" way to get on a roadmap for Bitwarden Mobile?
2. Failing that, is there a way to receive a formal acknowledgment that "yes, Bitwarden would like to have this if it was contributed"?

I can't see any sane user committing time to another PR, only to have it neglected or ultimately withdrawn/closed

At the risk of sounding harsh or critical- I have to say that I'm shocked at the strength and persistence of the apathy with regard to this feature

I do understand that Bitwarden is, for many, many people, a free (or "budget") solution. As such, I suspect that even if every individual on this GH issue was a paying customer, the revenue would barely amount to more than a few hours of developer/UX time. So on the one hand, the progress here is very easily understandable. Bitwarden is a business, and developer hours are zero sum; I think all reasonable people understand this

But at the same time, as a project/product that has dramatically improved the collective security posture of Internet users and organizations, it's disappointing that a feature that provides strong authentication (and, perhaps more important for security-minded organizations- attack surface reduction) has gone nowhere

Pardon the unsolicited ranting

It would be great to see this start to move again, but I'm not holding my breath

I won't spam the issue any further. I felt I had to contribute the last $0.02 I had left on this topic 😊

Finally- thank you to everyone (including those at Bitwarden - I know everyone is doing their best) who helped to move this along over the years. You are appreciated, despite this ending up where it started

[quaintdev]

They are rewriting both iOS and Android client. Here is the repo for Android.

It looks like this issue(https://github.com/bitwarden/android/issues/582) was opened on the new repository but it was closed stating the issue will be moved to this repository. Now I have no idea what the intention is here

1. Support mTLS on this old version of Bitwarden?
2. It will not be supported on newer versions?
3. It will not be supported at all?

This is open since 2019. Can we at least make a decision and let the users move on if it's not going to be supported?