Client Base Authentication (MTLS)

[xxxAyxxx 6]

Hello Support Team,

First of all, Thank you for a grate product.

I have been using emby for the last couple of years after trying all the other competitors apps (Kodi, Jellyfin & Plex) It's clean, simple to use and just works!

My main issue now is regarding security, I'm publishing my server using reverse proxy (as most) and I have no way of protecting against unwanted access.

I do use signed public certificate on the server & proxy and I'm interested of utilize MTLS so only clients with allowed certificate will gain access to the server through the proxy.

As was mentioned previously on this post

Most platform supports Client Base Authentication (Mobile, PCs & most TVs) and the missing ingredient is Clients Apps support.

I'm sure a lot of emby users will be glad to add protection to there servers in order to defend from unwanted/malicious access.

[Luke 43418]

Hi, this will depend on platform support, but for the platforms that do support it, yes we can look into it in future updates. Thanks.

[Pr0xyZer0 0]

 

Hello, is there anything new on the subject of mTLS? I'm considering switching from Plex to Emby but I can't get mTLS to work in the client apps for Android. Does this only work on the web?

[Luke 43418]

8 hours ago, Pr0xyZer0 said:

 

Hello, is there anything new on the subject of mTLS? I'm considering switching from Plex to Emby but I can't get mTLS to work in the client apps for Android. Does this only work on the web?

Hi, not yet, sorry, but it remains possible for future updates. Thanks.

[athes 0]

Hi Luke,

How are the features prioritized?
Is there a way for the community to vote or donate for specific features to bump them up in your list?

Thx

Edited November 16, 2024 by athes

[ebr 16946]

3 hours ago, athes said:

Is there a way for the community to vote or donate for specific features to bump them up in your list?

 

[Luke 43418]

8 hours ago, athes said:

Hi Luke,

How are the features prioritized?
Is there a way for the community to vote or donate for specific features to bump them up in your list?

Thx

Hi, it's based on user interest level.

[berrmal 1]

On 11/16/2024 at 2:58 PM, Luke said:

Hi, it's based on user interest level.

Hi Luke,

Add me to the list of interested.  I created a community account just to let you know. 

I think over the next several years mtls is going to be very important for any service.  Many large orgs are already moving in that direction.

[ctn06675 2]

I too would love to see this feature added.

[kamiya344 1]

I’d also like to see mTLS support.

With AI-powered attacks so common these days, I really don’t want to expose an application running on my home network to the internet without any protection.

If you’re not going to support mTLS, then please at least offer a hosted proxy service for remote streaming connections, like Plex does—even if it’s only available to Premiere users.

[sh0rty 811]

Now that Pangolin supports mTLS per Ressource, I would ditch my custom header feature request in favor of this mTLS request.
Compared to set a custom header for every ressource, Emby just needs to implement support for importing a mTLS certificate in his Apps like Immich does and send it with the requests.
With this, the days are over where open paths etc. are needed to reach Emby behind Reverse Proxies with additional auth tools. @Luke

Obsolete:

 

Edited 18 hours ago by sh0rty

[howllor 53]

+1

[OSBuckeyes4Life 12]

Adding my interest in this. I’d like to put Emby behind a reverse proxy that requires a client certificate, while keeping normal Emby account authentication afterward.

Could you outline which client platforms could support this—particularly iOS, Android and Apple TV—and any platform limitations? Importing a password-protected certificate, storing its private key securely, and supporting certificate renewal/replacement would make this practical for household devices.

It would also be important for the certificate to work across the complete playback path: API calls, artwork, streaming segments, downloads and WebSocket connections—not just the initial login. Can the native players and background download components all use the same certificate identity?

For platforms where this isn’t feasible, clear documentation would help us design remote access appropriately. Is this something that could be considered for a future release?

[sh0rty 811]

1 hour ago, OSBuckeyes4Life said:

Adding my interest in this. I’d like to put Emby behind a reverse proxy that requires a client certificate, while keeping normal Emby account authentication afterward.

Could you outline which client platforms could support this—particularly iOS, Android and Apple TV—and any platform limitations? Importing a password-protected certificate, storing its private key securely, and supporting certificate renewal/replacement would make this practical for household devices.

It would also be important for the certificate to work across the complete playback path: API calls, artwork, streaming segments, downloads and WebSocket connections—not just the initial login. Can the native players and background download components all use the same certificate identity?

For platforms where this isn’t feasible, clear documentation would help us design remote access appropriately. Is this something that could be considered for a future release?

You create a CA and create Client certs with it (e.g. with VaulTLS as UI or vial cli and plain openssl). I create a mTLS cert for every device personally, e.g Phone, Laptop, Gaming PC, Iphone etc. But could also use one cert for all of your devices technically. Emby account authentication stays intact as mTLS just is the gatekeeper for the initial connection between Reverse Proxy and the Client before everything else. 

For Emby Web theres is nothing to do since the Reverse Proxy handles mTLS with your Browser that uses the Client cert imported into OS trust store. The problem were always the client apps (Android, iOS, Desktop) because they do not support web interactions like a Reverse Proxy auth layer (login page, 2FA, proxy Headers etc.). They do need either connect to the devices trust store (e.g. imported client cert into Android), or use an own store with import fields for the cert in initial app settings.

Long story short: When you enable mTLS in reverse proxy, every device needs to have a client cert.

Edited 1 hour ago by sh0rty

[OSBuckeyes4Life 12]

Thanks, @sh0rty—that matches what I’m aiming for: a separate certificate per device, mTLS enforced by the reverse proxy, and normal Emby authentication afterward. I understand the certificate setup you’re explaining.

My question is specifically about native-app support rather than issuing certificates. Installing a certificate on a device doesn’t automatically mean every app or its media player can use it.

@Luke, could Emby support selecting/importing a client identity and using it consistently for API requests, playback, artwork, downloads and WebSockets? I’m particularly interested in iOS, Android and Apple TV, including any platform limitations.

Browser access is useful, but native playback without bypassing the mTLS requirement is the feature I’m requesting. Hopefully that clarifies my use case—happy to help test if this moves forward!