[PM-39577] Pm 39573/mtls client certificate chain - #2833
Open
jalenfran wants to merge 3 commits into
Open
Conversation
Add keychain storage for the intermediate certificates associated with a client certificate, keyed by the certificate fingerprint. This backs the mTLS handshake change that presents the full certificate chain to servers that trust only the root CA.
When answering a client-certificate TLS challenge, the app presented only the leaf certificate. A reverse proxy that trusts only the root CA cannot build leaf -> intermediate -> root from the leaf alone and rejects the handshake, even though browsers and the Android app succeed with the same certificate by sending the full chain from the PKCS#12 file. Extract the intermediate certificates when importing a certificate, persist them alongside the identity, and include them in the URLCredential used for both API requests and vault icon loading. The chain is best-effort: a certificate without stored intermediates still presents the leaf alone, so existing single-certificate setups are unaffected.
Collaborator
|
Thank you for your contribution! We've added this to our internal tracking system for review. Details on our contribution process can be found here: https://contributing.bitwarden.com/contributing/pull-requests/community-pr-process. |
bitwarden-bot
changed the title
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🎟️ Tracking
📔 Objective
Fixes mutual TLS (client certificate) authentication failing against a self-hosted server when the reverse proxy is configured to trust only the root CA.
Root cause: When answering a client-certificate TLS challenge, the app presented only the leaf certificate (the credential was built with no additional certificates). A reverse proxy that trusts only the root CA cannot build
leaf → intermediate → rootfrom the leaf alone, so it rejects the handshake. Browsers and the Android app send the entire chain from the PKCS#12 file, which is why the same certificate and server work there but the iOS app fails with "This is not a recognized Bitwarden server." The failure affected both API requests and vault item icon loading, since both go through the client-certificate challenge.Fix:
URLCredentialpresented for client-certificate challenges, for both API requests (CertificateHTTPClient) and vault icon loading (CipherIconImageLoader).Backward compatibility: The chain is best-effort. A certificate with no stored intermediates still presents the leaf alone, so existing single-certificate setups are unaffected and already-imported certificates keep working with no re-login or re-import required. Users on a root-only proxy gain the fix automatically the next time they re-import their certificate.
Testing: