HOW TO: emby with NGINX - With Windows Specific Tips and CSP options

[iBoss 23]

@pwhodges

As I said with error only happen in Galaxy Note 5 (old device) ... with other devices, it works perfectly.

I'll try to change the certificate later and see if it will solve the issue.

 

Thanks

Edited July 20, 2022 by iBoss

[pir8radio 1292]

On 7/20/2022 at 5:56 PM, iBoss said:

@pwhodges

As I said with error only happen in Galaxy Note 5 (old device) ... with other devices, it works perfectly.

I'll try to change the certificate later and see if it will solve the issue.

 

Thanks

and that note 5 device can surf the internet fine? other sites?

 

Edited July 22, 2022 by pir8radio

[pwhodges 1519]

On 20/07/2022 at 23:56, iBoss said:

As I said with error only happen in Galaxy Note 5 (old device) ...

Sometimes older devices don't get updated with the root certificates of newer certificate issuers; using a different one might well help.

Paul

[iBoss 23]

38 minutes ago, pir8radio said:

and that note 5 device can surf the internet fine? other sites?

 

Yes It can surf other sites fine.

Maybe the issue from the certificate not the Nginx ... I need to use emby without nginx and install the same Let’s Encrypt cert into emby and see the if the issue happen or not.

 

Anyone know how convert my public and private PEM files to work directly in emby setting.

 

thanks

[shpitz461 4]

Hi,

I'm trying to achieve an A+ rating @ https://securityheaders.io/

My only missing piece is contentSecurityPolicy/Content-Security-Policy, as soon as I enable it all my proxied sites break.

Any idea how to configure contentSecurityPolicy so that it doesn't break Emby and every other service I'm running on Traefik v2?

As soon as I turn on the following policy:

Quote

contentSecurityPolicy: "default-src 'unsafe-inline'; script-src 'self' http://*.mydomain.com https://*.mydomain.com http://mydomain.com https://mydomain.com"

...Browsing to Emby yields the following errors in Chrome:

Quote

Refused to load the font 'https://media.mydomain.com/web/modules/fonts/material-icons/LDItaoyNOAY6Uewc665JcIzCKsKc_M9flwmP_3.woff2' because it violates the following Content Security Policy directive: "default-src 'unsafe-inline'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.

10Refused to load the image '<URL>' because it violates the following Content Security Policy directive: "default-src 'unsafe-inline'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.

index.html#!/home:1 Refused to load manifest from 'https://media.mydomain.com/web/manifest.json' because it violates the following Content Security Policy directive: "default-src 'unsafe-inline'". Note that 'manifest-src' was not explicitly set, so 'default-src' is used as a fallback.

If I set the values to 'unsafe-inline' wouldn't that defeat the purpose of setting the header in the 1st place?

Thanks!

[rbjtech 4218]

Hi @pir8radio

I'm hoping you can help me here.

First of all - thanks for the nginx/csp config - it's allowed me to get an A/A+ on the scanners. 

However, there is one issue I'm having which is preventing nginx from passing the real IP's to emby.

I have to comment out the two lines below - or the proxy simply refuses to connect and I get an error on the remote browser. (ERR_CONNECTION_CLOSED)

proxy_set_header X-Real-IP $remote_addr; ## Passes the real client IP to the backend server.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ## Adds forwarded IP to the list of IPs that were forwarded to the backend server.

This is obviously not directly impacting security - but because emby is now receiving the nginx g/w address (ngnix is on it's own dmz vlan) - fail2ban etc is no longer going to work.  I'm making the assumption that nginx passes this via the existing proxy_pass control and uses whatever ip/port is specified here as there is a firewall inbetween.   Emby works just fine (with the above lines commented), so I don't *think* it's related to that.

I'll dig a bit deeper today but if you have any thoughts on why this would stop it working, I'd appreciate it.

I can PM you nginx logs etc if you think that would help but there is nothing obvious in them.

Thanks !

Latest nginx on ubuntu 22.04.1 LTS/jammy

 

[pir8radio 1292]

On 9/9/2022 at 3:55 AM, rbjtech said:

Hi @pir8radio

I'm hoping you can help me here.

First of all - thanks for the nginx/csp config - it's allowed me to get an A/A+ on the scanners. 

However, there is one issue I'm having which is preventing nginx from passing the real IP's to emby.

I have to comment out the two lines below - or the proxy simply refuses to connect and I get an error on the remote browser. (ERR_CONNECTION_CLOSED)

proxy_set_header X-Real-IP $remote_addr; ## Passes the real client IP to the backend server.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ## Adds forwarded IP to the list of IPs that were forwarded to the backend server.

This is obviously not directly impacting security - but because emby is now receiving the nginx g/w address (ngnix is on it's own dmz vlan) - fail2ban etc is no longer going to work.  I'm making the assumption that nginx passes this via the existing proxy_pass control and uses whatever ip/port is specified here as there is a firewall inbetween.   Emby works just fine (with the above lines commented), so I don't *think* it's related to that.

I'll dig a bit deeper today but if you have any thoughts on why this would stop it working, I'd appreciate it.

I can PM you nginx logs etc if you think that would help but there is nothing obvious in them.

Thanks !

Latest nginx on ubuntu 22.04.1 LTS/jammy

 

the error on your remote browser, doesn't sound like a proxy error, are you sure fail2ban isnt blocking remote connections to nginx?    nginx will almost always give an error that says nginx somewhere.    Unless you specifically have config settings to just drop the connection.        

Edited September 13, 2022 by pir8radio

[rbjtech 4218]

On 13/09/2022 at 01:38, pir8radio said:

the error on your remote browser, doesn't sound like a proxy error, are you sure fail2ban isnt blocking remote connections to nginx?    nginx will almost always give an error that says nginx somewhere.    Unless you specifically have config settings to just drop the connection.        

Hi - thanks for coming back to me.

All fixed.

It was basically the emby config, it had nothing to do with nginx.

For some reason I had not set emby to allow remote connections using the 'use reverse proxy' setting (I had naively removed all remote connection on the emby config..) - thus any X-Real-IP was being blocked by the emby web server as a non-local IP.   By leaving out the X-Real-IP config - it returned the local emby gateway address which of course would be allowed....

doh!

Thanks again.

Edited September 14, 2022 by rbjtech

[pir8radio 1292]

11 hours ago, rbjtech said:

Hi - thanks for coming back to me.

All fixed.

It was basically the emby config, it had nothing to do with nginx.

For some reason I had not set emby to allow remote connections using the 'use reverse proxy' setting (I had naively removed all remote connection on the emby config..) - thus any X-Real-IP was being blocked by the emby web server as a non-local IP.   By leaving out the X-Real-IP config - it returned the local emby gateway address which of course would be allowed....

doh!

Thanks again.

nice, good job troubleshooting and fixing!

[horstepipe 356]

Hey @pir8radio

I'm wondering whether this would be possible with nginx:

For my users I need to enable "allow remux" in playback settings, otherwise they are not able to play some of my iptv channels. Unfortunately enabling this option sometimes lets Emby server remux a video although this is not needed. So if I disable the setting, the video is being direct played fine.

So I'm wondering whether nginx could be configured to change the response

Enable Playback Remuxing: True

to

Enable Playback Remuxing: False

if the requested media is an mkv file e.g. ...?

Best regards and thanks for all your valuable input!

Edited September 19, 2022 by horstepipe

[crusher11 848]

I changed ISP and now I'm getting a 522 error from CloudFlare. I changed my IP on CloudFlare's DNS page to my new IP, it hasn't fixed it. canyouseeme.org is down, so that's not super helpful right now.

[crusher11 848]

Never mind, turns out my port forwarding got wiped. Back up and running. 

[pir8radio 1292]

On 9/19/2022 at 4:32 AM, horstepipe said:

Hey @pir8radio

I'm wondering whether this would be possible with nginx:

For my users I need to enable "allow remux" in playback settings, otherwise they are not able to play some of my iptv channels. Unfortunately enabling this option sometimes lets Emby server remux a video although this is not needed. So if I disable the setting, the video is being direct played fine.

So I'm wondering whether nginx could be configured to change the response

Enable Playback Remuxing: True

to

Enable Playback Remuxing: False

if the requested media is an mkv file e.g. ...?

Best regards and thanks for all your valuable input!

just saw this.. did you ever get your answer?    what is this above?  a header of some kind or?   looks like an emby client setting, and we cant force those from the server side.

Edited September 25, 2022 by pir8radio

[horstepipe 356]

8 hours ago, pir8radio said:

looks like an emby client setting, and we cant force those from the server side.

no it is a server setting for each client. But nevermind, I solved my iptv remux problem so I was able to disable the setting for my users.

Best regards.

[rotational467 31]

Hi @pir8radio, first just wanted to say thank you for the guide.  Using it helped me get everything up and running with no pain.  Today though I've run into my first issue, hoping you or someone has seen this before.

I've confirmed that Android, AndroidTV, iOS, and the web client all work 100% from outside thru nginx.  All of these clients had already been authorized prior to my putting nginx in place.  Today I attempted to add a new Roku stick at mom's house, and it refused to connect with error -60 SSL Certificate unable to get local issuer certificate.  There's no activity whatsoever in the nginx logs from the Roku attempts, while I my activity connected via Android on the same remote network is there as expected.  I wonder if perhaps I'm not allowing any cipher suites the Rokus support (2021 4K stick running the latest software).  I did increase the restrictions from your original guide.  LAN Roku clients (not passing thru nginx) all work fine.

edit: I've found some old ( <= 2017) complaints on the Roku forums about Roku and cipher support, but nothing definitive.

Emby server is Ubuntu 20.04, nginx on the same box.  The router is listening on a non-standard port which forwards to 443 for nginx.

Here's my relevant nginx.conf settings:

ssl_certificate /var/lib/nginx/ssl/xxxxxxxxxxx.crt;
        ssl_certificate_key /var/lib/nginx/ssl/xxxxxxxxxxxx.key;
        ssl_protocols TLSv1.3 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_early_data on;
        ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE+AES128:RSA+AES128:ECDHE+AES256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DSS';

add_header 'Referrer-Policy' 'origin-when-cross-origin';
        ## add_header Strict-Transport-Security "max-age=15552000; preload" always;
        add_header Strict-Transport-Security "max-age=604800;" always;          ## max-age=604800; max-age=2592000;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-XSS-Protection "1; mode=block" always;

Thanks!

Edited October 17, 2022 by rotational467

[pir8radio 1292]

22 hours ago, rotational467 said:

Hi @pir8radio, first just wanted to say thank you for the guide.  Using it helped me get everything up and running with no pain.  Today though I've run into my first issue, hoping you or someone has seen this before.

I've confirmed that Android, AndroidTV, iOS, and the web client all work 100% from outside thru nginx.  All of these clients had already been authorized prior to my putting nginx in place.  Today I attempted to add a new Roku stick at mom's house, and it refused to connect with error -60 SSL Certificate unable to get local issuer certificate.  There's no activity whatsoever in the nginx logs from the Roku attempts, while I my activity connected via Android on the same remote network is there as expected.  I wonder if perhaps I'm not allowing any cipher suites the Rokus support (2021 4K stick running the latest software).  I did increase the restrictions from your original guide.  LAN Roku clients (not passing thru nginx) all work fine.

edit: I've found some old ( <= 2017) complaints on the Roku forums about Roku and cipher support, but nothing definitive.

Emby server is Ubuntu 20.04, nginx on the same box.  The router is listening on a non-standard port which forwards to 443 for nginx.

Here's my relevant nginx.conf settings:

ssl_certificate /var/lib/nginx/ssl/xxxxxxxxxxx.crt;
        ssl_certificate_key /var/lib/nginx/ssl/xxxxxxxxxxxx.key;
        ssl_protocols TLSv1.3 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_early_data on;
        ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE+AES128:RSA+AES128:ECDHE+AES256:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DSS';

add_header 'Referrer-Policy' 'origin-when-cross-origin';
        ## add_header Strict-Transport-Security "max-age=15552000; preload" always;
        add_header Strict-Transport-Security "max-age=604800;" always;          ## max-age=604800; max-age=2592000;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-XSS-Protection "1; mode=block" always;

Thanks!

i dont think i have but one roku any longer, you can check your roku client on my server if you like share what you find..   login info in my profile page. 

[Guest Brett_Dean]

thanks! 

[sross44 225]

Hey all, I could use some help. I'm pretty dumb when it comes to networking. I have Emby running on my home server. Right now I have Emby set up via SSL through Cloudfare but I got a warning from Cloudfare for violating their TOS. I've tried int he past to set up Nginx but somehow I keep screwing up lol. Anyone up to helping me out via team view or something. I feel like a dumb dumb but can’t figure out how to do it. But I have remote users who use my server and before I switch off of cloudfare I want to make sure it’s secure. Any help or suggestions would be appreciated.

 

[rbjtech 4218]

10 minutes ago, sross44 said:

Hey all, I could use some help. I'm pretty dumb when it comes to networking. I have Emby running on my home server. Right now I have Emby set up via SSL through Cloudfare but I got a warning from Cloudfare for violating their TOS. I've tried int he past to set up Nginx but somehow I keep screwing up lol. Anyone up to helping me out via team view or something. I feel like a dumb dumb but can’t figure out how to do it. But I have remote users who use my server and before I switch off of cloudfare I want to make sure it’s secure. Any help or suggestions would be appreciated.

 

If you're not experienced or have some insight into what nginx is doing - then my honest advice is just to stick to the normal remote access for emby - via the normal remote access guides.

nginx is for those that want to take the connectivity/security to the next level but while the guide here is excellent, just following a guide because it says so, is a little dangerous imo.

Get the basics working first (via normal remote access) and then maybe setup a test system with a parallel test emby server and start to have a play - nginx, certs etc are all free - so the only thing it's going to cost you is time.  Then when your comfortable with nginx on your test rig (and it's secure, A+ rating etc) - replicate the config on your main system and re-test.

 

[sross44 225]

2 minutes ago, rbjtech said:

If you're not experienced or have some insight into what nginx is doing - then my honest advice is just to stick to the normal remote access for emby - via the normal remote access guides.

nginx is for those that want to take the connectivity/security to the next level but while the guide here is excellent, just following a guide because it says so, is a little dangerous imo.

Get the basics working first (via normal remote access) and then maybe setup a test system with a parallel test emby server and start to have a play - nginx, certs etc are all free - so the only thing it's going to cost you is time.  Then when your comfortable with nginx on your test rig (and it's secure, A+ rating etc) - replicate the config on your main system and re-test.

 

I can get normal remote access working.... and like I said, I got it working previously via SSL with Cloudfare. It's why I was asking for a little bit of help with either the explanation or someone helping me set it up. I've got a few things I'd like to put behind nginx and just want to understand it better/have someone "show me the way". 

[rbjtech 4218]

So just a quick question which I think I know the answer to but posting here for clarification.

I see all the connections in Emby listed as http1.1 in the dashboard.

ngnix has been setup to use http2 - but I never see this.

I *think* this is because while http2 does not mandate https - no browsers (and maybe emby clients) support http2 over http only - thus my nginx reverse proxy re-direction will fail the http2 requirement as that is just using http - thus failing back to http1.1

If I setup https from nginx to emby itself (on the internal lan) - then http2 would work ?

[horstepipe 356]

I‘m wondering…anybody knows or has some tips about achieving something like this with nginx:

giving sessions from users logged in successfully into Emby some kind of authentication header which can be used for another web service behind nginx for authorization? So if user A logs in successfully to nginx, the device from user A can access a website behind nginx?

So kind of a mini SSO implementation…?

Edited January 9, 2023 by horstepipe

[Gecko 61]

On 1/9/2023 at 10:18 PM, rbjtech said:

So just a quick question which I think I know the answer to but posting here for clarification.

I see all the connections in Emby listed as http1.1 in the dashboard.

ngnix has been setup to use http2 - but I never see this.

I *think* this is because while http2 does not mandate https - no browsers (and maybe emby clients) support http2 over http only - thus my nginx reverse proxy re-direction will fail the http2 requirement as that is just using http - thus failing back to http1.1

If I setup https from nginx to emby itself (on the internal lan) - then http2 would work ?

FYI: nginx does not support http2 for the backend connection. So you need to stick with http1.1.

caddyv2 seems to support that on the other hand so worth to try and see if there is any performance improvment at all

[rbjtech 4218]

12 hours ago, Gecko said:

FYI: nginx does not support http2 for the backend connection. So you need to stick with http1.1.

Yep - dug into this a bit myself and yes, http/2 is for the web to NGINX connections only in a Reverse Proxy configuration.  There appears to be little benefit (if any) in using it LAN side anyway - so not something that bothers me now I know it's not even an option.

Quote

Q: Will you support HTTP/2 on the upstream side as well, or only support HTTP/2 on the client side?

A: At the moment, we only support HTTP/2 on the client side. You can’t configure HTTP/2 with proxy_pass. [Editor – In the original version of this post, this sentence was incorrectly transcribed as “You can configure HTTP/2 with proxy_pass.” We apologize for any confusion this may have caused.]

But what is the point of HTTP/2 on the backend side? Because as you can see from the benchmarks, there’s not much benefit in HTTP/2 for low‑latency networks such as upstream connections.

Also, in NGINX you have the keepalive module, and you can configure a keepalive cache. The main performance benefit of HTTP/2 is to eliminate additional handshakes, but if you do that already with a keepalive cache, you don’t need HTTP/2 on the upstream side.

source - The HTTP/2 Module in NGINX

 

[Gecko 61]

@rbjtech, I quickly set up caddyv2 locally this morning and made it work easily with this caddyfile if you want to try it :

:2080 {   # the http docker port opened for caddy
     reverse_proxy https://<embyIP>:<embyHTTPSPort> {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

Emby dashboard says the connection is http/2. Seems really simple to set it up compared to nginx. I'll play with it tomorrow to see if there is any benefit performance wise. Since I have the Safari bug, I'll also check if it disappears. (I'm not sure I correctly set up keep_alive on my config since my reverse proxy and Emby are not on the same machine).