[Request/Done] Let's Encrypt Container

[jtroberts]

Awesome, my day is complete!

[kamhighway]

@jtroberts, Your post helped me as well.

[kamhighway]

This is a portion of Aptalca's nginx.conf from his post on page 5.

 

server {

listen 443 ssl default_server;


ssl_certificate /config/keys/fullchain.pem;
ssl_certificate_key /config/keys/privkey.pem;
ssl_dhparam /config/nginx/dhparams.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
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 / {
root /config/www;
index index.html index.htm index.php;
        auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;
}

    location /sab {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.X.X:XXXX/sabnzbd;
}

}

 

As I read the nginx reverse proxy guide https://www.nginx.com/resources/admin-guide/reverse-proxy/, when the location is anything other than "/", nginx will add it to the url that is given in the proxy_pass statement.  I think this means that the location /sab in the settings file above is being passed to http://192.168.x.x:xxxx/sabnzbd/sab. If that is the correct url to access sab, then I can see how Aptalca's conf works.

 

My problem is that lsio's nextcloud docker responds on https://192.168.x.x:xxxx.  If I use this URL in a proxy_pass statement for location / it works. But if I use the same URL in a proxy_pass statement for location /nextcloud, it fails.

 

I have attempted to use a rewrite as follows:

 

location /nextcloud {
       rewrite ^/nextcloud(.*) /$1 break;
       proxy_pass https://192.168.x.xxx:xxxx;
}

 

But, this does not work.

 

I'm stumped. Would appreciate some help in understanding how aptalca's conf works.

 

Update:  I think I got this working with LSIO's Nextcloud docker.  The trick was to edit the default site-conf for the nextcloud docker.  Look for the comment "# Path to the root of your installation." The next line will be root /config/www/nextcloud.  Change that to root/config/www/ and restart the nextcloud docker. Now to get to your nextcloud instance you'll have add /nextcloud after the ip address:port you used to use. This is good because this is what makes it possible to make an nginx location such as /nextcould work.

 

Now edit the default nginx site-conf for the letsencrypt docker to add a new location:

 

	location /nextcloud {
       proxy_pass https://192.168.x.xxx:xxxx/nextcloud;
}

 

Now to get to your nextcloud instance you can type domain.com/nextcloud.

 

To get nextcloud to work through the proxy, I also found that I add these lines to nextcloud's config.php:

 

  'trusted_proxies' => ['192.168.x.xxx'],
  'overwritewebroot' => '/nextcloud',
  'overwritehost'     => 'domain.com',

 

Hope this is useful for others.

 

 

[aptalca]

 

 

As I read the nginx reverse proxy guide https://www.nginx.com/resources/admin-guide/reverse-proxy/, when the location is anything other than "/", nginx will add it to the url that is given in the proxy_pass statement.  I think this means that the location /sab in the settings file above is being passed to http://192.168.x.x:xxxx/sabnzbd/sab. If that is the correct url to access sab, then I can see how Aptalca's conf works.

 

 

Actually, anything "inside" the location /sab get passed to the proxy_pass url

 

So www.domain.url/sab/blah gets passed to http://192.168.x.x:xxxx/sabnzbd/blah internally

 

But as I wrote in an earlier message (yesterday I believe) sab sometimes does some force forwarding internally so it might try to force forward you to www.domain.url/sabnzbd which doesn't work. For best practices, I would try and keep the nginx site config's location part and the app's root url prefix the same as "sabnzbd" (I should go back and edit that post to reflect that change)

 

What you did with nextcloud seems right, as you told it to use a root url prefix. Some apps like sab automatically use a root url prefix and some others like couchpotato and sonarr have settings for it (they both call it url base).

[kamhighway]

@aptalca, Thanks for that clarification. I could not see exactly what was being passed to the proxied server, so I had to read the nginx manual -- and still got it wrong.

 

Based on the example you posted on page 5, I thought that all the settings to get the reverse proxy working were in the config files for nginx in the letsencrypt docker.

 

What I was missing was that the proxy pass URL needs to include the webroot of the proxied webserver.

 

This means that any docker that enables its app to be accessed at IP:XXXX/ (such as lsio's nextcloud) needs to be reconfigured so the app can be accessed at IP:XXXX/webroot if you want to access it from behind a reverse proxy.

 

Thank you for your work on the letsencrypt docker. Being able to use it as a reverse proxy server is going to make my life simpler.

[itsdandandan]

@kamhighway hmm I think I'm getting stuck at a similar position

 

This is my config modeled off of aptalca's on page 5

 

server {

listen 443 ssl default_server;
ssl_certificate /config/keys/fullchain.pem;
ssl_certificate_key /config/keys/privkey.pem;
ssl_dhparam /config/nginx/dhparams.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
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 / {
root /config/www;
index index.html index.htm index.php;
        auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;
}

    location /requests {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.1.XX:3000/;
}


}

 

I'm trying to redirect to this docker https://hub.docker.com/r/lsiodev/plexrequests/ which can be accessed on http://192.168.1.XX:3000/ Currently it only shows the webpage title "Plex Requests"

 

This docker also has a URL_BASE environment variable that can be passed to it. Any suggestions? Also happy to use a different plex requests docker if that is easier...

 

Also a separate issue when browsing to my domain from inside my network I get prompted to auth but none of the creds work, works fine from outside my network... hmm

[kamhighway]

@itsdandandan

 

I don't use plex requests so I don't think I can help you. It seems that each application/docker needs to be configured so the app can be accessed through a URL_BASE. Some apps have a variable to set it and some don't. In the case of Nextcloud, there are also variables to set so that nextcloud generated urls will work when being accessed through the reverse proxy. This is a long way to say that each application/docker needs to be looked at individually.

 

However, I think you need to set a URL_Base and then change the proxy pass url to http://192.168.1.xx:3000/URL_Base.  Based on what Aptalca said today, the location should match the URL_Base, so replace location /requests with location /URL_Base. Give that a try.

 

 

[aptalca]

 

 

@kamhighway hmm I think I'm getting stuck at a similar position

 

This is my config modeled off of aptalca's on page 5

 

server {

listen 443 ssl default_server;
ssl_certificate /config/keys/fullchain.pem;
ssl_certificate_key /config/keys/privkey.pem;
ssl_dhparam /config/nginx/dhparams.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
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 / {
root /config/www;
index index.html index.htm index.php;
        auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;
}

    location /requests {
        include /config/nginx/proxy.conf;
        proxy_pass http://192.168.1.XX:3000/;
}


}

 

I'm trying to redirect to this docker https://hub.docker.com/r/lsiodev/plexrequests/ which can be accessed on http://192.168.1.XX:3000/ Currently it only shows the webpage title "Plex Requests"

 

This docker also has a URL_BASE environment variable that can be passed to it. Any suggestions? Also happy to use a different plex requests docker if that is easier...

 

Also a separate issue when browsing to my domain from inside my network I get prompted to auth but none of the creds work, works fine from outside my network... hmm

 

In the plex requests container,  pass the url base variable set to requests

 

In the site config, change the proxy pass line to

proxy_pass http://192.168.1.XX:3000/requests;

[itsdandandan]

Awesome guys working perfectly, had to set the URL_BASE to /requests

 

Thanks for the help

[ken-ji]

for apps that don't have that - consider this snippet:

    location /kibana/ {
        proxy_pass http://192.168.2.5:9000;
        rewrite ^/kibana/(.*) /$1 break;
        access_log off;
    }

 

[lespaul]

I have got reverse proxy to work, but rutorrent page looks strange? it' the same on other as well, but sabnzbd is OK.

 

my settings for rutorrent

 

 location /rutorrent {
                auth_basic "Restricted";
                auth_basic_user_file /config/nginx/.htpasswd;
                proxy_set_header Authorization "Basic zyz1230";
                rewrite ^/rutorrent(/.*)$ $1 break;
                include /config/nginx/proxy.conf;
                proxy_pass http://192.168.0.190:9080/;
                }

 

 

Did you ever solve this? I'm having the same issue.

[peter_sm]

No it's no solved , same issue for transmission.

 

 

Skickat från min iPhone med Tapatalk

[kamhighway]

@lespaul and @ken-ji

 

When I tried this -- rewrite ^/nextcloud(/.*)$ $1 break; -- the problem I had was that the application communicates through the reverse proxy at location / instead of location /nextcloud. 

 

In other words, I could get to the login screen by typing domain.com/nextcloud but then the application would send back urls that did not have the uri /nextcloud so they would get handled by location / instead of location /nextcloud.

 

To make sure the back and forth communication through the reverse proxy is handled by the right nginx location block, the application needs to include the URI /nextcloud in any app-generated URLs.

[ken-ji]

try changing the rewrite rule:

rewrite ^/nextcloud$ /nextcloud/ permanent;
rewrite ^/nextcloud/(.*) /$1 break;

 

this will tell nginx to send /nextcloud => /nextcloud/

then anything after /nextcloud/ => will be proxied to nextcloud

so /nextcloud/images => 192.x.x.x:port/images

[kamhighway]

@ken-ji,

 

I've got nextcloud working a different way which I've described in a previous post.  But I'm curious to know if this approach works for you?

[lespaul]

No it's no solved , same issue for transmission.

 

 

Skickat från min iPhone med Tapatalk

 

Peter,

 

I added a trailing slash at the end of /rutorrent in the config and it seems to be working now. I tested from my phone  disconnected from the wifi and also from my computer connected to a vpn. Hope it fixes your issue as well.

 

location /rutorrent/ {

[peter_sm]

No it's no solved , same issue for transmission.

 

 

Skickat från min iPhone med Tapatalk

 

Peter,

 

I added a trailing slash at the end of /rutorrent in the config and it seems to be working now. I tested from my phone  disconnected from the wifi and also from my computer connected to a vpn. Hope it fixes your issue as well.

 

location /rutorrent/ {

Thanks! that's worked! no I going to try to get nextcloud to work,  anyone have any config files for that ? or how to do it :-)

[peter_sm]

I only add this to get nextcloud working

 

location /nextcloud {
                proxy_pass https://192.168.0.190:446/nextcloud;
                rewrite ^/nextcloud$ /nextcloud/ permanent;
                rewrite ^/nextcloud/(.*) /$1 break;
                }

 

and added these line in nextcloud config.php

 

  1 => '192.168.0.190:446',

 

'trusted_proxies' => ['192.168.0.190'],
  'overwritewebroot' => '/nextcloud',
  'overwritehost'     => 'www.XXX.com',

[ken-ji]

@ken-ji,

 

I've got nextcloud working a different way which I've described in a previous post.  But I'm curious to know if this approach works for you?

 

I'm not working with nextcloud, but with kibana (hence the snippet) and it works since kibana expects to be a top level service without a virtual app dir.

[kamhighway]

@ken-ji, Thanks for letting me know. Its always good to have another way to solve a problem.

[Kewjoe]

I only add this to get nextcloud working

 

location /nextcloud {
                proxy_pass https://192.168.0.190:446/nextcloud;
                rewrite ^/nextcloud$ /nextcloud/ permanent;
                rewrite ^/nextcloud/(.*) /$1 break;
                }

 

and added these line in nextcloud config.php

 

  1 => '192.168.0.190:446',

 

'trusted_proxies' => ['192.168.0.190'],
  'overwritewebroot' => '/nextcloud',
  'overwritehost'     => 'www.XXX.com',

 

peter_sm, can you share your nextcloud config.php? obviously removing your personal info. I tried adding these lines and nextcloud doesn't start. I probably misunderstood where you put it.

[peter_sm]

This i my config.php file

 

 

The issue I have is that I cant reach the website from LAN only outside now. see image.

 

 

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'oc3nh4ucquft',
  'passwordsalt' => 'tuSxRj4T9h5mRkB+eHqU+iZ1j/eV6l',
  'secret' => 'bb+Ad/15J48oAaayi/NJ9vebkxoD3frseuwh+fZXE8HR9JAs',
  'trusted_domains' =>
  array (
    0 => '192.168.0.190:446',
  ),
  'overwrite.cli.url' => 'https://192.168.0.190:446',
  'dbtype' => 'sqlite3',
  'version' => '9.0.53.0',
  'logtimezone' => 'UTC',
  'installed' => true,
  'updater.release.channel' => 'stable',
  'trusted_proxies' =>
  array (
    0 => '192.168.0.190',
  ),
  'overwritewebroot' => '/nextcloud',
  'overwritehost' => 'www.xxxxx.com',
);

 

ngnix config

 

        location /nextcloud/ {
                proxy_pass https://192.168.0.190:446/nextcloud;
                rewrite ^/nextcloud$ /nextcloud/ permanent;
                rewrite ^/nextcloud/(.*) /$1 break;
                }

[kamhighway]

I think you need to add your domain.com as a trusted domain.

 

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'oc3nh4ucquft',
  'passwordsalt' => 'tuSxRj4T9h5mRkB+eHqU+iZ1j/eV6l',
  'secret' => 'bb+Ad/15J48oAaayi/NJ9vebkxoD3frseuwh+fZXE8HR9JAs',
  'trusted_domains' =>
  array (
    0 => '192.168.0.190:446',
    1 => 'www.xxxxx.com',       #<--------Add this line
  ),
  'overwrite.cli.url' => 'https://192.168.0.190:446',
  'dbtype' => 'sqlite3',
  'version' => '9.0.53.0',
  'logtimezone' => 'UTC',
  'installed' => true,
  'updater.release.channel' => 'stable',
  'trusted_proxies' =>
  array (
    0 => '192.168.0.190',
  ),
  'overwritewebroot' => '/nextcloud',
  'overwritehost' => 'www.xxxxx.com',
);

[peter_sm]

I think you need to add your domain.com as a trusted domain.

 

 

 

Added the line, but didn't help.

 

//Peter

[kamhighway]

I may have misread your message.  Are you saying that you cannot access nextcloud at www.xxxx.com/nextcloud, or that you can't access it at 192.168.9.190:446?

 

I used to get to a login screen that looked like the png you posted. The problem I had was the proxypass codeblock in letsencrypt's nginx config file was not passing through to the login page but to a page inside of the nextcloud. That's why the css is missing.

 

I tried the approach you used with the rewrite statements but could not get it to work.  Ken-ji, however, says the rewriting statements do work for his app.

 

I got nextcloud to work by editing the nginx config file in the Nextcloud docker to set the web root one directory above where it was originally.  Then I didn't need the rewrite rules.