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


Recommended Posts

47 minutes ago, ijuarez said:

 

I don't have experience with ubiquity, but your  setup should not have change because of a router switch, I say you need to investigate the router.

 

I wholeheartedly agree, for starters turn off remote access to your router, and to investigate further I'd be looking at the Ubiquity forums tbh.

Link to comment
3 hours ago, ijuarez said:

 

I don't have experience with ubiquity, but your  setup should not have change because of a router switch, I say you need to investigate the router.

 

3 hours ago, CHBMB said:

 

I wholeheartedly agree, for starters turn off remote access to your router, and to investigate further I'd be looking at the Ubiquity forums tbh.

 

Thank you for both responding.  I ended up rebooting the router and my server.  Everything works again!

 

Link to comment
Is it possible to have some pages served unsecured with this server?  I tried adding some locations to the listen 80 server, but I don't know if I truly understand how to set it up.  no matter what I try, browsing to the matched uri still redirects to the secure server.

 

server {listen 80;server_name _;root /config/publicwww;index index.html index.htm index.php;location ^~ /public {	try_files $uri =404;}location / {	return 301 https://$host$request_uri;}}

Any suggestions on how to tackle this?

 

 

You're on the right track. Just keep in mind that the "location" is relative to the root.

 

The way you set it up, when a user goes to http://yoururl/public/index.html the webserver will try to serve the file located at /config/publicwww/public/index.html

 

Other things to keep in mind are, restarting the container after changes to the config files, and clearing the browser cache

Link to comment

I have setup a revser proxy and ssl cert for my primary domain xxx.tld. I know need to do the same for another domain that I own. The content is exactly the same for both domains. Should I just do a DNS redirect or whats is the preferred way to do on my other domain?

Link to comment

hi guys, thanks for the great containers. 

 

I've followed the cyanlabs guide and was able to get sonarr and radarr working through my domain name and letsencrypt. 

 

I had previously followed your tutorial on installing nextcloud on unraid with letsencrypt proxy up until the point that says "Setting Up A Letsencrypt Reverse Proxy". At this point I was able to access nextcloud from my serverip:444 and was able to configure nextcloud with my mariadb info. 

 

I then followed cyanlabs' guide to set up letsencrypt. However after following this guide, while everything else I set up (sonarr, radarr, deluge) works through my domain/location (ex: http://domain/sonarr), nextcloud is inaccessible through /nextcloud. This wasn't a big concern for me because at this point I planned to continue following your tutorial which would cause me to access next cloud at nextcloud.domain.com instead of /nextcloud anyway, however I found that I was also unable to access nextcloud on my local network through serverip:444...

 

I tried following the rest of your tutorial anyway, and I still get ERR_CONNECTION_CLOSED when I try to connect to serverip:444 and my log file shows 

nginx: [emerg] open() "/config/nginx/proxy.conf" failed (2: No such file or directory) in /config/nginx/site-confs/nextcloud:31

There is no proxy.conf file in my site-confs directory, and I didn't see a step in either tutorial to create this file (or where I should edit my default.config to reflect nextcloud.conf rather than a generic proxy.conf)

 

My nextcloud site-conf is:

server {  
    listen 443 ssl;
    server_name nextcloud.vulf.stream;

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

    ###SSL Certificates
    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem;

    ###Diffie–Hellman key exchange ###
    ssl_dhparam /config/nginx/dhparams.pem;

    ###SSL Ciphers
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    ###Extra Settings###
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

        ### Add HTTP Strict Transport Security ###
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header Front-End-Https on;

    client_max_body_size 0;

    location / {
        proxy_pass https://192.168.1.107:444/;
        proxy_max_temp_file_size 4096m;
        include /config/nginx/proxy.conf;
    }
}

And my /config/www/nextcloud/config/config.php looks like this:

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'xxxxxxxxxx',
  'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxx',
  'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'trusted_domains' => 
  array (
    0 => '192.168.1.107:444',
    1 => 'nextcloud.vulf.stream',
),
'overwrite.cli.url' => 'https://nextcloud.vulf.stream',
'overwritehost' => 'nextcloud.vulf.stream'
'overwriteprotocol' => 'https',
  'dbtype' => 'mysql',
  'version' => '12.0.0.29',
  'dbname' => 'nextcloud',
  'dbhost' => '192.168.1.107:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'zandrsn',
  'dbpassword' => 'xxxxxxxxxxxxxxxxxxxxx',
  'installed' => true,
);

Any ideas?

 

I was also just wanted to make sure that I don't need to add the nextcloud subdomain on my domain nameprovider's web console right? I'm assuming that this will redirect automatically on the server end. 

Edited by zandrsn
update
Link to comment
5 hours ago, zandrsn said:

hi guys, thanks for the great containers. 

 

I've followed the cyanlabs guide and was able to get sonarr and radarr working through my domain name and letsencrypt. 

 

I had previously followed your tutorial on installing nextcloud on unraid with letsencrypt proxy up until the point that says "Setting Up A Letsencrypt Reverse Proxy". At this point I was able to access nextcloud from my serverip:444 and was able to configure nextcloud with my mariadb info. 

 

I then followed cyanlabs' guide to set up letsencrypt. However after following this guide, while everything else I set up (sonarr, radarr, deluge) works through my domain/location (ex: http://domain/sonarr), nextcloud is inaccessible through /nextcloud. This wasn't a big concern for me because at this point I planned to continue following your tutorial which would cause me to access next cloud at nextcloud.domain.com instead of /nextcloud anyway, however I found that I was also unable to access nextcloud on my local network through serverip:444...

 

I tried following the rest of your tutorial anyway, and I still get ERR_CONNECTION_CLOSED when I try to connect to serverip:444 and my log file shows 


nginx: [emerg] open() "/config/nginx/proxy.conf" failed (2: No such file or directory) in /config/nginx/site-confs/nextcloud:31

There is no proxy.conf file in my site-confs directory, and I didn't see a step in either tutorial to create this file (or where I should edit my default.config to reflect nextcloud.conf rather than a generic proxy.conf)

 

My nextcloud site-conf is:


server {  
    listen 443 ssl;
    server_name nextcloud.vulf.stream;

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

    ###SSL Certificates
    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem;

    ###Diffie–Hellman key exchange ###
    ssl_dhparam /config/nginx/dhparams.pem;

    ###SSL Ciphers
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    ###Extra Settings###
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

        ### Add HTTP Strict Transport Security ###
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header Front-End-Https on;

    client_max_body_size 0;

    location / {
        proxy_pass https://192.168.1.107:444/;
        proxy_max_temp_file_size 4096m;
        include /config/nginx/proxy.conf;
    }
}

And my /config/www/nextcloud/config/config.php looks like this:


<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'xxxxxxxxxx',
  'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxx',
  'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
  'trusted_domains' => 
  array (
    0 => '192.168.1.107:444',
    1 => 'nextcloud.vulf.stream',
),
'overwrite.cli.url' => 'https://nextcloud.vulf.stream',
'overwritehost' => 'nextcloud.vulf.stream'
'overwriteprotocol' => 'https',
  'dbtype' => 'mysql',
  'version' => '12.0.0.29',
  'dbname' => 'nextcloud',
  'dbhost' => '192.168.1.107:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'zandrsn',
  'dbpassword' => 'xxxxxxxxxxxxxxxxxxxxx',
  'installed' => true,
);

Any ideas?

 

I was also just wanted to make sure that I don't need to add the nextcloud subdomain on my domain nameprovider's web console right? I'm assuming that this will redirect automatically on the server end. 

 

You've half followed two different guides.  I'd personally choose one and stick to it.  You need to add nextcloud to your nameprovider so the DNS queries point to your server.

Link to comment
9 hours ago, CHBMB said:

 

You've half followed two different guides.  I'd personally choose one and stick to it.  You need to add nextcloud to your nameprovider so the DNS queries point to your server.

 

Okay, thanks, I'll try to do that.

 

The only reason I followed the cyanlabs guide is because the LinuxSever guide assumed that the reader already had a Letsencrypt container installed (and a DuckDNS container pointing a domain to their server), and so didn't provide any instructions for installing it. I didn't have Letsencrypt installed yet, so needed instructions for installing it as a prerequisite for installing nextcloud. I followed every part of the LS guide after installing Letsencrypt though, and both the configs I used were from the LS guide. 

 

When you say 'add nextcloud to your nameprovider', do you mean as a cname or url redirect? I'm using namecheap and have tried to figure out what I need to do to point DNS queries to my server, but this step wasn't in either guide I followed, and I'm not sure exactly what to do. As I mentioned, Letsencrypt works with other services such as sonarr, radarr and deluge, but not with nextcloud. 

Link to comment

Hey All

 

So i successfully configured this docker to run reverse proxies for about 8 other dockers, they are all exposed (with a .htpasswd for access) over https on my duckdns domain pointing to my server. Super happy with it, thanks to many within this thread for various code snippets that helped me, and my working code is pasted below

 

What I want to do now is host a public wordpress blog, can anyone give me some insight as to how to do this? So far I have

  • installed apache docker (linuxservers.io)
  • copied (unzipped) wordpress into a folder in the www folder
  • installed the mysql docker (linuxserver.io)
  • hit wordpress config page, configured it to use the mysql db
  • wordpress is kinda locally now at 192.168.1.100:89  (via apache)
  • so now i started some random config in the NGINX  site-confs/default file that I have pasted below

 

edit:  solved my problem, here is how I did it

  • unzipped wordpress into a folder called insertmydomain2.com the www folder of ngynx
  • installed the mysql docker (linuxserver.io)
  • used the mysql workbench tool to configure a 'wordpress' schema, and create a user that can access it
  • configured my nginx default config file as per below
  • pointed A record of the the domain i am using for this wordpress to my ip address
  • hit my domain and boom, wordpress config page, easy mode from there

 

 

i really have no idea what i am doing ;)    i figured this shit out with brute force, some copy paste and lots of reading through this forum

 

# wordpress server running without https
server {
	listen 80;
	server_name insertmydomain2.com;

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

        location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		# With php5-cgi alone:
		fastcgi_pass 127.0.0.1:9000;
		# With php5-fpm:
		#fastcgi_pass unix:/var/run/php5-fpm.sock;
		fastcgi_index index.php;
		include /etc/nginx/fastcgi_params;
        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }

	location ~ \.php$ {
        fastcgi_split_path_info ^(/)(/.*)$;
	}

}

# main server with most of my dockers running on https
server {
	listen 443 ssl;

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

	server_name mydomain1.com;

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

	client_max_body_size 0;

#muximux
	location / {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.100:99;
	}
#sonarr
	location ^~ /sonarr {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.100:8989/sonarr;
	}
#couchpotato
	location ^~ /couch {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.100:5050/couch;
	}	
#transmission	
	location ^~ /transmission {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.100:9091/transmission;
	}
#sabnzbd
	location ^~ /sabnzbd {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass https://192.168.1.100:9090/sabnzbd;
	}
#plexpy
	location ^~ /plexpy {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.100:8181/plexpy;
   		proxy_bind $server_addr;
   		proxy_set_header X-Forwarded-Host $server_name;
    		proxy_set_header X-Forwarded-Ssl     on;
	}
#rutorrent
	location ^~ /rutorrent {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.100:82/;
	}
#ombi - non-restricted access
	location ^~ /ombi {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.100:86/ombi;
	}
#pi-hole
	location ^~ /pihole {
		auth_basic "Restricted";
		auth_basic_user_file /config/nginx/.htpasswd;
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.4/admin/;
	}


}

 

TODO   any help would be appreciated:

 

Figure out how to host the wordpress site on port 443 https on its unique domain, without breaking everything else currently running in the 443 server block on their seperate duckdns.org domain

 

 

Edited by MulletBoy
more gooderer
Link to comment

Hi,

 

I have another Question regarding "LetsEncrypt"-Docker togehter with NextCloud-Docker

 

My physical Setup:

 

DLS --> Router --> Switch 

On the Switch I have my PC and UnRaid

 

I have a public DNS with "cloud.domain.com" pointing to the public IP of the router.

The public IP has a 1:1 NAT to the LetsEncrypt-Docker with NAT-Loopback.

 

The Nexcloud Client on my Notebook is pointing to the public domain and this works within my network as well as outside.

Drawback: Within my network the traffic is alsways going via the ROuter and not directly from one Switch-Port to the other Switchport due to the fact that I am using the public domain.

 

My router has CPU troubles when big files are transmitted.

 

But I think there is nothing I can do? 

 

Br,

Johannes

Link to comment
12 hours ago, CHBMB said:

The prerequisite to getting nextcloud working is you should be able to hit nextcloud.server.com from WAN, so you will need a c-name record.

Sent from my LG-H815 using Tapatalk
 

Thanks for the help; got this bit sorted, with my subdomain routing to my unraid server. Still having issues with nextcloud however, so I scrapped my installs of letsencrypt and nextcloud to start again with fresh configs. I have some questions about the nextcloud install, but I'll ask in that thread instead.

Link to comment

Hi,

 

In the past I was using seperate virtual ips for my dockers but due to the limitation that the dockers are not able to talk with the UnRaid Main Interface I wanted to go back with a single IP but mapped ports. With the dedicated IPs I had no issues with certs.

 

I have the following dockers:

1) OpenVPN port 443 with manual generated Certificate

2) Nextcloud on port 449

3) Letsencrypt on port 448 with vhost for nextcloud to redirect to 449

 

On the Public Network I have 2 static IPs.

On the DNS I have:

1) openvpn.domain.com --> IP1

2) nextcloud.domain.com --IP2

 

On the ROuter I have the following NAT Rules

1) IP1-443 --> Unraid-443

2) IP2-443 --> Unraid-448

 

If I now access nextcloud.domain.com from public, the certificate is green.

But If I acess the same domain internally, it shows me an error "NET::ERR_CERT_COMMON_NAME_INVALID" - The subject is not "nextcloud.domain.com" but "openvpn.domain.com"...

 

Br,

Johannes

 

Edit: Somehow it is now working... MAybe a DNS Timer...

Edited by ebnerjoh
Link to comment
On 6/27/2017 at 7:04 AM, ChaOConnor said:

Good morning!  So I've finally gotten around to setting up ddclient to use my dynamic IP with my already registered Google Domain, per the advice of this thread earlier.  Letsencrypt is now throwing the following error message:


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

Domain: chaoconnor.com
Type: unknownHost
Detail: No valid IP addresses found for chaoconnor.com

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.

My setup is as follows:

Letsencrypt (see picture)

Google DNS (see picture)

DDclient:

#
##
## Google Domains (www.google.com/domains)
##
protocol=googledomains,
login=<removed>,
password=<removed>
www.chaoconnor.com

 

If I type in www.chaoconnor.com it brings me to my router homepage, so doesn't that mean DDclient is working?  Note the Google DNS is updated with my IP.  If I go to chaoconnor.com (without the www), it doesn't work.  

 

I also tried using the @ identifier in Google DNS instead of www, and the error for Letsencrypt is:


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

Domain: www.chaoconnor.com
Type: connection
Detail: DNS problem: NXDOMAIN looking up A for www.chaoconnor.com

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.


I appreciate any help/guidance you can provide, thanks!

LetsEncrypt.jpg

GoogleDNS.png

Sorry for bumping this, but does anyone have any idea what I could be missing?  I messed around with it again this weekend and couldn't get anywhere.  I feel like it's something simple, but it has to do with the dynamic DNS and what LetsEncrypt sees when it pings that domain.  If I use something like DuckDNS it works, and that's what I've been using.  However that isn't my desired end state.

 

I appreciate any thoughts/help anyone has, thank you!

Link to comment
Sorry for bumping this, but does anyone have any idea what I could be missing?  I messed around with it again this weekend and couldn't get anywhere.  I feel like it's something simple, but it has to do with the dynamic DNS and what LetsEncrypt sees when it pings that domain.  If I use something like DuckDNS it works, and that's what I've been using.  However that isn't my desired end state.
 
I appreciate any thoughts/help anyone has, thank you!


It's certainly a dns setting issue. I have not used Google domains before so can't help you there. Perhaps you can search on letsencrypt forums for Google domains help
Link to comment
28 minutes ago, ijuarez said:

I am going to ASSume that you can run multiple instances of this docker, making sure no ports overlap there should be no issues?

 

 

ASSuming you can configure each container to be able to communicate through port 443 from the outside world. Might require some fiddling at the router level. Or switch each container in turn to be on 443 externally when it comes time to obtain or renew certificates. Don't know if you can tell the letsencrypt script to talk back to a different port.

 

After it's running with good certificates I'm assuming you can put them on whatever external port you want.

 

I may be completely wrong though.

Link to comment
2 minutes ago, jonathanm said:

ASSuming you can configure each container to be able to communicate through port 443 from the outside world. Might require some fiddling at the router level. Or switch each container in turn to be on 443 externally when it comes time to obtain or renew certificates. Don't know if you can tell the letsencrypt script to talk back to a different port.

 

After it's running with good certificates I'm assuming you can put them on whatever external port you want.

 

I may be completely wrong though.

 

 

Ahh good point that's why we ask and knowledge is given. 

Link to comment
ASSuming you can configure each container to be able to communicate through port 443 from the outside world. Might require some fiddling at the router level. Or switch each container in turn to be on 443 externally when it comes time to obtain or renew certificates. Don't know if you can tell the letsencrypt script to talk back to a different port.
 
After it's running with good certificates I'm assuming you can put them on whatever external port you want.
 
I may be completely wrong though.


I have a few containers on my server most are test versions.

Only the main one where 443 on the router is forwarded to will auto renew the certs.

For others, when I get the email notice saying the cert is about to expire, I forward port 443 to the expiring one and restart the container. After renewal, I switch the port forward to the main one.
Link to comment
16 hours ago, aptalca said:

 


I have a few containers on my server most are test versions.

Only the main one where 443 on the router is forwarded to will auto renew the certs.

For others, when I get the email notice saying the cert is about to expire, I forward port 443 to the expiring one and restart the container. After renewal, I switch the port forward to the main one.

 

 

that's what i will do then,thanks

Link to comment
On 7/5/2017 at 0:23 PM, ChaOConnor said:

Sorry for bumping this, but does anyone have any idea what I could be missing?  I messed around with it again this weekend and couldn't get anywhere.  I feel like it's something simple, but it has to do with the dynamic DNS and what LetsEncrypt sees when it pings that domain.  If I use something like DuckDNS it works, and that's what I've been using.  However that isn't my desired end state.

 

I appreciate any thoughts/help anyone has, thank you!

 

So I've also tried using google domain with the docker to failure like you and peruse the forums at letsencrypt and finally found one person that said create the A record and put the public ip. In you case 68.XXX.XXX.XXX ip, go to the section labeled custom resource records leave @ A 1H add your ip. then run the docker boom you'll get your cert.

 

Only drawback is if your IP changes you have to update google.

 

I don't understand why google is so hard and duckdns.org works flawlessly but i have a feeling they want to control that too and pay them money.

  • Upvote 1
Link to comment
  So I've also tried using google domain with the docker to failure like you and peruse the forums at letsencrypt and finally found one person that said create the A record and put the public ip. In you case 68.XXX.XXX.XXX ip, go to the section labeled custom resource records leave @ A 1H add your ip. then run the docker boom you'll get your cert.

 

Only drawback is if your IP changes you have to update google.

 

I don't understand why google is so hard and duckdns.org works flawlessly but i have a feeling they want to control that too and pay them money.

 

 

Every dns provider expects you to update your ip with them when it changes, including duckdns. Otherwise, how would they know what your new ip is?

 

Most of them have an api and they provide tools so you can automate that part if you want to.

 

 

 

Link to comment
3 hours ago, aptalca said:

 

Every dns provider expects you to update your ip with them when it changes, including duckdns. Otherwise, how would they know what your new ip is? emoji6.png

 

Most of them have an api and they provide tools so you can automate that part if you want to.

 

 

 

I do have that, pfsense does it for me. I can do a nslookup from outside my home network and it will reply with the correct ip. But when the docket runs it just says no valid ip for my Google domains.  

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.