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

[strike]

@Nickglott, @lespaul In your nginx.conf uncomment these lines: 

gzip_vary on;

gzip_proxied any;

gzip_comp_level 6;

gzip_buffers 16 8k;

gzip_http_version 1.1;

gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Made my emby a lot faster, the sign in page is still slow but once you sign in it's faster. Also remember if you have configured your disks to spin down, there will be a delay to spin up any disk that's not spinning.

Edited March 11, 2018 by strike

[ben-nl]

Here is a how to, maybe it helps.

https://emby.media/community/index.php?/topic/47508-how-to-nginx-reverse-proxy/

[trurl]

2 hours ago, ben-nl said:

Here is a how to, maybe it helps.

https://emby.media/community/index.php?/topic/47508-how-to-nginx-reverse-proxy/

Do you have this working on unRAID yourself?

[ben-nl]

3 minutes ago, trurl said:

Do you have this working on unRAID yourself?

Yes, I use it.

[sinbrkatetete]

On 08. 03. 2018. at 4:35 PM, Living Legend said:

 

Hmm.  I'm still not getting it to work.

 

I add the linked conf from the post mentioned.  At first it didn't work and I was met with an error that the directive stream was not acceptable.  I added the below to the very top of the nginx.conf file:

 

load_module /usr/lib/nginx/modules/ngx_stream_module.so;

 

After this, Letsencrypt was able to boot up.

 

But when Owntracks is trying to connect to server.duckdns.org I get the error:

 

Unable to connect to server (32103) - 

java.net.ConnectException: Connection refused

 

Maybe my  configuration is incorrect for the nginx file or owntracks?  My MQTT is running on port 1883 on my server (192.168.1.3) so my nginx.conf addition looks like this:

 

stream {
        upstream mosquitto {
                server 192.168.1.3:1883;
        }

        server {
                listen 8883 ssl;
                proxy_pass mosquitto;

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

My Owntracks configuration looks like this:

 

Mode: Private MQTT

Host: server.duckdns.org

Port: 1883

Use WebSockets: "No"

 

Security

TLS: "No"

 

I'm not sure I'm correctly understanding the post where you said:

 

"As it is now, my mqtt clients connect by using any of the three subdomains the duckdns.org docker is "following" @ port 8883."

 

My subdomains like Home Assistant and Next Cloud are not following any port besides the specific port designated to those dockers on my local network.

 

Probably a silly oversight on my part.  I'll keep tinkering with the settings.

 

 

Sorry for taking so long to respond...  EDIT (reread your conf): FIRST SKIP TO THE END OF MY POST, then read everything else if it still interests you.

I'm not sure what could go wrong if you forwarded the port 8883 correctly to your letsencrypt docker and set the MQTT docker to expect/accept connections on port 1883. Are your credentials OK? 

BTW, I repeat, I'm a total noob in thiese "fields" but could the problem be in a "tab too much" - why are your ssl_certificate_key and ssl_dharam indented further than ssl_certificate? Here's my nginx.conf:

user abc;
worker_processes 4;
pid /run/nginx.pid;
include /etc/nginx/modules/*.conf;

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	##
	# Basic Settings
	##

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;

	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	client_max_body_size 0;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# Logging Settings
	##

	access_log /config/log/nginx/access.log;
	error_log /config/log/nginx/error.log;

	##
	# Gzip Settings
	##

	gzip on;
	gzip_disable "msie6";

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

	##
	# nginx-naxsi config
	##
	# Uncomment it if you installed nginx-naxsi
	##

	#include /etc/nginx/naxsi_core.rules;

	##
	# nginx-passenger config
	##
	# Uncomment it if you installed nginx-passenger
	##

	#passenger_root /usr;
	#passenger_ruby /usr/bin/ruby;

	##
	# Virtual Host Configs
	##
	include /etc/nginx/conf.d/*.conf;
	include /config/nginx/site-confs/*;
  
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
	ssl_prefer_server_ciphers on;
	ssl_session_cache shared:SSL:10m;
	add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
	add_header X-Frame-Options SAMEORIGIN;
	add_header X-Content-Type-Options nosniff;
	add_header X-XSS-Protection "1; mode=block";
	add_header X-Robots-Tag none;
	ssl_stapling on; # Requires nginx >= 1.3.7
	ssl_stapling_verify on; # Requires nginx => 1.3.7

	##
	# Added from Reddit prescription
	##
	map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    	}
}

stream {
        upstream mosquitto {
                server 192.168.4.2:1883;
        }

        server {
                listen 8883 ssl;
                proxy_pass mosquitto;

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


#mail {
#	# See sample authentication script at:
#	# http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#	# auth_http localhost/auth.php;
#	# pop3_capabilities "TOP" "USER";
#	# imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#	server {
#		listen     localhost:110;
#		protocol   pop3;
#		proxy      on;
#	}
#
#	server {
#		listen     localhost:143;
#		protocol   imap;
#		proxy      on;
#	}
#}
daemon off;

As you can see from the conf, my MQTT server is at 192.168.4.2, listening on port 1883; the letsencrypt/nginx is expecting connections at port 8883.

 

Here are my settings for the MQTT server hassio addon:

{
  "plain": true,
  "ssl": false,
  "anonymous": false,
  "logins": [
    {
      "username": "blabla",
      "password": "blablapassword"
    },
    {
      "username": "clacla",
      "password": "claclapassword"
    },
    {
      "username": "dladla",
      "password": "dladlapassword"
    },
    {
      "username": "elaela",
      "password": "elaelapassword"
    },
    {
      "username": "flafla",
      "password": "flaflapassword"
    },
    {
      "username": "glagla",
      "password": "glaglapassword"
    }
  ],
  "customize": {
    "active": false,
    "folder": "mosquitto"
  },
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem"
}

 

-> READ THIS FIRST!

Now, that I came to this part of your post about your MQTT client conf:

Quote

My Owntracks configuration looks like this:

 

Mode: Private MQTT

Host: server.duckdns.org

Port: 1883

Use WebSockets: "No"

What port(s) have you forwarded to your letsencrypt/nginx container from the "outside"??

If you've followed the same principles as I did, you should have forwarded port 8883 on your router to your letsencrypt/nginx container which would mean you should set it as the port your MQTT client is connecting to - Port: 8883, not 1883. I'm not "at home" with owntracks, but you could check if there's something like "Secure MQTT" besides "Private MQTT" because of the next problem with your Owntracks config...

Quote

Security

TLS: "No"

I believe the next part of the problem is the "No" by the TLS... Did you try using TLS 1.2? Since,, from your MQTT client perspective, you are in fact connecting through a "secure connection" I don't think this is the right option here. Is there an option in Owntracks to set SSL/TLS connection?

 

Lastly, about the (sub)domains. I have four subdomains "registered" @ duckdns.org, let's call them - sub1.duckdns.org etc. I've set up my duckdns container to keep the IPs updated and the letsencrypt/nginx docker to obtain certificates for those four subdomains and forward connections like - entering "https://www.sub1.duckdns.org" will get you to my Hassio UI login, entering "https://www.sub2.duckdns.org" will get you to my Nextcloud UI also that's the subdomain I enter into the Nextcloud clients to connect. sub3 is there for the mqtt connection, sub4 is still unused, it's reserved for video surveilance or something like that. Anyway, everything works as expected, entering the address of the subdomain gets me exactly where I'm supposed to get but the MQTT connection works no matter which of the four registered subdomains I enter into the client config; sub1.duckdns.org:8883 works as well as the sub2.duckdns.org:8883, sub3... you get the point. 

 

I hope I've helped at least a bit. If I were you, I'd concentrate on the "TLS:'No'" setting and the indentation in nginx.conf, but mostly on the former.

 

Good luck
 

Edited March 11, 2018 by sinbrkatetete

[Nickglott]

17 hours ago, strike said:

@Nickglott, @lespaul In your nginx.conf uncomment these lines: 

gzip_vary on;

gzip_proxied any;

gzip_comp_level 6;

gzip_buffers 16 8k;

gzip_http_version 1.1;

gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Made my emby a lot faster, the sign in page is still slow but once you sign in it's faster. Also remember if you have configured your disks to spin down, there will be a delay to spin up any disk that's not spinning.

Thanks, I added those, but it still seems to load pictures very slowly. I am beginning to think its Nginx that causes it since it goes through there with the reverse proxy. I have my disks set to never spin down and my appdata is running off a NVME. The media itself plays instantly its the HTML5 webserver that’s very slow behind it. Been tweaking it for about 6 days with no luck yet. Thinking about just opening the port and use the cert w/o the reverse proxy. When I get some more free time ill test that and see if I can still have letsencrypt get the cert for that domain and subdomain w/o using the Ngnix server to route it but have the subdomain go straight to the port all while keeping Emby Connect functional. 

 

15 hours ago, ben-nl said:

Here is a how to, maybe it helps.

https://emby.media/community/index.php?/topic/47508-how-to-nginx-reverse-proxy/

 Yeah I built my reverse proxy based off that guide , but thank you! 

[strike]

When you say added, did you actually add it to your config or did you just uncomment it the default nginx.conf.? Because if you added it you're probably missing two lines: 

 

gzip on;
gzip_disable "msie6";

Without the first line it won't work. That's why I told you to just uncomment the lines in the default nginx.conf because it's all there but most of it is commented out. If you haven't removed it.

 

You can also add 

 

image/svg+xml

To the last line.

 

Worked like a charm for me, images and everything loads instantly.

 

 

[strike]

You can also try to add http2 to your main server block config which will load pages that have a lot of images a bit faster

[Living Legend]

On 3/11/2018 at 12:39 PM, sinbrkatetete said:

Sorry for taking so long to respond...  EDIT (reread your conf): FIRST SKIP TO THE END OF MY POST, then read everything else if it still interests you.

I'm not sure what could go wrong if you forwarded the port 8883 correctly to your letsencrypt docker and set the MQTT docker to expect/accept connections on port 1883. Are your credentials OK? 

BTW, I repeat, I'm a total noob in thiese "fields" but could the problem be in a "tab too much" - why are your ssl_certificate_key and ssl_dharam indented further than ssl_certificate? Here's my nginx.conf:

user abc;
worker_processes 4;
pid /run/nginx.pid;
include /etc/nginx/modules/*.conf;

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	##
	# Basic Settings
	##

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;

	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	client_max_body_size 0;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# Logging Settings
	##

	access_log /config/log/nginx/access.log;
	error_log /config/log/nginx/error.log;

	##
	# Gzip Settings
	##

	gzip on;
	gzip_disable "msie6";

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

	##
	# nginx-naxsi config
	##
	# Uncomment it if you installed nginx-naxsi
	##

	#include /etc/nginx/naxsi_core.rules;

	##
	# nginx-passenger config
	##
	# Uncomment it if you installed nginx-passenger
	##

	#passenger_root /usr;
	#passenger_ruby /usr/bin/ruby;

	##
	# Virtual Host Configs
	##
	include /etc/nginx/conf.d/*.conf;
	include /config/nginx/site-confs/*;
  
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
	ssl_prefer_server_ciphers on;
	ssl_session_cache shared:SSL:10m;
	add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
	add_header X-Frame-Options SAMEORIGIN;
	add_header X-Content-Type-Options nosniff;
	add_header X-XSS-Protection "1; mode=block";
	add_header X-Robots-Tag none;
	ssl_stapling on; # Requires nginx >= 1.3.7
	ssl_stapling_verify on; # Requires nginx => 1.3.7

	##
	# Added from Reddit prescription
	##
	map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    	}
}

stream {
        upstream mosquitto {
                server 192.168.4.2:1883;
        }

        server {
                listen 8883 ssl;
                proxy_pass mosquitto;

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


#mail {
#	# See sample authentication script at:
#	# http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#	# auth_http localhost/auth.php;
#	# pop3_capabilities "TOP" "USER";
#	# imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#	server {
#		listen     localhost:110;
#		protocol   pop3;
#		proxy      on;
#	}
#
#	server {
#		listen     localhost:143;
#		protocol   imap;
#		proxy      on;
#	}
#}
daemon off;

As you can see from the conf, my MQTT server is at 192.168.4.2, listening on port 1883; the letsencrypt/nginx is expecting connections at port 8883.

 

Here are my settings for the MQTT server hassio addon:

{
  "plain": true,
  "ssl": false,
  "anonymous": false,
  "logins": [
    {
      "username": "blabla",
      "password": "blablapassword"
    },
    {
      "username": "clacla",
      "password": "claclapassword"
    },
    {
      "username": "dladla",
      "password": "dladlapassword"
    },
    {
      "username": "elaela",
      "password": "elaelapassword"
    },
    {
      "username": "flafla",
      "password": "flaflapassword"
    },
    {
      "username": "glagla",
      "password": "glaglapassword"
    }
  ],
  "customize": {
    "active": false,
    "folder": "mosquitto"
  },
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem"
}

 

-> READ THIS FIRST!

Now, that I came to this part of your post about your MQTT client conf:

What port(s) have you forwarded to your letsencrypt/nginx container from the "outside"??

If you've followed the same principles as I did, you should have forwarded port 8883 on your router to your letsencrypt/nginx container which would mean you should set it as the port your MQTT client is connecting to - Port: 8883, not 1883. I'm not "at home" with owntracks, but you could check if there's something like "Secure MQTT" besides "Private MQTT" because of the next problem with your Owntracks config...

I believe the next part of the problem is the "No" by the TLS... Did you try using TLS 1.2? Since,, from your MQTT client perspective, you are in fact connecting through a "secure connection" I don't think this is the right option here. Is there an option in Owntracks to set SSL/TLS connection?

 

Lastly, about the (sub)domains. I have four subdomains "registered" @ duckdns.org, let's call them - sub1.duckdns.org etc. I've set up my duckdns container to keep the IPs updated and the letsencrypt/nginx docker to obtain certificates for those four subdomains and forward connections like - entering "https://www.sub1.duckdns.org" will get you to my Hassio UI login, entering "https://www.sub2.duckdns.org" will get you to my Nextcloud UI also that's the subdomain I enter into the Nextcloud clients to connect. sub3 is there for the mqtt connection, sub4 is still unused, it's reserved for video surveilance or something like that. Anyway, everything works as expected, entering the address of the subdomain gets me exactly where I'm supposed to get but the MQTT connection works no matter which of the four registered subdomains I enter into the client config; sub1.duckdns.org:8883 works as well as the sub2.duckdns.org:8883, sub3... you get the point. 

 

I hope I've helped at least a bit. If I were you, I'd concentrate on the "TLS:'No'" setting and the indentation in nginx.conf, but mostly on the former.

 

Good luck
 

 

I've read through the post and will continue to futz around.  Thanks for pointing out "TLS:No".  That was a ridiculously dumb oversight on my part.

 

I will preface the following with the same warning as you.  I'm also a relative n00b in the networking security realm, so take my questions/concerns with a grain of salt.

 

With that said, isn't one of the fundamental purposes of this docker supposed to be to provide the ability to reach into your home network via secure http without having to open up ports on your router for each and every docker?

 

For instance, I have about 10 different dockers with outside access.  Half of them are set up as subdomains where https://dockername.servername.duckdns.org will allow me to externally access what is on my internal network as 192.168.1.3:5555.  The other half are set up as subpages where https://servername.duckdns.org/dockername will allow me to access 192.168.1.3:6666.  And to accomplish this, I only have ports 443 and 80 on my router forwarded to my server.  With your suggested method, I'm just opening up another port and bypassing what I thought was the fundamental goal of this docker.

 

 

 

 

[ElectricBadger]

I have DNS on Gandi, which is does not have a certbot plugin. That is supported by acme.sh, though — along with a whole lot of other DNS providers that certbot doesn't support. As wildcard certificates require DNS verification, this is going to be a bit of a blocker.

 

(I did submit a feature request on the certbot repo for Gandi support, but the reply I got seemed to indicate that it wouldn't happen unless I wrote it myself, so that's unlikely to happen any time soon, alas…)

 

I don't suppose there are any plans to switch the docker from certbot to acme.sh? I'm guessing not, though it's worth asking

[aptalca]

1 hour ago, ElectricBadger said:

I have DNS on Gandi, which is does not have a certbot plugin. That is supported by acme.sh, though — along with a whole lot of other DNS providers that certbot doesn't support. As wildcard certificates require DNS verification, this is going to be a bit of a blocker.

 

(I did submit a feature request on the certbot repo for Gandi support, but the reply I got seemed to indicate that it wouldn't happen unless I wrote it myself, so that's unlikely to happen any time soon, alas…)

 

I don't suppose there are any plans to switch the docker from certbot to acme.sh? I'm guessing not, though it's worth asking

 

No plans at the moment, however cloudflare is free and is a great option for dns. Remember, you're not tied to your registrar for dns. All you need to do is get a cloudflare account and point your name servers there

[ijuarez]

Now that LE has domain wildcards how does that effect the docker, can you do wildcards?

[sparklyballs]

3 minutes ago, ijuarez said:

Now that LE has domain wildcards how does that effect the docker, can you do wildcards?

 

 

read the github readme for the newly added wildcard feature 

[ijuarez]

15 minutes ago, sparklyballs said:

 

 

read the github readme for the newly added wildcard feature 

i shall thanks

 

 

: Done

Edited March 14, 2018 by ijuarez
Solved

[smdion]

Wildcard working great for me.  Thanks!

[sinbrkatetete]

On 14. 03. 2018. at 5:29 AM, Living Legend said:

I've read through the post and will continue to futz around.  Thanks for pointing out "TLS:No".  That was a ridiculously dumb oversight on my part.

 

I will preface the following with the same warning as you.  I'm also a relative n00b in the networking security realm, so take my questions/concerns with a grain of salt.

 

With that said, isn't one of the fundamental purposes of this docker supposed to be to provide the ability to reach into your home network via secure http without having to open up ports on your router for each and every docker?

 

For instance, I have about 10 different dockers with outside access.  Half of them are set up as subdomains where https://dockername.servername.duckdns.org will allow me to externally access what is on my internal network as 192.168.1.3:5555.  The other half are set up as subpages where https://servername.duckdns.org/dockername will allow me to access 192.168.1.3:6666.  And to accomplish this, I only have ports 443 and 80 on my router forwarded to my server.  With your suggested method, I'm just opening up another port and bypassing what I thought was the fundamental goal of this docker.

 

As far as I understand this letsencrypt/nginx concoction, it has three primary purposes. The first one is to deal with issuing/refreshing the certificates provided by letsencrypt, the second one is encrypting/decrypting/authenticating the network traffic and the third one is reverse-proxying. In my mind, it's primary purpose is to provide a secure transport mean for your data - preventing eavesdropping / modifying the data transported by encryption and authentification. The great part about nginx reverse http(s) proxying is that you can have just one port opened to the world and forwarded to wherever nginx is running and reverse-proxy the traffic to countless internal addresses.

 

It seems, however, nginx can't proxy non http(s) traffic the same way it does with http(s). One of the details that reinforced my conviction was the (commented out) part of the nginx.conf concerning mail. So, as far as http(s) traffic is concerned, everything can be dealt with with a config in the "sites-whatever" folder, utilizing either the "subdomain" or the "subpages" setup (as we're both doing with our other dockers) - forwarding it either decrypted or encrypted to the internal address responding to the requested one. And just one port opened and forwarded to letsencrypt's docker is enough for any amount of internal addresses. Unfortunately, the non http(s) traffic (possibly because other types don't format their requests/data the same way or don't support/need/use some of the things http(s) does) has to be dealt with this "streams" thingy. And it seems it has to have a port forwarded to the letsencrypt/nginx docker for every internal address being served/proxied to. 

 

As far as I understand, and please someone correct me if I'm wrong, you're not losing the critical part of the setup - the authentication/encryption by forwarding another port to the letsencrypt docker, as you would if you forwarded ports directly to individual dockers (provided, of course, you didn't setup individual "secure connections" on each and every one of them), your traffic is still being encrypted/decrypted/authenticated/proxied by letsencrypt/nginx, it's just that you need another "point of entry" to the letsencrypt/nginx docker because nginx doesn't know where to direct the mqtt traffic if it comes in with the "normal" http(s) (because mqtt, it seems, can't say www). You need to "distinguish" it somehow so you can direct nginx what to do with, where to forward it, and you do it by giving it to nginx on a separate port. You're not bypassing anything.

 

I don't think having just 80 and 443 ports forwarded to letsencrypt docker makes you any more secure/resistant than you'd be if you forwarded another port to the same place. It's not the open ports that are/can be a problem, it's where they're forwarded to. So, as far as I know, this setup is providing me with the same level of (in)security I had with only ports 80 and 443 forwarded to letsencrypt/nginx with just a small level of inconvenience because I need another port forward rule (and port opened) for every non http(s) traffic I wish to proxy, better said - for every client I wish to forward non-http(s) traffic to.

 

So, TL;DR: as long as you forward port 8883 to the letsencrypt/nginx docker, and from there proxy unencrypted to 1883 port of your mqtt docker (which is what my config does, I hope), you're not bypassing anything, you won't be any less secure than you are now. It's simply that you need to distinguish the non http(s) traffic to nginx somehow and, since it's not speaking the same language, you distinguish it by giving it another port to enter through.

[ElectricBadger]

On 3/14/2018 at 12:26 PM, aptalca said:

 

No plans at the moment, however cloudflare is free and is a great option for dns. Remember, you're not tied to your registrar for dns. All you need to do is get a cloudflare account and point your name servers there

 

True, though the last time I looked at cloudflare, I got a redirect loop when I tried to view the privacy policy, which put me off somewhat.

[aptalca]

11 hours ago, ElectricBadger said:

 

True, though the last time I looked at cloudflare, I got a redirect loop when I tried to view the privacy policy, which put me off somewhat.

 

Cloudflare is a pretty legit service. They have many big clients and a good percentage of the internet goes through their servers (As of 2015, it was the most popular CDN, used by 3.9% of all websites)

[ElectricBadger]

5 hours ago, aptalca said:

 

Cloudflare is a pretty legit service. They have many big clients and a good percentage of the internet goes through their servers (As of 2015, it was the most popular CDN, used by 3.9% of all websites)

 

Sure — but I still don't provide personal details to anyone without first checking they're not going to spam me with their own marketing.

 

On the other hand, it looks like there's progress in Gandi support for certbot, so maybe this could do it once that plugin (hopefully!) gets included as part of the standard certbot install: https://github.com/certbot/certbot/issues/5582#issuecomment-373476517

[NeoMatrixJR]

have LE docker on unRAID 6.4.  Was working previously...checked it yesterday and no joy.  Attempts to http validate my domain/subdomains fails.  Can't connect via HTTP.  Firewall/ports/etc. set up ok (was working previously).

I docker exec'd in to bash and I can't see that nginx is even running or listening on any ports.

Did a config backup, full remove/remove image/wipe config and re-install...still no joy.

HELP!

[saarg]

2 hours ago, NeoMatrixJR said:

have LE docker on unRAID 6.4.  Was working previously...checked it yesterday and no joy.  Attempts to http validate my domain/subdomains fails.  Can't connect via HTTP.  Firewall/ports/etc. set up ok (was working previously).

I docker exec'd in to bash and I can't see that nginx is even running or listening on any ports.

Did a config backup, full remove/remove image/wipe config and re-install...still no joy.

HELP!

 

Not much we can do without any info. 

You need to say more than it fails. Provide the docker run command, LE container log and pictures of your port forwarding. 

[NeoMatrixJR]

5 minutes ago, saarg said:

 

Not much we can do without any info. 

You need to say more than it fails. Provide the docker run command, LE container log and pictures of your port forwarding. 

Docker Command:
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="letsencrypt" --net="bridge" --privileged="true" -e TZ="America/Chicago" -e HOST_OS="unRAID" -e "EMAIL"="<redacted>" -e "URL"="<redacted>.us" -e "SUBDOMAINS"="www,<sd1>,<sd2>" -e "ONLY_SUBDOMAINS"="false" -e "DHLEVEL"="2048" -e "VALIDATION"="http" -e "DNSPLUGIN"="" -e "HTTPVAL"="true" -e "PUID"="99" -e "PGID"="100" -p 8080:80/tcp -p 4343:443/tcp -v "/mnt/user/appdata/letsencrypt":"/config":rw linuxserver/letsencrypt

 

Forwarding

 

Container log:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 10-adduser: executing...

-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/


Brought to you by linuxserver.io
We gratefully accept donations at:
https://www.linuxserver.io/donations/
-------------------------------------
GID/UID
-------------------------------------

User uid: 99
User gid: 100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
using keys found in /config/keys
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Variables set:
PUID=99
PGID=100
TZ=America/Chicago
URL=redacted.dns
SUBDOMAINS=www,<sd1>,<sd2>
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
DHLEVEL=2048
VALIDATION=http
DNSPLUGIN=
EMAIL=<redacted>
STAGING=

Backwards compatibility check. . .
No compatibility action needed
2048 bit DH parameters present
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Sub-domains processed are: -d www.redacted.dns -d <sd1>.redacted.dns -d <sd2>.redacted.dns
E-mail address entered: <redacted>
http validation is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for <sd2>.redacted.dns
http-01 challenge for <sd1>.redacted.dns
http-01 challenge for redacted.dns
http-01 challenge for www.redacted.dns
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.redacted.dns (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.redacted.dns/.well-known/acme-challenge/edxukoZRwU7EPlVpHFg142PTBBrqyU2G94dp_KmApA0: Timeout, redacted.dns (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://redacted.dns/.well-known/acme-challenge/hMixnVqD8nuDQ8WFP4rYw2NL-lWDNx-gqifbSt0Yy8Y: Timeout, <sd1>.redacted.dns (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://<sd1>.redacted.dns/.well-known/acme-challenge/gjtxzSA3iVJOr5-uEKmtJaFH_1F-u9aG1g_03Km8fYI: Timeout, <sd2>.redacted.dns (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://<sd2>.redacted.dns/.well-known/acme-challenge/IzNN34bA1ALo-7NdbqWlN63vQNvvo4PP-pvea9FCpKE: Timeout

IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: www.redacted.dns
Type: connection
Detail: Fetching
http://www.redacted.dns/.well-known/acme-challenge/<redacted>:
Timeout

Domain: redacted.dns
Type: connection
Detail: Fetching
http://redacted.dns/.well-known/acme-challenge/<redacted>:
Timeout

Domain: <sd1>.redacted.dns
Type: connection
Detail: Fetching
http://<sd1>.redacted.dns/.well-known/acme-challenge/<redacted>:
Timeout

Domain: <sd2>.redacted.dns
Type: connection
Detail: Fetching
http://<sd2>.redacted.dns/.well-known/acme-challenge/<redacted>:
Timeout

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container

 

[NeoMatrixJR]

Got it sorted...kind of.  Transmission VPN docker was eating all traffic forwarded from my router to my server....not sure how to fix yet except turn off that docker...which hasn't been used in a while...so that's fine for now.

[aptalca]

17 hours ago, ElectricBadger said:

 

Sure — but I still don't provide personal details to anyone without first checking they're not going to spam me with their own marketing.

 

On the other hand, it looks like there's progress in Gandi support for certbot, so maybe this could do it once that plugin (hopefully!) gets included as part of the standard certbot install: https://github.com/certbot/certbot/issues/5582#issuecomment-373476517

 

You don't need to provide any personal info to cloudflare other than an email address (use a burner one) and the ip it should forward to. 

[sjp770]

So my letsencrypt docker stopped working.. Ive blown it away and started again but it doesnt seem to write anything into the logs for me to check why its not working. Any recent changes that would stop my old config files from working?