40 minutes ago, ZipsServer said:

I couldn't find a README 

 

It's linked on the very first post.  On both dockerhub and github.

9 hours ago, CHBMB said:

 

That's interesting, I use Namecheap and up until this week used their nameservers and never had an issue.  Switched to cloudflare now, just so I can get a wildcard cert, nothing to do with performance.

 

 

Yeah.  I don't really know what the deal is.  All I know is it has worked without any issue since making the change.  I'm just glad to have it sorted out.  It was really driving me nuts.

On 8/11/2018 at 3:22 PM, CHBMB said:

 

It's linked on the very first post.  On both dockerhub and github.

Thanks for the reply. Yes I read the main README, but it do not seem to specify how to use a DNS provider other than the ones listed. It seems that I am missing something obvious or that it is not possible. 

 

Thanks for the reply. Yes I read the main README, but it do not seem to specify how to use a DNS provider other than the ones listed. It seems that I am missing something obvious or that it is not possible. 
 

Namecheaps API isn't compatible with DNS Auth, I changed my DNS provider to Cloudflare and used their DNS plugin.

Sent from my Mi A1 using Tapatalk

Can anyone help with this?  I updated letsencrypt today and now nothing is working.  No other changes have been made.   It's as if everything is trying to go over 8443 (which is what my UNRAID server is set to since there was a conflict between letsencrypt 443 and UNRAID 443.  This is the error I'm getting:

 

2048 bit DH parameters present
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Sub-domains processed are: -d nextcloud.xxx.com -d office.xxx.com -d apps.xxx.com
E-mail address entered: [email protected]
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
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 apps.xxx.com
http-01 challenge for xxx.com
http-01 challenge for nextcloud.xxx.com
http-01 challenge for office.xxx.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. apps.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, office.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, nextcloud.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443
IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: apps.xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Domain: office.xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Domain: nextcloud.xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Domain:xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Can anyone help with this?  I updated letsencrypt today and now nothing is working.  No other changes have been made.   It's as if everything is trying to go over 8443 (which is what my UNRAID server is set to since there was a conflict between letsencrypt 443 and UNRAID 443.  This is the error I'm getting:
 
2048 bit DH parameters present
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Sub-domains processed are: -d nextcloud.xxx.com -d office.xxx.com -d apps.xxx.com
E-mail address entered: [email protected]
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
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 apps.xxx.com
http-01 challenge for xxx.com
http-01 challenge for nextcloud.xxx.com
http-01 challenge for office.xxx.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. apps.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, office.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, nextcloud.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443
IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: apps.xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Domain: office.xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Domain: nextcloud.xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Domain:xxx.com
Type: connection
Detail: Fetching
https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:
Invalid port in redirect target. Only ports 80 and 443 are
supported, not 8443

Post your docker run command and screenshots of your port forwarding.

Sent from my Mi A1 using Tapatalk

Originally, I only had 443 and 32400, but I've since added 80 & 81 to troubleshoot the issue.  No luck.  Here are the screenshots you requested.  Thanks for taking a look.

51 minutes ago, chiaramontef said:

Originally, I only had 443 and 32400, but I've since added 80 & 81 to troubleshoot the issue.  No luck.  Here are the screenshots you requested.  Thanks for taking a look.

 

Your port forwarding for port 80 is wrong. You should forward 80 from outside to 81.

That is probably why it's answering with the unraid.net adress.

52 minutes ago, chiaramontef said:

Originally, I only had 443 and 32400, but I've since added 80 & 81 to troubleshoot the issue.  No luck.  Here are the screenshots you requested.  Thanks for taking a look.

 

So you have port 81 (external internet facing) port forwarded to port 81 on your unraid and inside the container is port 80, is that correct?

1 minute ago, saarg said:

 

Your port forwarding for port 80 is wrong. You should forward 80 from outside to 81.

That is probably why it's answering with the unraid.net adress.

 

 

saarg beat me to it.

Great catch.  That was a facepalm moment, thanks for the help!

Hi folks.

Had to start over (too much messing around with the conf files and default)...

So I've downloaded a new copy of LetsEncrypt (called it letsencrypt-temp, saved to an appdata folder by the same name) to create a new configuration, and noticed the sample files added for subdomains, which is a very elegant and helpful solution to what I need.

The problem I'm having is with:

Quote

These confs also assume that the letsencrypt container can reach other containers via their dns hostnames (defaults to 
container name) resolved via docker's internal dns

 All of my containers are defined with capitalization of their name (OCD anyone? ?) and I really want to keep it that way.

I've tried for instance to change the "transmission.subdomain.conf" file to point $upstream_transmission to "Transmission" instead of "transmission", but it doesn't work.

I get the error:

Quote

transmission could not be resolved (3: Host not found), client: 192.168.1.1, server: tr.*, request: "GET /favicon.ico HTTP/1.1", host: "tr.my.domain", referrer: "https://tr.my.domain/transmission/web/"

in the error log.

Any help would be appreciated.

 

You also need to create a custom docker network so the DNS name resolution works.

Thanks for the quick reply.

I did create the custom network (as mentioned in _readme) and doing a DNS resolution inside the letsencrypt container returns:

root@2610736c55ba:/$ nslookup Transmission 127.0.0.11
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      Transmission
Address 1: 172.18.0.3 Transmission.docknet
root@2610736c55ba:/$ nslookup transmission 127.0.0.11
Server:    127.0.0.11
Address 1: 127.0.0.11

nslookup: can't resolve 'transmission': Name does not resolve

 

Edited August 14, 20187 yr by gshlomi

ok, please be kind, my brain is moosh trying to go thru 92 pages, and search didnt help either

 

am trying to setup subdomain medusa, there is no sample avail so here is my try, but I am getting bad gateway, I know its something simple., but I Just cant see it atm

 

# make sure that your dns has a cname set for medusa
# to enable password access, uncomment the two auth_basic lines

server {
    listen 443 ssl;

    server_name medusa.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
#        auth_basic "Restricted";
#        auth_basic_user_file /config/nginx/.htpasswd;
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_medusa binhex-medusa;
        proxy_pass http://$upstream_medusa:8082;
    }
}

yes, i am using binhex still - but am planing on moving over soon....

 

Error log shows:

2018/08/14 20:28:11 [error] 386#386: *6 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: medusa.*, request: "GET /favicon.ico HTTP/1.1", upstream: "http://172.18.0.4:8082/favicon.ico", host: "medusa.townecrier.extensionhidden", referrer: "https://medusa.townecrier.extensionhidden/"

Please help me, thanks

Myk

Edited August 15, 20187 yr by MyKroFt

ok, please be kind, my brain is moosh trying to go thru 92 pages, and search didnt help either

 

am trying to setup subdomain medusa, there is no sample avail so here is my try, but I am getting bad gateway, I know its something simple., but I Just cant see it atm

 

# make sure that your dns has a cname set for medusa# to enable password access, uncomment the two auth_basic linesserver {   listen 443 ssl;   server_name medusa.*;   include /config/nginx/ssl.conf;   client_max_body_size 0;   location / {#        auth_basic "Restricted";#        auth_basic_user_file /config/nginx/.htpasswd;       include /config/nginx/proxy.conf;       resolver 127.0.0.11 valid=30s;       set $upstream_medusa binhex-medusa;       proxy_pass http://$upstream_medusa:8082;   }}

yes, i am using binhex still - but am planing on moving over soon....

 

Error log shows:

 

2018/08/14 20:28:11 [error] 386#386: *6 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: medusa.*, request: "GET /favicon.ico HTTP/1.1", upstream: "http://172.18.0.4:8082/favicon.ico", host: "medusa.townecrier.extensionhidden", referrer: "https://medusa.townecrier.extensionhidden/"

Please help me, thanks

Myk

 

You added it to the subdomain variable and registered a cname with your domain provider? You also have the custom network interface?

 

Sent from my SM-G930W8 using Tapatalk

 

 

 

14 minutes ago, Gog said:

You added it to the subdomain variable and registered a cname with your domain provider? You also have the custom network interface?

 

Sent from my SM-G930W8 using Tapatalk

 

 

 

 

yes I have my own domain name, nextcloud and others are working just fine.  I: can access medusa via local ip, but when I try https://medusa.townecrier.domain I get bad gateway

2 hours ago, MyKroFt said:

yes I have my own domain name, nextcloud and others are working just fine.  I: can access medusa via local ip, but when I try https://medusa.townecrier.domain I get bad gateway

 

I'm far from a nginx expert but everything I check seems OK.  Found @CHBMB's config problems on github but the only directive that seems to be needed, outside of the standard proxy.conf, is proxy_pass. Sorry...

 

 

9 minutes ago, Gog said:

 

I'm far from a nginx expert but everything I check seems OK.  Found @CHBMB's config problems on github but the only directive that seems to be needed, outside of the standard proxy.conf, is proxy_pass. Sorry...

 

 

 

Ya I found that as well, but am still at a loss of why I: am getting Bad Gateway, hopefully someone who know more than I do, will see this and can push me in the right direction.

Thanks

 

1 hour ago, MyKroFt said:

 

Ya I found that as well, but am still at a loss of why I: am getting Bad Gateway, hopefully someone who know more than I do, will see this and can push me in the right direction.

Thanks

 

Binhex-medusa's internal port is 8081

1 hour ago, aptalca said:

Binhex-medusa's internal port is 8081

 

Thank you very much, that is what it was, I was using the external port instead of internal.  I am now understanding this much more.

 

Appreciated!

 

I just got letsencrypt working again (long story) but now I have a question: how can I reverse proxy into a container on a different unraid server?

I am running multiple servers and now need to use the letsencrypt docker on one of them and reverse proxy into the other server from the outside

it kinda looks like this in my head:

 

couchpotato  >>> internet >> letsencrypt >>>>> tower 1  (this works fine)

                                                         |                       |   

unifi controller >>> internet >>>                            >>>>> tower 2  (this one not so good)

 

So I think that I have to somehow connect the two different docker networks( on tower1 and tower2)  together so that the correct stuff gets sent to the right place. Tried a few things, but thought I should ask before I make a really big mess here. Took a look at the "docker network" command but couldn't make heads or tails of it I think because I don' t know why?.  just need a little direction.

 

ThanX

Michael

 

7 hours ago, mikeyw said:

I just got letsencrypt working again (long story) but now I have a question: how can I reverse proxy into a container on a different unraid server?

I am running multiple servers and now need to use the letsencrypt docker on one of them and reverse proxy into the other server from the outside

it kinda looks like this in my head:

 

couchpotato  >>> internet >> letsencrypt >>>>> tower 1  (this works fine)

                                                         |                       |   

unifi controller >>> internet >>>                            >>>>> tower 2  (this one not so good)

 

So I think that I have to somehow connect the two different docker networks( on tower1 and tower2)  together so that the correct stuff gets sent to the right place. Tried a few things, but thought I should ask before I make a really big mess here. Took a look at the "docker network" command but couldn't make heads or tails of it I think because I don' t know why?.  just need a little direction.

 

ThanX

Michael

 

 

If the containers are on separate servers, then simply use the host ip and port to reverse proxy

I'm trying to use the Cloudflare DNS + HTTP proxy which I can't seem to get working as I want.

 

What I have is a Let's Encrypt set up, in Cloudflare I created CNAME's which redirect to my DuckDNS domain. When I put off the proxy mode in Cloudflare my personal domain and subdomains resolve to the right dockers. However, when I put on the HTTP proxy in Cloudflare, the (sub)domain can't resolve anymore.

 

Should what I'm trying to do work, or is it impossible? I'd prefer not to put my WAN IP out in the open, so the HTTP proxy would be very useful.

I'm trying to use the Cloudflare DNS + HTTP proxy which I can't seem to get working as I want.
 
What I have is a Let's Encrypt set up, in Cloudflare I created CNAME's which redirect to my DuckDNS domain. When I put off the proxy mode in Cloudflare my personal domain and subdomains resolve to the right dockers. However, when I put on the HTTP proxy in Cloudflare, the (sub)domain can't resolve anymore.
 
Should what I'm trying to do work, or is it impossible? I'd prefer not to put my WAN IP out in the open, so the HTTP proxy would be very useful.

If your ISP is not blocking port 80 why are you trying to use DNS?



Sent from my BND-L34 using Tapatalk

4 hours ago, ijuarez said:

If your ISP is not blocking port 80 why are you trying to use DNS?



Sent from my BND-L34 using Tapatalk
 

 

I might have not been clear. I have a personal domain (not the duckdns). So that domain needs DNS settings for the CNAME's, which I like Cloudlfare's interface for.