@justoverclock Can you give me access to your host ? Send me the details in a PM
@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 set
proxy_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 host
root@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 or 127.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, as nginx 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.
