mTLS Connectivity for Music Providers

voc0der · April 29, 2025, 12:02pm

Feature description:

Allow providing/uploading a client certificate to authenticate with a source (e.g. subsonic) using mutual tls (mTLS).

Problem solved:

If a service is only available with a client certificate, you cannot access it with Symfonium.

Brought benefits:

This allows people to more securely self host services not on a VPN but with similar security.

Other application solutions:

See:

github.com/bitwarden/android

[PM-16157] Support self-host servers using TLS with Client Authentication (mTLS)

main ← rohm1:PM-15537/mTLS-client-certificate

opened 09:09PM - 17 Dec 24 UTC

rohm1

+1713 -26

## 🎟️ Tracking https://github.com/bitwarden/android/issues/4416 https://bi…twarden.atlassian.net/browse/PM-17240 https://bitwarden.atlassian.net/browse/PM-16157 ## 📔 Objective This PR adds a "Client certificate" menu to the custom environment menu. By clicking on a "Choose" button, the native certificate selection menu will open. User can choose a certificate that will be used for connections to a self-hosted instance. Other apps implement some dynamic logic: if the sever requires mTLS, the user is prompted to select a certificate. While this behavior is more flexible for the user, it is more complicated to implement. With the chosen approach, the app settings must be cleared and a new server must be set up. As users generally do not enable/disable mTLS on a regular basis, I think the tradeoff is acceptable. Additionally the only information that is saved is the certificate name (key alias). If a user update/renew a certificate, as long as the certificate name does not change, the new certificate will be used and there is no need to reset the app. This issue could also be worked around by adding a certificate selection menu to the settings. ## 📸 Screenshots [select-mtls-certificate-complete.webm](https://github.com/user-attachments/assets/f407776d-8ad4-44bf-b451-737afb1857ae) ## Manual tests I did - Upgrade from main does not crash and old settings are still saved/available/used - It is still possible to connect to server without mTLS - A certificate can be selected and saved in the settings. Certificate is used for connections to the server - Close the app and restart: Certificate setting has been persisted and connection is still using mTLS Tested on Android 15 (Pixel 6) and Android 14 (Samsung Galaxy Note 20 Ultra 5G) ## 🦮 Reviewer guidelines - 📝 I am not an Android dev and this is my first time with Kotlin and contributing to the Bitwarden project. While I have tried to follow the architecture, I'm sure I missed some things and and others are not in the right place. I apologize in advance and look forward how to improve the code - ❓ The Android APIs use the _key alias_ wording [(KeyChain.choosePrivateKeyAlias),](https://developer.android.com/reference/android/security/KeyChain#choosePrivateKeyAlias(android.app.Activity,%20android.security.KeyChainAliasCallback,%20java.lang.String[],%20java.security.Principal[],%20java.lang.String,%20int,%20java.lang.String)) and this is also the wording I chose in the code. For the UI I chose to go with _Client certificate_. While this is generally bad to have two wordings for the same thing, _key alias_ cannot be used in the UI because confusing for the user, and _user certificate_ in code is kind of weird because that would be something else that the Android wording. Open for suggestions - 🌱 Following the current approach, we can add a Certificate selection screen to the settings. This way it is not necessary anymore to reset the app to choose a new certificate.

(and more)

Additional description and context:

Thank you!!