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


Recommended Posts

14 minutes ago, Living Legend said:

 

Figured out that my redirect of the unRAID HTTPS port to 445 created some unknown conflict.  442 worked.

 

442 worked, but no external access.  I imagine this is a port forwarding issue.  I thought this looked right, but apparently something is still wrong.  I'll keep reading...

 

image.png.c455c3c088f4f34784b232273a39b503.png

 

image.png.f93f3417127c85791068f7bf807aedbf.png

 

EDIT:  Restarted the docker one more time.  Now it's working.  Go figure.

Edited by Living Legend
Link to comment
47 minutes ago, CorneliousJD said:

EDIT: Thanks I'll look into the nginx redirect part, and see if I can find a way to disable HSTS as well due to the below issue I had just posted. Unless someone knows a quick way to disable HSTS?

 

Another, separate issue - I use my www.mydomain.com as kind of a shortcut page to other services, e.g. a shortcut on there links to my UniFi setup, which runs HTTPS on a different port than 443, and obviously doesn't use the same certificate. When I try to browse to that site I get 

 

Because this site uses HTTP Strict Transport Security, you can’t continue to this site at this time. 

That's in IE, and in Chrome it shows

You cannot visit mydomain.com right now because the website uses HSTS. 

 

So I made progress on this - I got HSTS disabled - that worked okay. And I got HTTP to HTTPS redirect working, but that caused another problem. I have links on that site to http://mydomain.com:8881 etc that do not use HTTPS because it is not supported or offered. To try and get around this I tried to set a location on my redirect but that doesn't seem to be working to let it through on http:// only, it still tries to force an HTTPS redirect. 

 

My default site conf looks like this at the top


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

  • Like 1
Link to comment
8 hours ago, CorneliousJD said:

 

So I made progress on this - I got HSTS disabled - that worked okay. And I got HTTP to HTTPS redirect working, but that caused another problem. I have links on that site to http://mydomain.com:8881 etc that do not use HTTPS because it is not supported or offered. To try and get around this I tried to set a location on my redirect but that doesn't seem to be working to let it through on http:// only, it still tries to force an HTTPS redirect. 

 

My default site conf looks like this at the top


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

 

If port 8881 on your router is forwarded to the same port 80 in the container, nginx won't know the difference. Map a separate port into the container for that and create a new server block listening at that port

 

EDIT: On second read, if it's a different container, you shouldn't have that problem (I think). I do that too with emby, but it uses https. Perhaps browser cache from before causing issues? 

Edited by aptalca
Link to comment
On 1/13/2018 at 3:45 PM, Taddeusz said:

 

I already did just to make sure things haven't changed but Cox Cable blocks port 80.

 

Verified as well. Let's Encrypt needs to allow other ports than 80, this is just silly. LSIO Nginx container will have to work until something changes. If I could get another ISP that offered 300mb/s connections where I live I would be all over it.

Link to comment

hey guys, woke up this morning to a couple errors in letsencrypt out of no where, haven't changed the setting since i got it working months ago so i really dont know how to fix it :( 

Here's the log;

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...
2048 bit DH parameters present
SUBDOMAINS entered, processing
Sub-domains processed are: -d akrapps.akrapps.duckdns.org
E-mail address entered: [email protected]
Different sub/domains entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created
usage:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: argument --cert-path: No such file or directory

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:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
IMPORTANT NOTES:
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
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

 

screenshot of letsencrypt settings gwEmTIj.png

 

i made sure all the duckdnsdns settings are good reinstalled both letsencrypt and ducksdns, and made sure the ports (81, 443) are still forwarded, but no use, its been working great for the past 4+ months so idk honestly.

Link to comment
6 minutes ago, AKR said:

hey guys, woke up this morning to a couple errors in letsencrypt out of no where, haven't changed the setting since i got it working months ago so i really dont know how to fix it :( 

Here's the log;


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...
2048 bit DH parameters present
SUBDOMAINS entered, processing
Sub-domains processed are: -d akrapps.akrapps.duckdns.org
E-mail address entered: [email protected]
Different sub/domains entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created
usage:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: argument --cert-path: No such file or directory

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:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
IMPORTANT NOTES:
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
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

 

screenshot of letsencrypt settings gwEmTIj.png

 

i made sure all the duckdnsdns settings are good reinstalled both letsencrypt and ducksdns, and made sure the ports (81, 443) are still forwarded, but no use, its been working great for the past 4+ months so idk honestly.

 

Might be an idea to look at the last few pages for a solution.

Link to comment
12 hours ago, aptalca said:

 

If port 8881 on your router is forwarded to the same port 80 in the container, nginx won't know the difference. Map a separate port into the container for that and create a new server block listening at that port

 

EDIT: On second read, if it's a different container, you shouldn't have that problem (I think). I do that too with emby, but it uses https. Perhaps browser cache from before causing issues? 

 

Thanks for the second read on that - I had cleared cache a few times via automated tools but that didn't work... tried on a laptop that hadn't visited the site before at all and everything was good, so was totally a cache issue. doh. 

 

I cleared manually on my main desktop and everything was fine. Time to stop trusting tools to do things for me. :)

 

Thanks for everything, all running how I want it to now with HTTPS from Let's Encrypt! Awesome job LSIO Team!

Link to comment
18 hours ago, fc0712 said:

So I had problems starting the docker after updating and I changed the unraid port to 442 and the dockers seems to work again. Is there anything else I should do?

I did that too, and I cannot see why that would not be a good solution. So stick to it until you encounter a problem or someone else tells us why this would not be a good solution. 

Edited by truetype
Link to comment
6 hours ago, jonathanm said:

This looks like it might be backwards, but hard to tell with just this little snippet. Try switching original and forward-to.

 

 

Hello, thanks for the response. I switched it around and I am still having the same error. 

 

 

Edit: I was able to resolve this issue. I recommend anyone who is having the same issue as this to start here - 

 

Edited by Bisu
Link to comment
On 1/13/2018 at 12:57 AM, matthope said:

In my case, my internet provider block the port 80 so the HTTPVAL fix wont work.

 

Since TLS-SNI challenge is deactivated and I can't use HTTP challenge, I'm obligated to use the DNS-01 challenge. I've found a way to use it with this docker and cloudflare. You will need those 2 scripts ( here ) and you will need to modify the script /etc/cont-init/50-config inside the docker. 


docker exec -it [DOCKERNAME] /bin/bash
vi /etc/cont-init.d/50-config

In the file comment this line :


certbot certonly --non-interactive --renew-by-default --standalone --preferred-challenges $PREFCHAL --rsa-key-size 4096 $EMAILPARAM --agree-tos $URLS

And add this one :


certbot certonly --agree-tos --manual --manual-public-ip-logging-ok --preferred-challenges=dns --manual-auth-hook /app/authenticator.sh --manual-cleanup-hook /app/cleanup.sh --rsa-key-size 4096 $EMAILPARAM --no-eff-email $URLS

 

However, this is a one time fix since any modification to the docker is reverted when restarted. 

 

@aptalca It would be nice if the DNS-01 challenge could be added definitively to this docker.

 

 

DNS-01 challenge needs to be added to this docker per this update:

https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188

 

 

Link to comment
7 minutes ago, surfshack66 said:

 

DNS-01 challenge needs to be added to this docker per this update:

https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188

 

 

 

Aptalca adressed this in his post and said it's not happening.

 

I've reverted to the LSIO nginx container and used a script for DNS-01 verification.

 

https://github.com/Neilpang/acme.sh

 

  • Upvote 1
Link to comment
19 minutes ago, surfshack66 said:

 

DNS-01 challenge needs to be added to this docker per this update:

https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188

 

 

 

8 minutes ago, BrandonG777 said:

 

Aptalca adressed this in his post and said it's not happening.

 

I've reverted to the LSIO nginx container and used a script for DNS-01 verification.

 

https://github.com/Neilpang/acme.sh

 

 

It's been discussed and given the difficulties people have been having with http_val and the fact that dns auth would require a lot more end user configuration and understanding, it's not a viable option.....

Link to comment
1 minute ago, CHBMB said:

 

 

It's been discussed and given the difficulties people have been having with http_val and the fact that dns auth would require a lot more end user configuration and understanding, it's not a viable option.....

 

Seems like the stupid simple fix here is for Let's Encrypt to allow http verfication on ports other than 80 but maybe I'm missing something.

Link to comment
11 minutes ago, BrandonG777 said:

 

Aptalca adressed this in his post and said it's not happening.

 

I've reverted to the LSIO nginx container and used a script for DNS-01 verification.

 

https://github.com/Neilpang/acme.sh

 

 

Since this seems to be the new reality and my ISP blocks port 80 how do I go about implementing this script with unRAID and the regular nginx container?

Link to comment
Just now, BrandonG777 said:

 

Seems like the stupid simple fix here is for Let's Encrypt to allow http verfication on ports other than 80 but maybe I'm missing something.

 

Nope, you're right, it would be, but they don't

 

To be fair, most people don't have an issue with port 80 and the vast majority of problems we've seen in the thread have been down to lack of understanding on port forwarding and docker.  But I can understand how frustrating it must be for those of you with port 80 blocked.

Link to comment
16 minutes ago, Taddeusz said:

 

Since this seems to be the new reality and my ISP blocks port 80 how do I go about implementing this script with unRAID and the regular nginx container?

 

The LE container is directly replaceable by the LSIO nginx container. Probably just need to comment out your cert paths in the nginx configuration and then it will start and you can shell into the container and use the script I linked to. Unfortunately I do not have the time right now to write up a good step by step guide. I really don't have the time to deal with this in general at the moment but being I left autoupdate enabled I pretty much brought this on myself and just have to deal with the fallout.

 

EDIT: Something I probably should have mentioned, you will need DNS control of the domain in question. I use Google Domains, which allows Dynamic DNS updates within my own domain.

Edited by BrandonG777
Link to comment

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...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.