nginx + let's encrypt issues
|
Posts: 9
Threads: 6
Joined: Mar 2017
Reputation:
0
[Solved]
Mar 29, 2017, 07:42 PM
(This post was last modified: Mar 29, 2017, 09:46 PM by rinzler40oz.)
Hello HTPCGuides,
I'm having issues enforcing SSL / letsencrypt on my nginx reverse proxy. If I go to my dynamic dns address (I'll say is domain.com) without SSL/LE configured it'll work just fine. Including domain.com/deluge after I've set it up with the vpn split tunnel guide and auto pia port forward.
For whatever reason, as soon as I attempt SSL everything stops working. I can't go to domain.com or domain/.com/deluge anymore from any browser (including LTE on my phone). However, whatever client device I try and access from it does resort to https but there's no content.
I've reinstalled / restored snapshot so many times that I've used up all of my certificates as well so it looks like I need to wait a couple days before I try again but I wanted to come here and look for any type of troubleshoot help.
I also noticed in the htpcguide for nginx + letsencrypt you're never actually instructed to:
sudo apt-get install letsencrypt
I've tried running that command as well before / after configuration but it didn't help.
Thanks in advance
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Solved]
Apr 12, 2017, 07:25 AM
The guide should work fine, many of us are using it and works great.
There are so many things that can prevent SSL to work, quite hard to troubleshoot based on the information you provided.
Make sure you have a working DDNS or domain name that you use correctly in nginx config.
Make sure you forward the ports in your router to the server running nginx (80 and 443).
Make sure your ISP is not blocking port 443 (one of our forum users had this issue unfortunately).
Once you have everything configured, check the content of nginx logs and post them here. There should be some information that can help us one step closer to resolve the issue.
As for the "sudo apt-get install letsencrypt": we don't use it since it way outdated in Debian/Ubuntu repository, we pull the most up-to-date versions (which gets updated once a certificate renewal is requested).
Posts: 45
Threads: 4
Joined: Mar 2017
Reputation:
5
[Solved]
Apr 12, 2017, 05:02 PM
(This post was last modified: Apr 12, 2017, 07:27 PM by Lt Hawk.)
(Apr 12, 2017, 07:25 AM)drake Wrote: The guide should work fine, many of us are using it and works great.
There are so many things that can prevent SSL to work, quite hard to troubleshoot based on the information you provided.
Make sure you have a working DDNS or domain name that you use correctly in nginx config.
Make sure you forward the ports in your router to the server running nginx (80 and 443).
Make sure your ISP is not blocking port 443 (one of our forum users had this issue unfortunately).
Once you have everything configured, check the content of nginx logs and post them here. There should be some information that can help us one step closer to resolve the issue.
As for the "sudo apt-get install letsencrypt": we don't use it since it way outdated in Debian/Ubuntu repository, we pull the most up-to-date versions (which gets updated once a certificate renewal is requested).
I would be above forum user. What I did to get around that was:
On my router instead of setting up forwarding, I set up a 'virtual server' and told my router to listen for port 4xxxx then send it to my server as 443. Note that if we do it this way, because of the way we set up our Nginx to always force ssl, we cannot use http anymore at all. If you look inside the reverse file, you can see that all http requests are immediately forwarded to https as 443 therefore breaking it again. So this is what you will type in your browser from a remote device: https://my.ddns.net:xxxxx/deluge where "xxxxx" is the new port you decided upon.
Also note if you wish to access from the local network you should only need to type 192.168.x.x/deluge ad your ISP cannot tell you what to do from within ;-)
Another tip, some network configurations will not allow you to send a request outbound to be routed back inbound, so try from your phone on mobile network instead of local network
I just thought of this, in the reverse file, you may be able to edit where it say if port 80 forward to 443. Change 443 to xxxxx. I will test this when I get home.
EDIT: editing the port 80 side will work in this situation.
Here is how:
in terminal - sudo nano /etc/nginx/sites-available/reverse
in this section:
server {
listen 80;
server_name my.ddns.net 192.168.x.x localhost;
return 301 https://$server_name$request_uri; # enforce https
}
change the last line to this:
return 301 https://$server_name:[port]$request_uri; # enforce https
where [port] is the port you chose on your router as the listening port to forward tcp 443 to the server.
close and save
ctrl-x, y, enter
check for syntax
nginx -t
restart nginx
sudo service nginx restart
Ladies and gentleman, take my advice. Pull down your pants and slide on the ice. -Sidney Freidman
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Solved]
Apr 25, 2017, 09:34 AM
If your ISP is not blocking any ports, then you should do the following to have certificate renewal to work.
We need to grant access to the
Code:
/well-known/acme-challenge/
location, and not use auth_basic for this. based on the nginx documentation, it is safe to remove auth_basic for cert renewal location, while I strongly advise you to keep all the other location directives protected by auth_basic (and I even keep the user/pass auth ON for all the service I run behind reverse proxy, like Sonarr, Deluge, VM, etc). This means two quite secure layers of protection, while you can use for example LastPass to automate logins, and most other app like NZB360 and Transdrone support auth and service authentication.
Edit the reverse config file:
Code:
sudo nano /etc/nginx/sites-available/reverse
Under the # Let's Encrypt Webroot plugin location -- allow access location, remove the content:
Remove:
Code:
location ~ /.well-known {
allow all;
And add the following:
Code:
location ^~ /.well-known/acme-challenge/ {
auth_basic off;
autoindex on;
}
This will disable auth_basic for well-known location and will always allow you to update certificates, as the Let's Encrypt client will be able to access the required location.
Restart nginx service and run the Cron Job to see if the update process was successful or not. Watch for any error messages. If non, and your certificates are not up to renewal yet, then you will get just a notification about this, but no error messages.
Let me know if this works for you (I have this configured on my system and works perfectly fine).
Posts: 2
Threads: 0
Joined: Apr 2017
Reputation:
0
[Solved]
Apr 28, 2017, 12:11 AM
I tried this setting and tested by going to [domain]/.well-known/acme-challenge but my server still prompted me for password so I don't think this configuration is correct
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Solved]
Apr 28, 2017, 04:36 AM
It works for me and many others. Did you restart nginx after you did the changes? Or a system restart? Don't visit the location in your browser, but trigger the cron job for cert uodate and see the logs, what do you have there?
Sent from my Sony Z5C from Tapatalk
Posts: 2
Threads: 0
Joined: Apr 2017
Reputation:
0
[Solved]
Apr 29, 2017, 02:42 AM
I won't be able to test this until my certificate is up for renewal, as that's when it tries to access the path. That's why I tried to manually try it. Because right now certbot says my certificate is not up for renewal and terminates early. But if I can't access the folder without password, certbot won't either. So you are able to access folder from browser (incognito) without password prompt?
Posts: 244
Threads: 1
Joined: Jul 2016
Reputation:
12
[Solved]
Apr 29, 2017, 05:54 PM
(Apr 29, 2017, 02:42 AM)guruyooko Wrote: I won't be able to test this until my certificate is up for renewal, as that's when it tries to access the path. That's why I tried to manually try it. Because right now certbot says my certificate is not up for renewal and terminates early. But if I can't access the folder without password, certbot won't either. So you are able to access folder from browser (incognito) without password prompt?
No, you don't need to be able to access anything related to this location from browser.
If you do the modifications correctly, restart nginx, and then trigger the Cron Job manually for cert update, you should see the output in the logs. If there are no other issues with your setup, it will work for sure.
It works for me and many other users confirmed it works fine.
Just don't forget, if you run the update manually (not with the Cron Job) to renew the certificates, you need to restart/reload nginx to load the updated certificates.
The guide has been updated with the new and correct configuration.
|
|
Recent Posts
|
About Swap
jonescelinaa Apr 10, 2024, 06:58 AM
|
Tracker Status: Error Connection Time Out
jonesPhedra Apr 04, 2024, 08:17 AM
|
Split Tunnel Docker Containers
jonesPhedra Mar 27, 2024, 03:10 AM
|
Plex server not powerful enough, but only with s...
jonesPhedra Mar 27, 2024, 03:02 AM
|
game Geometry Dash Scratch
jonescelinaa Jan 31, 2024, 04:21 AM
|
Latest unread posts | Unanswered posts |
|