Support SSL client certificates for authentication (Subsonic)

Feature requests
1

Feature description:

Symfonium is a great player and supports SSL/HTTPS for many media servers, in particular SubSonic (with Navidrome) for self-hosting.

However, Symfonium does not support SSL client certificates to authenticate the client to the server. As an additional layer of security before exposing services to the Internet, this would be desirable.

NOTE that this is different from basic SSL/TLS support and server-side certificates! That all works fine and is about the server authenticating to the client; this is about the client authenticating to the server at the SSL/TLS layer.

While my request is specifically about Subsonic, I’d assume other media providers using HTTPS transport (such as Jellyfin) would also benefit.

Problem solved:

For example nginx can be configured with with ssl_verify_client on;, which will enforce client certificate checking before the connection is passed on to the service.

This is supported by a variety of other clients on Android; e.g., the Nextcloud app, the Home Assistant companion app, and of course Chrome itself.

These apps will then allow the user to select a client certificate from the system and use it for the HTTPS connection.

With Symfonium however, enabling the client certificate checks results in “Http error: 9890” in Symfonium when adding the service, and an error message such as

1.2.3.4 - - [2024-02-25T18:48:27+01:00] “GET /rest/ping.view?u=test&p=test&v=1.13.1&c=Symfonium HTTP/1.1” 400 255 “-” “Symfonium/9.0.0 (Linux;Android 14)” “media.mydyndns.info” “192.168.1.2:443” “gz:-”

in nginx logs.

Client side certificate checking is otherwise completely transparent to the media provider’s service, since it’s entirely handled by the reverse proxy setup.

(Accessing the media service through it’s web client works fine, even with the client certificate, since Chrome’s HTTPS handling supports client side certificates. Symfonium works fine if client certificates are disabled.)

Brought benefits:

This would improve security for self-hosted services considerably. It provides an additional layer of security over the media service itself and shields it from attacks.

Other application solutions:

 
Chrome, Nextcloud, Home Assistant Companion app are some examples of Android apps which support this feature.

Jellyfin’s client for example do not support this either, and this would be another competitive win for Symfonium.
 

Additional description and context:

 

This is the original commit that added relevant support to Home Assistant’s Android app: TLS Client Authentication Support (#2526) · home-assistant/android@bf5a983 · GitHub
 

Screenshots / Mockup:

    

2

I thought the OS would automatically pick the right one if the subjects matches.

Any reason the custom headers are not enough for such kind of usage?

This kind of auth is a pain for apps that can cast to other devices or transcode via ffmpeg and all the different things that needs different ways to handle this or just can’t.

3

The OS apparently doesn’t by itself, see the Home Assistant code as well. The app needs to invoke the right method.

Ouch. I hadn’t considered Cast in full (or rather, misunderstood how it worked) :-/ Indeed, the supported streaming protocols don’t include this HTTPS feature either it seems.

4

HA is a webview, it’s easy to add the cert at one place :slight_smile: Symfonium have tons of different components that needs that with some that can’t, so not really comparable.

Honestly there’s little chance that I add this due to to the side effects and amount of work for little gain and broken things leading to support.

5

After considering Cast in particular, I think you’re right. It’d be one thing to just do local playback, but the way that works is impractical.

Thanks for the response, however! That’s really outstanding.

Looks like what I’ll be doing instead is amending the Navidrome docs with a snippet explaining how using client certs limits the use of players.