Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)

Featured Replies

 
I tried to read through and figure out what the implications are, but it goes beyond me.  It seems like if I own my domain yyyyy.com, I can get the wildcard certificate for *.yyyyy.com.  Is that right?  or am I totally off base? 


Yes, that is correct about wildcard certs.

Letsencrypt (acme) uses a couple of different methods to verify that you control the domain. One is using a webserver and serving a custom file to the letsencrypt server. That is the method we use in this container.

Another method is to add a custom txt variable in the public dns settings of the domain, which letsencrypt reads to validate.

Unfortunately the wildcard domains will work only with the dns method.
  • Replies 6.2k
  • Views 1.5m
  • Created
  • Last Reply

Top Posters In This Topic

Most Popular Posts

  • Confirming this worked for me too. Not sure I needed to replace both, but I did anyway and Swag and Nextcloud are both back and up and running. For noobs like me, here's what I did: 1. Stop

  • I will only post this once. Feel free to refer folks to this post.   A few points of clarification:   The last update of this image didn't break things. Letsencrypt abruptly disabl

  • BigBoyMarky
    BigBoyMarky

    I replaced both the ssl.conf and nginx.conf files with the sample ones to update them since I did not make any custom modifications to either one of those and this resolved my issue.

Posted Images

Hi all,

 

I had this working all up until a week ago.  Now any time i try I receive an error "502 Bad Gateway".  I am not sure what is causing it.  Please see my config below.  THanks!

 

UPDATE:  If this helps, I am seeing this in the error.log file

2017/07/13 12:21:29 [error] 340#340: *1 upstream prematurely closed connection while reading response header from upstream, client: 192.168.2.60, server: _, request: "GET /plex HTTP/1.1", upstream: "http://192.168.2.90:32400/web", host: "MYSUBDOMAIN.duckdns.org"

2017/07/13 12:23:19 [error] 338#338: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.2.60, server: _, request: "GET /sonarr HTTP/1.1", upstream: "http://192.168.2.90:9898/sonarr", host: "MYSUBDOMAIN.duckdns.org"
upstream backend {
	server 192.168.2.90:19999;
	keepalive 64;
}

server {
	listen 443 ssl default_server;
	listen 80 default_server;
	#listen 443 ssl;
    #server_name MYSUBDOMAIN.duckdns.org;
	#listen 80;
	root /config/www;
	index index.html index.htm index.php;

	server_name _;

	ssl_certificate /config/keys/letsencrypt/fullchain.pem;
	ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
	ssl_dhparam /config/nginx/dhparams.pem;
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
	ssl_prefer_server_ciphers on;

	client_max_body_size 0;

	location = / {
		return 301 /plex;
	}

	
	# Sonarr
	location /sonarr {
		satisfy  any;
		#allow  192.168.2.90/24;
		#deny   all;

		proxy_pass http://192.168.2.90:9898/sonarr;
		proxy_set_header Host $http_host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}    


	#location /sonarr {
	#	auth_basic "Restricted";
	#	auth_basic_user_file /config/nginx/.htpasswd;
	#	include /config/nginx/proxy.conf;
	#	proxy_pass http://192.168.2.90:9898/sonarr;
	#}
	
	
	#location /sonarr {
	#	include /config/nginx/proxy.conf;
	#	proxy_pass http://192.168.2.90:9898/sonarr;
	#}
	
	#location /cp {
	#	include /config/nginx/proxy.conf;
	#	proxy_pass http://192.168.2.90:5050/cp;
	#}
		
	
	#Zoneminder
	location /zm {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.2.90:8082/zm;
		#proxy_connect_timeout    300;
		#proxy_send_timeout       300;
		#proxy_read_timeout       300;
		#send_timeout             300;
	}
	
	#location /zm/api/ {
    #    alias                   /usr/share/zoneminder/api;
    #    rewrite ^/zm/api(.+)$ /zm/api/index.php?p=$1 last;
    #}
	
	#PLEX
	location /web {
		# serve the CSS code
		proxy_pass http://192.168.2.90:32400;
	}

	# Main /plex rewrite
	location /plex {
		# proxy request to plex server
		proxy_pass http://192.168.2.90:32400/web;
	}

	#location /nextcloud {
	#	include /config/nginx/proxy.conf;
	#	proxy_pass https://192.168.2.90:444/nextcloud;
	#}
	
	location ~ /netdata/(?<ndpath>.*) {
		proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_pass http://backend/$ndpath$is_args$args;
		proxy_http_version 1.1;
		proxy_pass_request_headers on;
		proxy_set_header Connection "keep-alive";
		proxy_store off;
	}
}

 

Edited by blknitro11

On 7/11/2017 at 11:39 PM, aptalca said:

 


Yes, that is correct about wildcard certs.

Letsencrypt (acme) uses a couple of different methods to verify that you control the domain. One is using a webserver and serving a custom file to the letsencrypt server. That is the method we use in this container.

Another method is to add a custom txt variable in the public dns settings of the domain, which letsencrypt reads to validate.

Unfortunately the wildcard domains will work only with the dns method.

 

 

I assume adding or switching to the DNS method is non-trivial.  Either way, thank you for your work on this docker.

 
I assume adding or switching to the DNS method is non-trivial.  Either way, thank you for your work on this docker.


Not feasible in an automated way
3 minutes ago, aptalca said:

 


Not feasible in an automated way

 

 

I figured it would be something like that.  Hopefully at some point they expand the capability to the other methods.

On 7/12/2017 at 11:59 PM, blknitro11 said:

Hi all,

 

I had this working all up until a week ago.  Now any time i try I receive an error "502 Bad Gateway".  I am not sure what is causing it.  Please see my config below.  THanks!

 

UPDATE:  If this helps, I am seeing this in the error.log file


2017/07/13 12:21:29 [error] 340#340: *1 upstream prematurely closed connection while reading response header from upstream, client: 192.168.2.60, server: _, request: "GET /plex HTTP/1.1", upstream: "http://192.168.2.90:32400/web", host: "MYSUBDOMAIN.duckdns.org"

2017/07/13 12:23:19 [error] 338#338: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.2.60, server: _, request: "GET /sonarr HTTP/1.1", upstream: "http://192.168.2.90:9898/sonarr", host: "MYSUBDOMAIN.duckdns.org"

upstream backend {
	server 192.168.2.90:19999;
	keepalive 64;
}

server {
	listen 443 ssl default_server;
	listen 80 default_server;
	#listen 443 ssl;
    #server_name MYSUBDOMAIN.duckdns.org;
	#listen 80;
	root /config/www;
	index index.html index.htm index.php;

	server_name _;

	ssl_certificate /config/keys/letsencrypt/fullchain.pem;
	ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
	ssl_dhparam /config/nginx/dhparams.pem;
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
	ssl_prefer_server_ciphers on;

	client_max_body_size 0;

	location = / {
		return 301 /plex;
	}

	
	# Sonarr
	location /sonarr {
		satisfy  any;
		#allow  192.168.2.90/24;
		#deny   all;

		proxy_pass http://192.168.2.90:9898/sonarr;
		proxy_set_header Host $http_host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}    


	#location /sonarr {
	#	auth_basic "Restricted";
	#	auth_basic_user_file /config/nginx/.htpasswd;
	#	include /config/nginx/proxy.conf;
	#	proxy_pass http://192.168.2.90:9898/sonarr;
	#}
	
	
	#location /sonarr {
	#	include /config/nginx/proxy.conf;
	#	proxy_pass http://192.168.2.90:9898/sonarr;
	#}
	
	#location /cp {
	#	include /config/nginx/proxy.conf;
	#	proxy_pass http://192.168.2.90:5050/cp;
	#}
		
	
	#Zoneminder
	location /zm {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.2.90:8082/zm;
		#proxy_connect_timeout    300;
		#proxy_send_timeout       300;
		#proxy_read_timeout       300;
		#send_timeout             300;
	}
	
	#location /zm/api/ {
    #    alias                   /usr/share/zoneminder/api;
    #    rewrite ^/zm/api(.+)$ /zm/api/index.php?p=$1 last;
    #}
	
	#PLEX
	location /web {
		# serve the CSS code
		proxy_pass http://192.168.2.90:32400;
	}

	# Main /plex rewrite
	location /plex {
		# proxy request to plex server
		proxy_pass http://192.168.2.90:32400/web;
	}

	#location /nextcloud {
	#	include /config/nginx/proxy.conf;
	#	proxy_pass https://192.168.2.90:444/nextcloud;
	#}
	
	location ~ /netdata/(?<ndpath>.*) {
		proxy_set_header X-Forwarded-Host $host;
		proxy_set_header X-Forwarded-Server $host;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_pass http://backend/$ndpath$is_args$args;
		proxy_http_version 1.1;
		proxy_pass_request_headers on;
		proxy_set_header Connection "keep-alive";
		proxy_store off;
	}
}

 

Anyone able to help me out with the 502 error i am getting?  It would be greatly appreciated.

Anyone able to help me out with the 502 error i am getting?  It would be greatly appreciated.


Nginx cannot connect to the reverse proxied servers. If you didn't change the nginx site config in a while, then you probably changed your router/firewall rules or something. Can you connect to Sonarr directly at 192.168.2.90:9898?
1 hour ago, aptalca said:

 


Nginx cannot connect to the reverse proxied servers. If you didn't change the nginx site config in a while, then you probably changed your router/firewall rules or something. Can you connect to Sonarr directly at 192.168.2.90:9898?

 

havent changed any firewall rules recently.  Last time i did was when i was getting Nginx setup initially.  It was working great up until a week ago

 

I can get to sonarr directly, yes (now that port is corrected)

 

UPDATE:  So i just realized I had the port flipped....it should have been 8989.  Plex still give me the 502 error.  When i go to Sonarr now, It just says "Sonarr Ver"

Edited by blknitro11

21 hours ago, aptalca said:

 


Nginx cannot connect to the reverse proxied servers. If you didn't change the nginx site config in a while, then you probably changed your router/firewall rules or something. Can you connect to Sonarr directly at 192.168.2.90:9898?

 

ok sonarr started working fine all of a sudden.  I am wondering why Plex still gives me a 502 error though.  Any thoughts?

On 7/11/2017 at 11:46 AM, aptalca said:

 

A couple of thing I noticed. . .

I am not sure if 0.0.0.0 is the real ip you are trying to reverse proxy or if that's your redaction. If former, that is incorrect. 0.0.0.0 in net=bridge will refer only to the letsencrypt container, not the host and not other containers. You can use the server ip to connect to a different container.

 

Also, you are trying to reverse proxy an https page. That is likely the reason you are getting the ssl handshake error (or a combination with a nonexistent service on 0.0.0.0 as referenced above). Try to use an http address for the reverse proxy.

 

@aptalca, thanX for taking a look at my config file. It was the latter of the the solutions. looks like I got it working now. You guys do an awesome job of supporting all these dockers. BTW: I did have to clear the DNS cache in windows too. ThanX again for your hard work.

Mikey

Hi, how can I run an aspx website with this docker? The fastcgi protocol is already enabled for php, so it should just be some config file changes right? I'm not sure if the fast cgi mono server is included in this docker? Thanks for any help!

Hi, how can I run an aspx website with this docker? The fastcgi protocol is already enabled for php, so it should just be some config file changes right? I'm not sure if the fast cgi mono server is included in this docker? Thanks for any help!


Never used aspx, so not entirely sure, but there is no mono in this image, so probably a no go.
15 hours ago, aptalca said:

 


Never used aspx, so not entirely sure, but there is no mono in this image, so probably a no go.

Ah, bummer! Ok, well I put a windows vm machine with IIS to host for now. How can I forward my ssl protocol to this webserver instead?

 

My current nginx config looks like this

 

server {
    listen 80;
    server_name _;
    return 301 https://$host$request_uri;
}

# main server block
server {
    listen 443 ssl default_server;

    root /config/www;
    index index.html index.htm index.php;

    server_name _;

    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
    ssl_dhparam /config/nginx/dhparams.pem;
  

etc

 

I would want to bypass the nginx serving the pages now, but maintain the SSL encrpytion to the new vm host though

 

Thanks!

43 minutes ago, rdubs said:

I would want to bypass the nginx serving the pages now, but maintain the SSL encrpytion to the new vm host though

Why not use nginx as the majority of us do, as a reverse proxy? That way your IIS is protected behind the SSL nginx setup.

IIS, that sends a shiver through me even now, years after I first tried it (pretty unsuccessfully) lol

2 hours ago, CHBMB said:

IIS, that sends a shiver through me even now, years after I first tried it (pretty unsuccessfully) lol

 

Yeah pretty crappy then not so better now but it's point and click and its windows

1 hour ago, ijuarez said:

 

Yeah pretty crappy then not so better now but it's point and click and its windows

Yah, I couldn't find any unraid dockers that are compiled with mono or any other way for me to run an aspx page though. I suppose I could make my own image, but that would be a lot of reading and exploring, I have no idea how lol.

5 hours ago, rdubs said:

Yah, I couldn't find any unraid dockers that are compiled with mono or any other way for me to run an aspx page though. I suppose I could make my own image, but that would be a lot of reading and exploring, I have no idea how lol.

 

We have a mono base image.

On 7/7/2017 at 4:15 PM, Ezro said:

 

Sorry to bump, but I'm still having issues with Gitlab routing.

 

Also, I tried getting Nextcloud to work using this guide, and when I try to access https://192.168.1.207:444 I receive an "Insecure Connection" error. When I try to access server.duckdns.org/nextcloud/ I get a 502 bad gateway.

 

Does anyone know what I should look at in order to fix the Nextcloud routing?

 

I've attached my configs for letsencrypt and nextcloud.

 

Can someone take a look to see if my config is correct?

letsencrypt_default

nextcloud_config.php

nextcloud_default

8 hours ago, CHBMB said:

 

We have a mono base image.

 

So is this image mono based? because aptalca stated that there's no mono in this image.

22 minutes ago, ijuarez said:

 

So is this image mono based? because aptalca stated that there's no mono in this image.

 

No, we have a mono base image that is used for Radarr and Sonarr, that someone could use if they wanted.

1 minute ago, CHBMB said:

 

No, we have a mono base image that is used for Radarr and Sonarr, that someone could use if they wanted.

 

 

well DUH, where's my dunce hat, i used those

 

FAILED!

Edited by ijuarez
engrish

I'm having issues getting this up and running on my server; I am getting the following from my LetsEncrypt log:

 

/bin/sh: /app/le-renew.sh: Permission denied

Has anyone else experienced this, and does anyone have any potential solutions?  I'm not exactly sure what permissions need to be enabled.

I'm running into some issues with Plex being ssl proxypassed through this docker. I can access the proxypassed page just fine, but then I get a message saying: The server "server" does not allow secure connections, with the option to allow once/always (but both don't actually do anything). When I access Plex directly via LAN it works just fine. My browser is giving me a notification that the page is trying to load unsecure scripts.

 

What I've tried so far:

 

- Serving Plex through both http and https via nginx

- Setting the custom server access urls in Plex settings

- Setting Secure Connections in Plex: Disabled/Preferred/Required


Part of the nginx config:

Quote

 

    location /web {
        # serve the CSS code
        proxy_pass http://192.168.2.3:32400/web;
        include /config/nginx/proxy.conf;
        }

    location /plex {
        # proxy request to plex server
        proxy_pass http://192.168.2.3:32400/web;
        include /config/nginx/proxy.conf;
    }

 

 

Proxy.conf:

Quote

client_max_body_size 10m;
client_body_buffer_size 128k;

#Timeout if the real server is dead
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

# Advanced Proxy Config
send_timeout 5m;
proxy_read_timeout 240;
proxy_send_timeout 240;
proxy_connect_timeout 240;

# Basic Proxy Config
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_redirect  http://  $scheme://;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 32 4k;
 

 

 

Is it required to set up a custom certificate within Plex itself? I assumed this wouldn't be necessary, as this docker would take care of the ssl part.

 

Edited by Kashiro

17 hours ago, jamesp469 said:

I'm having issues getting this up and running on my server; I am getting the following from my LetsEncrypt log:

 


/bin/sh: /app/le-renew.sh: Permission denied

Has anyone else experienced this, and does anyone have any potential solutions?  I'm not exactly sure what permissions need to be enabled.

 

I don't experience it. 

Please post your container settings and we'll take a look

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.