March 18, 20197 yr 2 hours ago, munit85 said: This was my problem as well. I don't know why, but once the changes propagated everything worked. thanks. The way you set up your a record and cnames is correct. You just need to make sure that the a record remains up to date. You can use a docker image like ddclient to update it, or some routers can also do it. If you're doing dns validation, look into getting a wildcard cert and then you only need to create one cname for "*" without the quotes and you'll be good. Between the a record and that wildcard cname, your domain and all subdomains will be covered.
March 18, 20197 yr ok, being dumb here, have searched and tried configs for over 1 hr now... does anyone have a working bitwarden config for subdomain w/docker on a seperate proxeynet my others work just fine, but this one is making me pull out what hair i have left help pls Myk
March 18, 20197 yr ok, being dumb here, have searched and tried configs for over 1 hr now... does anyone have a working bitwarden config for subdomain w/docker on a seperate proxeynet my others work just fine, but this one is making me pull out what hair i have left help pls MykThere's a blog post on our site where I posted s working config.Sent from my Mi A1 using Tapatalk
March 18, 20197 yr 6 hours ago, CHBMB said: There's a blog post on our site where I posted s working config. Sent from my Mi A1 using Tapatalk this is what I am trying to use already from the blog post, but am getting bad gateway # make sure that your dns has a cname set for bitwarden server { listen 80; server_name bw.*; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name bitwarden.*; include /config/nginx/ssl.conf; set $upstream_bitwarden bitwarden; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; location / { proxy_pass http://$upstream_bitwarden:8343; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /notifications/hub { proxy_pass http://$upstream_bitwarden:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_pass http://$upstream_bitwarden:8343; } }
March 18, 20197 yr 1 hour ago, MyKroFt said: this is what I am trying to use already from the blog post, but am getting bad gateway # make sure that your dns has a cname set for bitwarden server { listen 80; server_name bw.*; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name bitwarden.*; include /config/nginx/ssl.conf; set $upstream_bitwarden bitwarden; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; location / { proxy_pass http://$upstream_bitwarden:8343; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /notifications/hub { proxy_pass http://$upstream_bitwarden:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_pass http://$upstream_bitwarden:8343; } } Your server names aren't matching for 80 and 443, bw vs bitwarden
March 18, 20197 yr 17 hours ago, aptalca said: The way you set up your a record and cnames is correct. You just need to make sure that the a record remains up to date. You can use a docker image like ddclient to update it, or some routers can also do it. If you're doing dns validation, look into getting a wildcard cert and then you only need to create one cname for "*" without the quotes and you'll be good. Between the a record and that wildcard cname, your domain and all subdomains will be covered. excellent. I set my subdomains to "wildcard" in the container and set cloudflare cname to * and it seems to be working. Thanks a lot.
March 19, 20197 yr Please please ..... - letsencrypt running on static ip on my lan 192.168.13.11 . - all settings are default - I put my dynamic DNS name in the domain name field. - router port forwarded 9999 to 80 at 192.168.13.11 - confirmed dynamic dns service forwards to my IP because I have other ports forwarded no problem. But want to replace all my port forwarding with letsencrypt - sonarr, for instance running on 192.168.13.45:8989 - I have set base URL in sonarr to /sonarr and restarted - I have not touched proxy.conf on one machine - win10/chrome returns a 404 in top left corner of the screen on another machine - win10/chrome returns "site cannot be reached" I'm so confused. My nginx.conf file looks like this but of course it's wrong... I have another 8 dockers I want to set up the same - some don't have a base URL setting such as deluge - is it possible to help with that as well? server { server_name _; location ^~ /sonarr { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf #auth_request /auth; #error_page 401 =200 /login; #include /config/nginx/proxy.conf; #resolver 192.168.13.45 valid=30s; #set $upstream_sonarr sonarr; proxy_pass http://192.168.13.45:8989; } location ^~ /sonarr/api { #include /config/nginx/proxy.conf; #resolver 192.168.13.45 valid=30s; #set $upstream_sonarr sonarr; proxy_pass http://192.168.13.45:8989; } }
March 19, 20197 yr 52 minutes ago, tiwing said: Please please ..... - letsencrypt running on static ip on my lan 192.168.13.11 . - all settings are default - I put my dynamic DNS name in the domain name field. - router port forwarded 9999 to 80 at 192.168.13.11 - confirmed dynamic dns service forwards to my IP because I have other ports forwarded no problem. But want to replace all my port forwarding with letsencrypt - sonarr, for instance running on 192.168.13.45:8989 - I have set base URL in sonarr to /sonarr and restarted - I have not touched proxy.conf on one machine - win10/chrome returns a 404 in top left corner of the screen on another machine - win10/chrome returns "site cannot be reached" I'm so confused. My nginx.conf file looks like this but of course it's wrong... I have another 8 dockers I want to set up the same - some don't have a base URL setting such as deluge - is it possible to help with that as well? server { server_name _; location ^~ /sonarr { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf #auth_request /auth; #error_page 401 =200 /login; #include /config/nginx/proxy.conf; #resolver 192.168.13.45 valid=30s; #set $upstream_sonarr sonarr; proxy_pass http://192.168.13.45:8989; } location ^~ /sonarr/api { #include /config/nginx/proxy.conf; #resolver 192.168.13.45 valid=30s; #set $upstream_sonarr sonarr; proxy_pass http://192.168.13.45:8989; } } Start from the beginning. Forget about the reverse proxy. Forward port 80 on your router to port 80. Check the docker log, make sure cert is retrieved. Then check the landing page Edited March 19, 20197 yr by aptalca
March 19, 20197 yr Am really trying here :( /banging head on desk changed the offending line to: server_name bitwarden.*; and now I am getting timeouts :( current conf file # make sure that your dns has a cname set for bitwarden server { listen 80; server_name bitwarden.*; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name bitwarden.*; include /config/nginx/ssl.conf; set $upstream_bitwarden bitwarden; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; location / { proxy_pass http://$upstream_bitwarden:8343; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /notifications/hub { proxy_pass http://$upstream_bitwarden:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_pass http://$upstream_bitwarden:8343; } }
March 19, 20197 yr 2 hours ago, MyKroFt said: Am really trying here /banging head on desk changed the offending line to: server_name bitwarden.*; and now I am getting timeouts current conf file # make sure that your dns has a cname set for bitwarden server { listen 80; server_name bitwarden.*; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name bitwarden.*; include /config/nginx/ssl.conf; set $upstream_bitwarden bitwarden; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; location / { proxy_pass http://$upstream_bitwarden:8343; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /notifications/hub { proxy_pass http://$upstream_bitwarden:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_pass http://$upstream_bitwarden:8343; } } Looks like you are running letsencrypt on a custom bridge from the config you posted. Then you need to change the port from 8343 to 80 as letsencrypt talks to bitwarden internally using the the custom docker bridge The second thing I'm not sure about, as nginx is black arts for me. I think you need to set the include and resolver line in each location. I'm sure aptalca or any other nginx guru will correct me if I'm wrong. Here is my working bitwarden proxy conf. server { listen 80; server_name bitwarden.*; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name bitwarden.*; include /config/nginx/ssl.conf; client_max_body_size 128M; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_bitwarden bitwarden; proxy_pass http://$upstream_bitwarden:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /notifications/hub { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_bitwarden bitwarden; proxy_pass http://$upstream_bitwarden:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_bitwarden bitwarden; proxy_pass http://$upstream_bitwarden:80; } } Edited March 19, 20197 yr by saarg Adding proxy conf
March 19, 20197 yr # make sure that your dns has a cname set for sonarr and that your sonarr container is not using a base url server { listen 80; server_name bw.*; return 301 https://$server_name$request_uri; } server { listen 443 ssl; server_name bw.*; # add_header X-Content-Type-Options nosniff; # add_header X-XSS-Protection "1; mode=block"; # add_header Referrer-Policy same-origin; 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_bitwarden bitwarden; proxy_pass http://$upstream_bitwarden:80; proxy_set_header Host $host; # proxy_ssl_server_name on; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # proxy_headers_hash_bucket_size 512; } # location /notifications/hub { # proxy_pass http://10.10.20.50:3012; # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection "upgrade"; # } # location /notifications/hub/negotiate { # proxy_pass http://10.10.20.50:8343; # } } Can someone please help. I cannot get pass the loading page from my web browser using reverse proxy. Logging in via webUI and connecting with my bitwarden on my phone works correctly. I notice a error in log file whenever I try access my bw subdomain Edited March 19, 20197 yr by bulletjie
March 19, 20197 yr 16 minutes ago, CHBMB said: @bulletjie Did you look at the post immediately above yours?! Yes I did, and since my post I enabled the additional lines and included the include and resolver lines as per the previous post but no luck. Bitwarden seems to work as when sync from my phone and using the webUI but I cannot get past the spinning wheel when trying to log in using the domain name. Could it be a firewall issue? I use pfsense btw.
March 20, 20197 yr 21 hours ago, aptalca said: Start from the beginning. Forget about the reverse proxy. Forward port 80 on your router to port 80. Check the docker log, make sure cert is retrieved. Then check the landing page removed the docker, deleted appdata, and repulled. there are no logs..!! (in the /log folder). port 80 is forwarded to the right IP:80... "This site can’t be reached". There has to be something so basic that I'm missing.
March 20, 20197 yr 4 hours ago, tiwing said: removed the docker, deleted appdata, and repulled. there are no logs..!! (in the /log folder). port 80 is forwarded to the right IP:80... "This site can’t be reached". There has to be something so basic that I'm missing. The log from the docker page, the sheet icon to the right of the container.
March 20, 20197 yr Due to change of ISP, I had to change my static IP in Cloudflare DNS records. As soon as I did that, my collabora and nextcloud stopped working together. I am receiving errors in NC and documents don't open. I checked NC/Collabora forums and found that this error is related to the invalid certificates. I feel that it is related to the letsencrypt certificates as issued for the old IP. My question is, is there a way to force renewing certificates? Thanks
March 20, 20197 yr 2 minutes ago, sse450 said: Due to change of ISP, I had to change my static IP in Cloudflare DNS records. As soon as I did that, my collabora and nextcloud stopped working together. I am receiving errors in NC and documents don't open. I checked NC/Collabora forums and found that this error is related to the invalid certificates. I feel that it is related to the letsencrypt certificates as issued for the old IP. My question is, is there a way to force renewing certificates? Thanks You shouldn't need to if it's only your IP address that's changed. To elaborate, your certificate is issued based on your domain name. IP address doesn't come into it. For instance, I have a dynamic IP address, I don't need to get new certificates every time my IP address changes. Have you got cloudflare caching switched on? If so, turn it off. Without a bit more info about error messages around certs it's difficult to help, but I think you're barking up the wrong tree. Edited March 20, 20197 yr by CHBMB
March 21, 20197 yr 20 hours ago, CHBMB said: Without a bit more info about error messages around certs it's difficult to help, but I think you're barking up the wrong tree. I don't know where the correct tree is Hence, asking for help. Today, I did a very useful test. Currently, both ISPs, the old and the new, have connection at the same location. I reversed back to the old ISP and changed the IP number to that of old ISP at Cloudflare DNS settings. Collabora is again started working nicely. So, it looks it is related to the new ISP connection. If it is nothing to do with letsencrypt certs, then what could it be? Router (pfSense) is the same with forwarded ports 80 and 443 to 81 and 443, respectively. Thanks for your support. More Info on my setup: 1. I use your collabora and linuxserver's nextcloud and letsencrypt dockers. 2. Nextcloud and collabora are setup as subdomains. Setup procedure as per your guide. 3. I use wildcard with Cloudflare plugin in Letsencrypt settings. 4. NC: 15.0.5, Collabora: 4.0.2, Letsencrypt: Latest LS docker, Collabora Plugin NC: 3.2.4 4. The error in NC log is as below: Error PHP Undefined offset: 0 at /config/www/nextcloud/lib/private/AppFramework/Http.php#150 2019-03-21T12:20:17+0300 Error PHP Cannot declare class GuzzleHttp\Handler\CurlFactory, because the name is already in use at /config/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php#15 2019-03-21T12:20:17+0300 Error richdocuments GuzzleHttp\Exception\ConnectException: cURL error 28: Connection timed out after 5001 milliseconds (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) 2019-03-21T12:20:17+0300 Someone had solved this problem by stating "Solved! it was an expired certificate for the loolwsd server." (https://github.com/nextcloud/server/issues/11278). That's why I wanted to force renew the certs. Edited March 21, 20197 yr by sse450 Added info on my setup.
March 21, 20197 yr Use your old ISP and go to whatismyip.com and post the results here, then do the same but using your new ISP.Sent from my Mi A1 using Tapatalk
March 21, 20197 yr 3 hours ago, CHBMB said: Use your old ISP and go to whatismyip.com and post the results here, then do the same but using your new ISP. Old ISP: Your Public IPv4 is: 176.88.224.xxx Your IPv6 is: Not Detected Your Local IP is: 10.10.30.30 New ISP: Your Public IPv4 is: 78.188.71.yyy Your IPv6 is: Not Detected Your Local IP is: 10.10.30.30 Note: If I use the old ISP but without revising the IP in Cloudflare settings, I get exactly the same errors in NC. Note2: Related NC docker nginx log entry: 2019/03/21 14:49:35 [error] 314#314: *15995 upstream sent invalid status "0" while reading response header from upstream, client: 172.17.0.1, server: _, request: "GET /index.php/apps/richdocuments/settings/check HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com:443" Note3: Perhaps, port 80 is blocked by the new ISP. I temporarily forward port 80 to a webpage on the same Unraid. And checked it using some web tools. Not blocked. Note4: Re-installed LE docker from scratch. Renewed certificates but the problem persists. Frustrated. Kill me. Edited March 21, 20197 yr by sse450 Notes added.
March 21, 20197 yr If I may, I am setting up an S3 Compatible (Minio) container and would like to use Letsencrypt to generate the certs. I found another docker online (not Linuxserver) that states: -This image runs certbot under the hood to automate issuance and renewal of letsencrypt certificates. -Initial certificate requests are run at container first launch, once the image responds on a specified health check url. -Then certificates validity is checked at 02:00 on every 7th day-of-month from 1 through 31, and certificates are renewed only if expiring in less that 28 days, preventing from being rate limited by letsencrypt. -Issued certificates are made available in the container's /certs directory which can be mounted on the docker host or as a docker volume to make them available to other applications. So far everything is working great with the Linuxserver container (huge thank you by the way). Am just wondering how the container handles auto renewing the existing certs. Thanks for a great container! -MW
March 22, 20197 yr 5 hours ago, mfwade said: If I may, I am setting up an S3 Compatible (Minio) container and would like to use Letsencrypt to generate the certs. I found another docker online (not Linuxserver) that states: -This image runs certbot under the hood to automate issuance and renewal of letsencrypt certificates. -Initial certificate requests are run at container first launch, once the image responds on a specified health check url. -Then certificates validity is checked at 02:00 on every 7th day-of-month from 1 through 31, and certificates are renewed only if expiring in less that 28 days, preventing from being rate limited by letsencrypt. -Issued certificates are made available in the container's /certs directory which can be mounted on the docker host or as a docker volume to make them available to other applications. So far everything is working great with the Linuxserver container (huge thank you by the way). Am just wondering how the container handles auto renewing the existing certs. Thanks for a great container! -MW I'm just wondering why you read the other image's readme and even quoted it here, but you didn't read our image's readme. All of what you quoted is also in our readme in different words
March 22, 20197 yr Please accept my apologies. I missed this section in the readme... "Certs are checked nightly and if expiration is within 30 days, renewal is attempted. If your cert is about to expire in less than 30 days, check the logs under /config/log/letsencrypt to see why the renewals have been failing. It is recommended to input your e-mail in docker parameters so you receive expiration notices from letsencrypt in those circumstances." Thanks again for all the hard work. It is truly appreciated! -MW
March 22, 20197 yr 3 minutes ago, mfwade said: Please accept my apologies. I missed this section in the readme... "Certs are checked nightly and if expiration is within 30 days, renewal is attempted. If your cert is about to expire in less than 30 days, check the logs under /config/log/letsencrypt to see why the renewals have been failing. It is recommended to input your e-mail in docker parameters so you receive expiration notices from letsencrypt in those circumstances." Thanks again for all the hard work. It is truly appreciated! -MW No worries. Let us know if we can improve the docs so they are clearer
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.