@DownPW anytime
Digitalocean step by step guide to nginx configuration
-
@phenomlab you have pm
-
@justoverclock Thanks. Your config appears to be in default, which is fine, but was not set correctly. In the
location
block, I’ve setproxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass http://127.0.0.1:8080/; proxy_redirect off; # Socket.IO Support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";
This should now work when you to to https://vfgest.it
-
@phenomlab works but if i type https://www.vfgest.it/ i see a 404 error page, works only with no www
-
@justoverclock Hold on.
-
@justoverclock That will work now, but your certificate binding is not correct. The certificate is for the non-www only, so you’ll get an error. Let me fix that.
-
@phenomlab for sure is my fault, i’ve done all by myself with a tutorial with a certbot
-
@justoverclock All done. Both https://vfgest.it and https://vfgest.it should work now
You have to adjust
certbot
for this to work - see below command transcript executed on your hostroot@vito-fiore:/etc/nginx/sites-enabled# sudo certbot Saving debug log to /var/log/letsencrypt/letsencrypt.log Which names would you like to activate HTTPS for? We recommend selecting either all domains, or all domains in a VirtualHost/server block. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: vfgest.it 2: www.vfgest.it - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel): - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - You have an existing certificate that contains a portion of the domains you requested (ref: /etc/letsencrypt/renewal/vfgest.it.conf) It contains these names: vfgest.it You requested these names for the new certificate: vfgest.it, www.vfgest.it. Do you want to expand and replace this existing certificate with the new certificate? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (E)xpand/(C)ancel: E Renewing an existing certificate for vfgest.it and www.vfgest.it Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/vfgest.it/fullchain.pem Key is saved at: /etc/letsencrypt/live/vfgest.it/privkey.pem This certificate expires on 2022-12-29. These files will be updated when the certificate renews. Certbot has set up a scheduled task to automatically renew this certificate in the background. Deploying certificate Successfully deployed certificate for vfgest.it to /etc/nginx/sites-enabled/vfgest Successfully deployed certificate for www.vfgest.it to /etc/nginx/sites-enabled/vfgest Your existing certificate has been successfully renewed, and the new certificate has been installed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you like Certbot, please consider supporting our work by: * Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate * Donating to EFF: https://eff.org/donate-le - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - root@vito-fiore:/etc/nginx/sites-enabled#
-
@justoverclock You can drop the
vfgest
conf file as it’s not being used -
@phenomlab thank you very much!!!
-
@justoverclock Anytime
-
@justoverclock You should change your app so that it only listens on
localhost
or127.0.0.1
for security reasons as you are currently exposing it publicly via port 8080. The reverse proxy means that this is not required, asnginx
redirects it for you and is fully secure. -
@phenomlab so now this app use a server created by me with nodejs…so all the api endpoints are available through port 3030
can i set the env variable to https://vfgest.it:3030 ?
-
@justoverclock If the app is listening on 8080, which it typically would, then no, leave it alone. Are the endpoints intended to be public ? Typically, these aren’t accessible via
nginx
-
@phenomlab if now i try to login, the endpoint of my api doesn’t work because of mixed content
Mixed Content: The page at 'https://vfgest.it/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://MYSERVERIP:3030/api/login'. This request has been blocked; the content must be served over HTTPS.
-
@justoverclock Yes, that’s expected. You should change your endpoint so it works over
https
otherwise it won’t be secure, and is then subject to eavesdropping as the traffic is being sent in clear text. From a security standpoint, this is an absolute no. -
@phenomlab ok, so i can add https, can i leave the ip or i need to add vfgest.it:3030?
-
@justoverclock You can use either, but if the API is not meant to be exposed publicly, and should only be accessed by the app itself, then you should use
127.0.0.1
. Ultimately, the design is up to you. -
@phenomlab well, i’ve learned something new, no its a private crm developed by me, so no external use
-
@justoverclock Exactly - that’s why I asked You won’t be exposing the API then. Any issues, let me know.
-
@phenomlab ok i’ll try later when people are not using the crm :P, and i’ll post here the result
Did this solution help you?
Related Topics
-
-
-
-
-
-
-
nginx can't start again
Moved Solved Configure -