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


Recommended Posts

11 hours ago, mathgoy said:

Hi all,

 

Like many others I am struggling with Letsencrypt and NextCloud.

I spent a lot of time following numerous tutorials but none of them could make it work.

 

What is installed:

  • duckdns
  • nextcloud
  • letsencrypt

 

What does work:

  • Local access to nextcloud through an unsecured connection by using my unraid local address: 192.168.1.206:442 (I have to add an exception in my browser so it will connect)
  • Remote access to nextcloud through an unsecured connection by using my duckdns address XXXXX.duckdns.org:442 (I have to add an exception in my browser so it will connect)
  • Looks like duckdns works as well as port forwarding on port 442
  • Letsencrypt works I guess, here is the log:
    
    Processing /etc/letsencrypt/renewal/XXXX.duckdns.org.conf
    -------------------------------------------------------------------------------
    Cert not yet due for renewal
    
    -------------------------------------------------------------------------------
    
    The following certs are not due for renewal yet:
    /etc/letsencrypt/live/XXXX.duckdns.org/fullchain.pem expires on 2018-08-13 (skipped)
    No renewals were attempted.
    No hooks were run.
    -------------------------------------------------------------------------------
    [cont-init.d] 50-config: exited 0.
    [cont-init.d] done.
    [services.d] starting services
    [services.d] done.
    Server ready

     

What does not work:

  • Local secured access to next cloud
  • Remote secure acess to next cloud

What is my configuration:

  • letsencrypt\nginx\site-confs\default

upstream backend {
    server 192.168.1.206:19999;
    keepalive 64;
}
 
server {
    listen 443 ssl;
    listen 80 default_server;
    root /config/www;
    index index.html index.htm index.php;
 
    server_name XXXX.duckdns.org;
 
    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;
 
    location = / {
        return 301 /htpc;
    }
 
    location /sonarr {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.1.206:8989/sonarr;
    }
   
    location /radarr {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.1.206:7878/radarr;
    }
 
    location /htpc {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.1.206:8085/htpc;
    }
 
   
    location /downloads {
        include /config/nginx/proxy.conf;
        proxy_pass  http://192.168.1.206:8112/;
        proxy_set_header  X-Deluge-Base "/downloads/";
    }
   
    #PLEX
    location /web {
        # serve the CSS code
        proxy_pass http://192.168.1.206:32400;
    }
 
    # Main /plex rewrite
    location /plex {
        # proxy request to plex server
        proxy_pass http://192.168.1.206:32400/web;
    }
 
    location /nextcloud {
        include /config/nginx/proxy.conf;
        proxy_pass https://192.168.1.206:442/nextcloud;
    }
   
    location ~ /netdata/(?<ndpath>.*) {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://backend/$ndpath$is_args$args;
        proxy_http_version 1.1;
        proxy_pass_request_headers on;
        proxy_set_header Connection "keep-alive";
        proxy_store off;
    }
}
  • nextcloud config.php

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'oc4xjllsleky',
  'passwordsalt' => 'AePwbt7LYPhHr9QW/xhQEHG3Upk+XC',
  'secret' => 'eg8adPotUPdkAphDtJKC0abNfglncPMdGPYlx5ujkwWRhZBf',
  'trusted_domains' => 
  array (
    0 => '192.168.1.206:442',
	1 => 'XXXXX.duckdns.org',
  ),
  'overwrite.cli.url' => 'https://192.168.1.206:442',
  'dbtype' => 'mysql',
  'version' => '13.0.1.1',
  'dbname' => 'nextcloud',
  'dbhost' => '192.168.1.206:3305',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'xXxXxXxX',
  'dbpassword' => 'xXxXxX',
  'installed' => true,
);

And attached, the docker configuration of both Letsencrypt and Nextcloud

 

There must be something stupid I did but I can't put my finger on it. Thanks a lot for your help!

lestencrypt.PNG

nextcloud.PNG

 

Check out the folder /config/nginx/proxy-confs and read the readme there. There is a built in nextcloud config via subdomain

Link to comment
3 hours ago, Jessie said:

How can I reverse proxy my Small business server through the letsencrypt docker without adding the letsencrypt certificates.

ie   I want to be able to connect to https://remote.mydomain.com.au 

I want this to pass straight through the letsencrypt dockers reverse proxy to the sbs server.

The SBS server will provide self signed certs rather than letsencrypt certs.

 

The config file is shown below.

I have hashed out what I think would be needed to pass straight in and out again.

 

It doesn't work of course, which is why I am posting here.

 

server {  
    listen 443 ssl;
    server_name remote.mydomain.com.au;

 #   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;

#    proxy_request_buffering off;
#    proxy_buffering off;

        
    location / {
        proxy_pass https://192.168.10.27:443/;
        proxy_max_temp_file_size 2048m;
        include /config/nginx/proxy.conf;
    }
}

 

If you don't need letsencrypt, you can use the plain nginx container. 

 

But if you want the sbs server to provide certs, I don't believe it will be possible to reverse proxy that way. As far as I know, the first handshake (reverse proxy in this case) needs to establish the ssl protocol

 

EDIT:

On second read, I see that sbs will provide self signed certs. Those aren't really desirable. You're better off using letsencrypt certs between client and letsencrypt, and the sbs self signed certs between letsencrypt and sbs. 

 

I think you asked questions about your setup and issues with sbs servers before, honestly I never really understood your setup or what you were trying to achieve with sbs. But then again, I don't know much about ms servers

Edited by aptalca
Link to comment
On 5/15/2018 at 7:58 PM, noja said:

You know, I had a hell of a time trying to make it work myself at first.  Eventually I decided give it a whirl using a subdomain (ie nextcloud.domain.com as opposed to domain.com/nextcloud).  Turns out the subdomain was easier to implement and for me - easier to remember my url address.  As an added benefit, its apparently also more secure!

 

So, just to make it better for yourself, its worth it to review your installation from the ground up.  Just go back one more time and follow Linuxserver's excellent step-by-step process on this very topic: https://blog.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/

 

As I don't use DuckDNS I had to make sure that subdomains were possible, and apparently they are! So try this for your subdomain setup:

 

Good luck!

 

 

 

It works now. There was 2 mistakes I made.

 

Mistake #1: my ISP modem had a built-in functionnality for remote administration that was using the port #443. I disabled that and the port forwarding then worked

Mistake #2 : it's not really a mistake but I dropped duckdns and used my dyndns subdomain. Then, by following the tutorial (again) I made it work. I can now access my next cloud through https://nextcloud.MYDOMAIN.dyndns.org.

 

Thanks for the valuable help!

Edited by mathgoy
Link to comment
On ‎5‎/‎16‎/‎2018 at 12:52 PM, aptalca said:

 

If you don't need letsencrypt, you can use the plain nginx container. 

 

But if you want the sbs server to provide certs, I don't believe it will be possible to reverse proxy that way. As far as I know, the first handshake (reverse proxy in this case) needs to establish the ssl protocol

 

EDIT:

On second read, I see that sbs will provide self signed certs. Those aren't really desirable. You're better off using letsencrypt certs between client and letsencrypt, and the sbs self signed certs between letsencrypt and sbs. 

 

I think you asked questions about your setup and issues with sbs servers before, honestly I never really understood your setup or what you were trying to achieve with sbs. But then again, I don't know much about ms servers

I'd prefer not to use self signed certificates but they work if SBS is the only system being fed through port 443.  The problem is I also run nextcloud and letsencrypt docker which provides the certificates for nextcloud.  Because letsencrypt must have 443 and SBS also must have 443, they need to go through the reverse proxy.  Letsencrypt used to provide certificates for sbs but that fell apart when they banned TLS type certificates.

 

The main purpose of SBS is to provide an exchange mail server.  File server functions can easily be handled by Unraid. SBS is also a domain controller presently.

In the future, I will look at Samba as a domain controller.

I plan to retire SBS in 2020 when they drop support.  Still looking for a viable replacement for exchange.

 

I am now running a pfsense router as a vm on unraid. If I can't get SBS to go using current methods, I am looking at the possibility of generating letsencrypt certs and reverse proxying through pfsense.

 

Spare time is my enemy here.  I also can't afford much downtime for my system either.

Link to comment

Setting up reverse proxy seemed easy after following this guide, radarr and sonarr work fine when accessed through my duckdns domain. However anything else I try to set up fails miserably, I just get a 404. At the moment I am focussing on getting Transmission and Jackett to work but I feel I am at a dead end.

 

Opening subdomain.duckdns.org:9117 works for me, but subdomain.duckdns.org/jackett does not

 

With transmission subdomain.duckdns.org:9091 does not work at all (ERR_CONNECTION_REFUSED)

 

Anybody have any pointers?

Edited by Jeroen
Link to comment

I have been getting a certificate error from the letsencrypt docker.

2018-05-19_14-00-53.png.48bf121c1ef92da144f150133d432154.png

 

The cert appears to be self-signed, but shows as verified by linuxserver.io. I have purchased my own domain name, and it is running through cloudflare (caching off) so that I can use DNS domain validation with letsencrypt because my ISP (COX) blocks port 80 so I can't do http validation. Here's my letsencrypt output:

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


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/New_York
URL=mydomain.com
SUBDOMAINS=www,ftp,nc,ari43dou,minio-ari,minio-marty,testing
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
DHLEVEL=2048
VALIDATION=dns
DNSPLUGIN=cloudflare
[email protected]
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.mydomain.com -d ftp.mydomain.com -d nc.mydomain.com -d ari43dou.mydomain.com -d minio-ari.mydomain.com -d minio-marty.mydomain.com -d testing.mydomain.com
E-mail address entered: [email protected]
dns validation via cloudflare plugin is selected
Certificate exists; parameters unchanged; attempting renewal
<------------------------------------------------->

<------------------------------------------------->
cronjob running on Sat May 19 14:04:49 EDT 2018
Running certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/mydomain.com.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal

-------------------------------------------------------------------------------

The following certs are not due for renewal yet:
/etc/letsencrypt/live/mydomain.com/fullchain.pem expires on 2018-08-17 (skipped)
No renewals were attempted.
No hooks were run.
-------------------------------------------------------------------------------
[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Server ready

How can I resolve this so the certs are good?

Thanks,
Ari

 

 

Link to comment

I'm hoping someone here can help me out. I'm really starting to run out of any ideas to figure this out...

 

Lets get this out of the way first... Here are screenshots of my DuckDNS Docker Settings, LetsEncrypt Docker settings, and Router Port Forwarding settings. Additionally, here is what my default file in the site-conf directory looks like.

 

I can't seem to get this working at all. When I attempt to connect to the site, I get an error that says that the page cannot be reached. It doesn't appear that NGINX is even running though. I have tried everything I can think of at this point and I'm just at a total loss...

 

When I run "ps aux | grep nginx", here's what I get:

  333 root       0:00 grep nginx

And the Log doesn't seem to help me much either, other than to say there may be some sort of firewall issue, but I don't see anything wrong as of yet:

[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=duckdns.org
SUBDOMAINS=XXXXXXXXXX
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
DHLEVEL=2048
VALIDATION=http
DNSPLUGIN=
[email protected]
STAGING=

Backwards compatibility check. . .
No compatibility action needed
2048 bit DH parameters present
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are: -d XXXXXXXXXX.duckdns.org
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
Performing the following challenges:
http-01 challenge for XXXXXXXXXX.duckdns.org
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. XXXXXXXXXX.duckdns.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://XXXXXXXXXX.duckdns.org/.well-known/acme-challenge/f1rdD3LNSvZDXNlOZy15GcVFK4LOQqvIZ_KyXSXpJFw: 
Timeout during connect (likely firewall problem)

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

Domain: XXXXXXXXXX.duckdns.org
Type: connection
Detail: Fetching
http://XXXXXXXXXX.duckdns.org/.well-known/acme-challenge/f1rdD3LNSvZDXNlOZy15GcVFK4LOQqvIZ_KyXSXpJFw:
Timeout during connect (likely firewall problem)

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

Please tell me there's someone that can help... I don't have much hair left to pull.

 

Thanks in advance.

Link to comment
20 hours ago, Jeroen said:

Setting up reverse proxy seemed easy after following this guide, radarr and sonarr work fine when accessed through my duckdns domain. However anything else I try to set up fails miserably, I just get a 404. At the moment I am focussing on getting Transmission and Jackett to work but I feel I am at a dead end.

 

Opening subdomain.duckdns.org:9117 works for me, but subdomain.duckdns.org/jackett does not

 

With transmission subdomain.duckdns.org:9091 does not work at all (ERR_CONNECTION_REFUSED)

 

Anybody have any pointers?

How about you post your config? We have no idea what you did

Link to comment
11 hours ago, adoucette said:

I have been getting a certificate error from the letsencrypt docker.

2018-05-19_14-00-53.png.48bf121c1ef92da144f150133d432154.png

 

The cert appears to be self-signed, but shows as verified by linuxserver.io. I have purchased my own domain name, and it is running through cloudflare (caching off) so that I can use DNS domain validation with letsencrypt because my ISP (COX) blocks port 80 so I can't do http validation. Here's my letsencrypt output:


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


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/New_York
URL=mydomain.com
SUBDOMAINS=www,ftp,nc,ari43dou,minio-ari,minio-marty,testing
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
DHLEVEL=2048
VALIDATION=dns
DNSPLUGIN=cloudflare
[email protected]
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.mydomain.com -d ftp.mydomain.com -d nc.mydomain.com -d ari43dou.mydomain.com -d minio-ari.mydomain.com -d minio-marty.mydomain.com -d testing.mydomain.com
E-mail address entered: [email protected]
dns validation via cloudflare plugin is selected
Certificate exists; parameters unchanged; attempting renewal
<------------------------------------------------->

<------------------------------------------------->
cronjob running on Sat May 19 14:04:49 EDT 2018
Running certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/mydomain.com.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal

-------------------------------------------------------------------------------

The following certs are not due for renewal yet:
/etc/letsencrypt/live/mydomain.com/fullchain.pem expires on 2018-08-17 (skipped)
No renewals were attempted.
No hooks were run.
-------------------------------------------------------------------------------
[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Server ready

How can I resolve this so the certs are good?

Thanks,
Ari

 

 

 

I don't see where it says self signed, but verified by linuxserver is weird. Did you perhaps edit your site config and change the cert location to point to the wrong cert? There is a self signed cert in there which is created by the nginx baseimage

Link to comment
9 hours ago, ucrbuffalo said:

I'm hoping someone here can help me out. I'm really starting to run out of any ideas to figure this out...

 

Lets get this out of the way first... Here are screenshots of my DuckDNS Docker Settings, LetsEncrypt Docker settings, and Router Port Forwarding settings. Additionally, here is what my default file in the site-conf directory looks like.

 

I can't seem to get this working at all. When I attempt to connect to the site, I get an error that says that the page cannot be reached. It doesn't appear that NGINX is even running though. I have tried everything I can think of at this point and I'm just at a total loss...

 

When I run "ps aux | grep nginx", here's what I get:


  333 root       0:00 grep nginx

And the Log doesn't seem to help me much either, other than to say there may be some sort of firewall issue, but I don't see anything wrong as of yet:


[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=duckdns.org
SUBDOMAINS=XXXXXXXXXX
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
DHLEVEL=2048
VALIDATION=http
DNSPLUGIN=
[email protected]
STAGING=

Backwards compatibility check. . .
No compatibility action needed
2048 bit DH parameters present
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are: -d XXXXXXXXXX.duckdns.org
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
Performing the following challenges:
http-01 challenge for XXXXXXXXXX.duckdns.org
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. XXXXXXXXXX.duckdns.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://XXXXXXXXXX.duckdns.org/.well-known/acme-challenge/f1rdD3LNSvZDXNlOZy15GcVFK4LOQqvIZ_KyXSXpJFw: 
Timeout during connect (likely firewall problem)

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

Domain: XXXXXXXXXX.duckdns.org
Type: connection
Detail: Fetching
http://XXXXXXXXXX.duckdns.org/.well-known/acme-challenge/f1rdD3LNSvZDXNlOZy15GcVFK4LOQqvIZ_KyXSXpJFw:
Timeout during connect (likely firewall problem)

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

Please tell me there's someone that can help... I don't have much hair left to pull.

 

Thanks in advance.

 

Did you log into duckdns to verify that the ip address they have is correct? 

Link to comment
7 hours ago, aptalca said:

I don't see where it says self signed, but verified by linuxserver is weird. Did you perhaps edit your site config and change the cert location to point to the wrong cert? There is a self signed cert in there which is created by the nginx baseimage

 

The instructions for setting this up at

https://blog.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/

have the following:

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

But the file in the letsencrypt docker distro at /ngnix/site-confs/default has this in it:

# all ssl related config moved to ssl.conf
include /config/nginx/ssl.conf;

So I went ahead and used that include statement in each of the ngnix reverse proxy server blocks.

Then in the above-named ssl.conf file I have:

# session settings
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# Diffie-Hellman parameter for DHE cipher suites
ssl_dhparam /config/nginx/dhparams.pem;

# ssl certs
#ssl_certificate /config/keys/letsencrypt/fullchain.pem;
#ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
# the letsencrypt docker has pointers that go to the above files, which should work, but the hardcoded path is below
ssl_certificate /config/etc/letsencrypt/live/mydomain.com/fullchain.pem;
ssl_certificate_key /config/etc/letsencrypt/live/mydomain.com/privkey.pem;

# protocols
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
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: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-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

# HSTS, remove # from the line below to enable HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;

Is this pointing to the correct cert? Or to the wrong cert (such as in the ngnix base image)?

Or is there some other problem I'm not seeing?

Thank you for the great help @aptalca

 

FWIW, I actually also get that same error at blog.linuxserver.io (but not at the base linuxserver.io page).

2018-05-20_9-31-53.png.248ff3460fff2359139518faa9740f5b.png

Link to comment
On 5/20/2018 at 9:46 AM, adoucette said:

 

The instructions for setting this up at

https://blog.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/

have the following:


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

But the file in the letsencrypt docker distro at /ngnix/site-confs/default has this in it:


# all ssl related config moved to ssl.conf
include /config/nginx/ssl.conf;

So I went ahead and used that include statement in each of the ngnix reverse proxy server blocks.

Then in the above-named ssl.conf file I have:


# session settings
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# Diffie-Hellman parameter for DHE cipher suites
ssl_dhparam /config/nginx/dhparams.pem;

# ssl certs
#ssl_certificate /config/keys/letsencrypt/fullchain.pem;
#ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
# the letsencrypt docker has pointers that go to the above files, which should work, but the hardcoded path is below
ssl_certificate /config/etc/letsencrypt/live/mydomain.com/fullchain.pem;
ssl_certificate_key /config/etc/letsencrypt/live/mydomain.com/privkey.pem;

# protocols
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
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: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-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

# HSTS, remove # from the line below to enable HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;

Is this pointing to the correct cert? Or to the wrong cert (such as in the ngnix base image)?

Or is there some other problem I'm not seeing?

Thank you for the great help @aptalca

 

FWIW, I actually also get that same error at blog.linuxserver.io (but not at the base linuxserver.io page).

2018-05-20_9-31-53.png.248ff3460fff2359139518faa9740f5b.png

 

I'm not sure what error you are referring to. The two screenshots you posted do not contain a shared error amongst them

Link to comment

I have real struggles to get nginx to redirect nextcloud.domain.com to https://nextcloud.domain.com.

I have tried this here LINK to digitalocean

And I have tried this here LINK to Serverfault.com

Both with no success... Also tried alot of others without success...

 

Please help me out, how should I configure a proper http to https redirect?

I want to redirect all my subdomains.domain.com to https. It's much easier when I tell friends those pages in short instead of saying "ehm, you also need to type https:// before the domain". 

 

My config now is below in an own nextcloud file in site-conf:

upstream php-handler {
    server 127.0.0.1:9000;
    #server unix:/var/run/php5-fpm.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name nextcloud.domain.com;
    # enforce https
    return 301 https://$server_name$request_uri;
}

server {  
    listen 443 ssl http2;
    server_name nextcloud.domain.com;

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

    include /config/nginx/ssl.conf;

    client_max_body_size 25G;

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

 

Edited by truetype
Link to comment
4 minutes ago, CHBMB said:

server {
        listen 80;
        server_name nextcloud.server.com;
        return 301 https://nextcloud.server.com$request_uri;
}

 

 

Thanks for reply, so the complete nextcloud.conf file should look like this? Because this does not redirect it automatically... :/

server {
	listen 80;
	server_name nextcloud.mydomain.com;
	return 301 https://nextcloud.mydomain.com$request_uri;
}

server {  
    listen 443 ssl http2;
    server_name nextcloud.mydomain.com;

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

    include /config/nginx/ssl.conf;

    client_max_body_size 25G;

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

 

Link to comment
5 minutes ago, CHBMB said:

Sure your ports are all forwarded properly and working?  Also worth checking your nextcloud config.php file.

 

I am using pfsense and yes they are since I can reach my nextcloud from anywhere if I type https:// manually. and this docker is able to renew the certs using port 80, but now I have it enabled all the time. See attached files please. Where can I find the nextcloud config.php file? (Could really use a spoiler function to hide this wall of images :P )

firewall rules.PNG

letsencrypt docker settings.PNG

NAT rules.PNG

Edited by truetype
Link to comment
6 minutes ago, CHBMB said:

Thanks, yeah I've followed that once but I cannot see anything that should do any difference, please see my config.php below (sensitive data censored)

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'XXXXXXXXXXXXXX',
  'passwordsalt' => 'XXXXXXXXXXXXXXXXXX',
  'secret' => 'XXXXXXXXXXXXXXXXXX',
  'trusted_domains' => 
  array (
    0 => '192.168.1.8:444',
    1 => 'nextcloud.mydomain.com',
  ),
  'overwrite.cli.url' => 'https://nextcloud.mydomain.com',
  'overwritehost' => 'nextcloud.mydomain.com',
  'overwriteprotocol' => 'https',
  'dbtype' => 'mysql',
  'version' => '13.0.1.1',
  'dbname' => 'nextcloud',
  'dbhost' => '192.168.1.8:3305',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'XXXXXX',
  'dbpassword' => 'XXXXXX',
  'installed' => true,
  'maintenance' => false,
  'loglevel' => 2,
  'theme' => '',
);

I can send the domain to you in PM and you can see for yourself that it doesn't redirect properly if you like?

Edited by truetype
Link to comment
2 minutes ago, CHBMB said:

I think it looks like an issue with pfsense rather than Nextcloud.  Does the 80 => 443 redirection work on your main domain server.com?

 

In the default.conf below it works yes. 

server {
	listen 80;
	server_name _;
	return 301 https://$server_name$request_uri;
}

 

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.