[Request/Done] Let's Encrypt Container


rix

Recommended Posts

Hello aptalca (and others),

 

Can someone point me in the right direction, I have two questions/issues. One needs fixing, one is something I want to change.

I'm sure these have been asked and answered, but my quick looking didn't turn anything up.

 

1. I've had this docker running for a while, with a htpassword on my primary domain (ex, unraid.domain.space).

 

Going there generates a password prompt. Good. However, all the proxies (ex, unraid.domain.space/sonarr) do NOT prompt for a password, and are basically wide open. What did I do wrong to miss getting the password on those? If I should add a config/etc, just let me know. I'm hoping it is just something stupid I messed up. None of my docker apps themselves are using passwords/etc that might be built in, so I though I was relying on the htpassword prompt.

 

2. I'd also like to move from doing unraid.domain.space/sonarr to sonarr.domain.space. Any links/info on how i'd setup those kind of subdomains instead? (I'd like to do all subdomains for these instead of .space/appname). 

 

Thanks in advance!

Link to comment
4 minutes ago, 00b5 said:

Going there generates a password prompt. Good. However, all the proxies (ex, unraid.domain.space/sonarr) do NOT prompt for a password, and are basically wide open. What did I do wrong to miss getting the password on those? If I should add a config/etc, just let me know. I'm hoping it is just something stupid I messed up. None of my docker apps themselves are using passwords/etc that might be built in, so I though I was relying on the htpassword prompt.

Add 

auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;

to each location block that you want to protect.

 

location /radarr {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
	include /config/nginx/proxy.conf;
		proxy_pass http://192.168.0.2:7878/radarr;
	}

 

Link to comment
Hello aptalca (and others),
 
Can someone point me in the right direction, I have two questions/issues. One needs fixing, one is something I want to change.
I'm sure these have been asked and answered, but my quick looking didn't turn anything up.
 
1. I've had this docker running for a while, with a htpassword on my primary domain (ex, unraid.domain.space).
 
Going there generates a password prompt. Good. However, all the proxies (ex, unraid.domain.space/sonarr) do NOT prompt for a password, and are basically wide open. What did I do wrong to miss getting the password on those? If I should add a config/etc, just let me know. I'm hoping it is just something stupid I messed up. None of my docker apps themselves are using passwords/etc that might be built in, so I though I was relying on the htpassword prompt.
 
2. I'd also like to move from doing unraid.domain.space/sonarr to sonarr.domain.space. Any links/info on how i'd setup those kind of subdomains instead? (I'd like to do all subdomains for these instead of .space/appname). 
 
Thanks in advance!

If you install the linuxserver version (which is the one I'm supporting along with the rest of the team going forward) the default site config contains examples for both reverse proxy methods

Make sure you install it from scratch (empty config folder) if you need to
Link to comment

jonathanm;

 

Thanks, simple copy-paste !!

 

aptalca;

 

I missed that it was converted to linuxserver.io, so i'll look into doing that one. I got it working by adding a bunch of (two really) server{} setups, but i'll look at swapping to the other one next time, since I'm about tapped out today. Thanks!

 

Link to comment
  • 1 month later...

So I have my image passing my web traffic appropriately to my servers.  Now I'm trying to get fail2ban implemented to protect them, but I'm a bit confused how to do so.

 

For example, my one webserver sits behind the letsencrypt proxy on https and is secured with http auth.  I'd like to get fail2ban to block too many bad attempts to this server, but I'm unsure how.  I nginx-http-auth in the jail fail but I get errors when enabling.  And even with it on, I don't see the login fails showing up in the error logs anyways, since the auth is done on the backend server.  Does the auth have to be done on the proxy?  Any suggestions on how to accomplish this?  I'd also like to set up fail2ban to block auth failures for my nextcloud server.

 

Thanks in advance,

Jared

Link to comment

Fail2ban monitors the logs in the same container.

You need to set up http auth in this container so that if someone enters the wrong password, it gets logged in the nginx logs in this container. Fail2ban monitors the nginx log and tracks the auth fail messages.

If your reverse proxy container passes everything with no errors logged, fail2ban won't ban anything.

For nextcloud, you can mount the log location for nc in this container and set up fail2ban to watch those.

Link to comment
2 hours ago, aptalca said:

Fail2ban monitors the logs in the same container.

You need to set up http auth in this container so that if someone enters the wrong password, it gets logged in the nginx logs in this container. Fail2ban monitors the nginx log and tracks the auth fail messages.

If your reverse proxy container passes everything with no errors logged, fail2ban won't ban anything.

For nextcloud, you can mount the log location for nc in this container and set up fail2ban to watch those.

Hmm, I was hoping since the docker is proxing traffic it could see the errors inline with the request vs examing a log file.  In some cases, the http auto needs to remain on the server behind and I don't think I can mount the log location remotely for them.  Some services on the same server (in another docker or VM) this should be straightforward to set up but for different physicals behind the proxy it is a more difficult task.

Link to comment
Hmm, I was hoping since the docker is proxing traffic it could see the errors inline with the request vs examing a log file.  In some cases, the http auto needs to remain on the server behind and I don't think I can mount the log location remotely for them.  Some services on the same server (in another docker or VM) this should be straightforward to set up but for different physicals behind the proxy it is a more difficult task.


Fail2ban is simply a log parser. If whatever criteria/trigger you're looking for is in a log accessible by fail2ban, it can monitor that and take action.
Link to comment

Hi guys,

 

Could you please help me with the setup of letsencrypt docker.

 

I have followed this guide https://cyanlabs.net/tutorials/the-complete-unraid-reverse-proxy-duck-dns-dynamic-dns-and-letsencrypt-guide/ closely but i could not even access the nginx default webpage up and running.

 

There is no log in letsencrypt configuration folder.

 

port has been changed from 80 to 81 for HTTP and 4430 for HTTPS

 

I know there is not a lot of information but this is my second days trying to use UNRAID. I think UNRAID is pretty amazing and has great potential (coming from a guy who previously using XPenology - something just work out of the box).

 

Many thanks guys 

Link to comment
Hi guys,

 

Could you please help me with the setup of letsencrypt docker.

 

I have followed this guide https://cyanlabs.net/tutorials/the-complete-unraid-reverse-proxy-duck-dns-dynamic-dns-and-letsencrypt-guide/ closely but i could not even access the nginx default webpage up and running.

 

There is no log in letsencrypt configuration folder.

 

port has been changed from 80 to 81 for HTTP and 4430 for HTTPS

 

I know there is not a lot of information but this is my second days trying to use UNRAID. I think UNRAID is pretty amazing and has great potential (coming from a guy who previously using XPenology - something just work out of the box).

 

Many thanks guys 

 

Port 443 on the wan should forward to port 443 inside the container. Since you mapped 4430 in unraid to 443 in the container, your router should be forwarding outside 443 to 4430 on the unraid IP

 

Link to comment
3 hours ago, aptalca said:

Port 443 on the wan should forward to port 443 inside the container. Since you mapped 4430 in unraid to 443 in the container, your router should be forwarding outside 443 to 4430 on the unraid IP

 

 

Port mapping:

 

Internet port 80 (Router) => 81 port Unraid Container

Internet port 443 (Router) => 4430 port Unraid Container

 

The thing is I could not see the default nginx webpage even if I connect it locally, example: Laptop connect to UNRAID Letsencrypt Container by http://192.168.0.29:81 or https://192.168.0.29:4430

 

Many thanks guys

Link to comment
 
Port mapping:
 
Internet port 80 (Router) => 81 port Unraid Container
Internet port 443 (Router) => 4430 port Unraid Container
 
The thing is I could not see the default nginx webpage even if I connect it locally, example: Laptop connect to UNRAID Letsencrypt Container by http://192.168.0.29:81 or https://192.168.0.29:4430
 
Many thanks guys


The certificate works for the domain name / url, not ip address. You have to go to https://your.domain.com

Post your docker container settings and a log for further assistance
Link to comment

I think there might be something wrong with my network set up, i have try other docker such as openvpn-as and if i change thenetwork type to host (instead of bridge) i could not connect to anh docker port. Network type bridge worked on openvpn-as but it did not work on letsncrypt.

 

And furthermore, isn't it true that port forwarding will only work if docker works i  the first place! 

 

Quote from cyanlab:

Since we have set the internal docker port to be 81 you can currently visit the nginx default webpage by going to your UnRAID ip at port 81. For me it would be this http://192.168.1.3:81 or https://192.168.1.3. We now need to forward ports in your router, i’m not going to go over this as its different for each router but basically you need to forward external port 80 and 443 to internal port 81 and 443 to your UnRAID IP which for me is 

 

my network is currently set to IEEE 802.3ad (LACP).

 

my server log:

 

Quote

May 14 04:40:01 LILOTOWER root: Fix Common Problems Version 2017.04.17
May 14 04:40:06 LILOTOWER root: Fix Common Problems: Error: Docker application Krusader has volumes being passed that are mounted by Unassigned Devices, but they are not mounted with the slave option
May 14 04:40:06 LILOTOWER root: Fix Common Problems: Error: Docker Application letsencrypt, Container Port 80 not found or changed on installed application
May 14 04:40:06 LILOTOWER root: Fix Common Problems: Error: Docker Application openvpn-as is currently set up to run in bridge mode
May 14 04:40:08 LILOTOWER root: Fix Common Problems: Warning: Dynamix SSD Trim Plugin Not installed
May 14 08:41:13 LILOTOWER kernel: docker0: port 2(vethf26b918) entered disabled state
May 14 08:41:13 LILOTOWER kernel: vethf9ad011: renamed from eth0
May 14 08:41:13 LILOTOWER kernel: docker0: port 2(vethf26b918) entered disabled state
May 14 08:41:13 LILOTOWER kernel: device vethf26b918 left promiscuous mode
May 14 08:41:13 LILOTOWER kernel: docker0: port 2(vethf26b918) entered disabled state
May 14 09:47:40 LILOTOWER emhttp: cmd: /usr/local/emhttp/plugins/fix.common.problems/scripts/showExtendedLog.sh
May 14 09:49:36 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered blocking state
May 14 09:49:36 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered disabled state
May 14 09:49:36 LILOTOWER kernel: device vethfc62dc5 entered promiscuous mode
May 14 09:49:36 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered blocking state
May 14 09:49:36 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered forwarding state
May 14 09:49:36 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered disabled state
May 14 09:49:36 LILOTOWER kernel: eth0: renamed from veth0a7c722
May 14 09:49:36 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered blocking state
May 14 09:49:36 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered forwarding state
May 14 09:49:47 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered disabled state
May 14 09:49:47 LILOTOWER kernel: veth0a7c722: renamed from eth0
May 14 09:49:47 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered disabled state
May 14 09:49:47 LILOTOWER kernel: device vethfc62dc5 left promiscuous mode
May 14 09:49:47 LILOTOWER kernel: docker0: port 2(vethfc62dc5) entered disabled state
May 14 09:50:03 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered blocking state
May 14 09:50:03 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered disabled state
May 14 09:50:03 LILOTOWER kernel: device veth37ff6a0 entered promiscuous mode
May 14 09:50:03 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered blocking state
May 14 09:50:03 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered forwarding state
May 14 09:50:03 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered disabled state
May 14 09:50:03 LILOTOWER kernel: eth0: renamed from veth3d319dc
May 14 09:50:03 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered blocking state
May 14 09:50:03 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered forwarding state
May 14 09:50:14 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered disabled state
May 14 09:50:14 LILOTOWER kernel: veth3d319dc: renamed from eth0
May 14 09:50:15 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered disabled state
May 14 09:50:15 LILOTOWER kernel: device veth37ff6a0 left promiscuous mode
May 14 09:50:15 LILOTOWER kernel: docker0: port 2(veth37ff6a0) entered disabled state
May 14 09:50:24 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered blocking state
May 14 09:50:24 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered disabled state
May 14 09:50:24 LILOTOWER kernel: device vethdccbe79 entered promiscuous mode
May 14 09:50:24 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered blocking state
May 14 09:50:24 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered forwarding state
May 14 09:50:24 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered disabled state
May 14 09:50:24 LILOTOWER kernel: eth0: renamed from veth2fe2b21
May 14 09:50:24 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered blocking state
May 14 09:50:24 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered forwarding state
May 14 09:50:39 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered disabled state
May 14 09:50:39 LILOTOWER kernel: veth2fe2b21: renamed from eth0
May 14 09:50:40 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered disabled state
May 14 09:50:40 LILOTOWER kernel: device vethdccbe79 left promiscuous mode
May 14 09:50:40 LILOTOWER kernel: docker0: port 2(vethdccbe79) entered disabled state

 

Edited by phoanglong
Addmlo
Link to comment

As I wrote before, you need to post your container settings and the log for the container. Otherwise we have no idea what's going on.

If letsencrypt cert generation is unsuccessful, nginx will not start due to nonexistent certs. So you won't be able to see the webpage even on port 80/81

Link to comment

dear aptalca,

 

thank you for your help and support, i was on my mobile so it quite hard for me to post all the necessary logs, please excuse me.

 

Please have a look at my log for the container as below

 

Quote

[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...
generating self-signed keys in /config/keys, you can replace these with your own keys if required
Generating a 2048 bit RSA private key
..........+++
.........+++
writing new private key to '/config/keys/cert.key'
-----
Subject Attribute /C has no known NID, skipped
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 50-config: executing...
Creating DH parameters for additional security. This may take a very long time. There will be another message once this process is completed
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
.........................+.......................................................................................+................................................................................................................................................................................................................................................................................................................................................................................+....................+.........................................................+.........................+..................................................................................................................................................+.............................................................................................................................................+.........................................................................................................................+............................................................................................................+...........................................................................+.........................................................................+...............................................................................................................................................................................................+.....................................................................................................................+..................+...............................+..................................+.................................................................+..............................+.........................................................................................................................................+.........................................................+..........................................................................................+.............+...................................................+..................................................................+...........................................................................................................................................................................................................+.......................................................................+....+..........+........................+......................................................................................................................................................................................................................................................+..................................+..................+..................................................................+................................................................................................................................................................................................++*++*
DH parameters successfully created - 2048 bits
SUBDOMAINS entered, processing
Sub-domains processed are: -d www.my_purchased_domain -d cloud.my_purchased_domain -d download.my_purchased_domain -d sickrage.my_purchased_domain -d couchpotato.my_purchased_domain
Generating new certificate
WARNING: The standalone specific supported challenges flag is deprecated.

Please use the --preferred-challenges flag instead.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for my_purchased_domain
tls-sni-01 challenge for www.my_purchased_domain
tls-sni-01 challenge for cloud.my_purchased_domain
tls-sni-01 challenge for download.my_purchased_domain
tls-sni-01 challenge for sickrage.my_purchased_domain
tls-sni-01 challenge for couchpotato.my_purchased_domain
/usr/lib/python2.7/site-packages/OpenSSL/rand.py:58: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
result_code = _lib.RAND_bytes(result_buffer, num_bytes)
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.my_purchased_domain (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 14.162.136.2:443 for tls-sni-01 challenge

IMPORTANT NOTES:
- If you lose your account credentials, you can recover through
e-mails sent to [email protected].
- The following errors were reported by the server:

Domain: www.my_purchased_domain
Type: connection
Detail: Failed to connect to 14.162.136.2:443 for tls-sni-01

challenge

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A 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.
- 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.
/var/run/s6/etc/cont-init.d/50-config: line 108: cd: /config/keys/letsencrypt: No such file or directory
[cont-init.d] 50-config: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

 

Link to comment

Is 14.162.136.2 your WAN IP? And is 443 open on your router and forwarded to your Unraid box.

Also make sure your domain name supplier DNS record is correct and no placeholder or similar is stopping the process.

Sent from my LG-H815 using Tapatalk

Link to comment
13 minutes ago, CHBMB said:

Is 14.162.136.2 your WAN IP? And is 443 open on your router and forwarded to your Unraid box.

Also make sure your domain name supplier DNS record is correct and no placeholder or similar is stopping the process.

Sent from my LG-H815 using Tapatalk
 

 

My DNS is dynamic and at the moment it is corrected. (i should hide it thought), also, the port 443 is open and forwarded.

 

2017-05-14_18-08-59.png.67b1789812b898898df2b8ef8e8fec5e.png

Link to comment

@CHBMB Thank you so much for the quick reply, i have started again with simple just my domain (www). DNS is corrected as i can navigate through my 4G network to my server. Please have a look at my attachment and thank you for pointing me out to the right thread. Many thanks

2017-05-14_18-24-44.png

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.