I used to connect my app (Next, React, ApolloClient) to my backend (ApolloServer) using this url: http://167.99.145.82:4020/graphql, and it worked.
Now that I have switched to https, GraphQL Playground still works in the browser (https://sketchdaily.club/graphql), but when the client (https://sketchdaily.vercel.app/) tries to connect to it, it returns [Network error]: TypeError: Failed to fetch.
Why could that happen?
My nginx config:
server {
listen 80;
listen [::]:80;
server_name sketchdaily.club www.sketchdaily.club;
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/sketchdaily.club/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/sketchdaily.club/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location / {
proxy_pass http://0.0.0.0:4020;
}
}
What am I doing wrong?
Your certificate has been issued for the domain sketchdaily.club and only this name is included in the certificate. If you now connect to the server using it's IP address the used server name 167.99.145.82 does not match the name used in the certificate sketchdaily.club and thus the client will refuse connection because the server can not be trusted.
Just try it out and open https://167.99.145.82 in any web browser - it will not work. Therefore for HTTPS you have to use the DNS name of your server or change the registration at Let's Encrypt to also include the IP address of your server into the certificate as "Subject alternative name", then you can continue to use the IP address.
Related
I'm trying to add ssl to my website hosted on my VPS (Ubuntu 20). I do not have any skill nginx (v 1.18.0) and I just followed tutorials to add ssl to my website by helping letsEncrypt and certbot.
Here I have some problems:
I followed this tutorial and in it's 3rd part I only used sudo certbot --nginx -d example.com because I faced error in sudo certbot --nginx -d www.example.com. So I decided to just add example.com and forward every request from www.appsazz.ir to appsazz.ir in nginx. Now certbot generated a file inside /etc/nginx/conf.d with the name www.appsazz.ir.conf.It's configuration did't resolved my problem I tryed to changed it a little. Here is the file configurations:
server {
if ($host = appsazz.ir){
return 301 https://$host$request_uri;
}
if ($scheme != "https"){
return 301 https://$host$request_uri;
}
}
server {
listen 80;
listen [::]:80;
root /var/www/venus;
server_name appsazz.ir www.appsazz.ir;
# managed by Certbot
listen 443 ssl default_server;
ssl_certificate /etc/letsencrypt/live/appsazz.ir/fullchain.pem; #managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/appsazz.ir/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
nginx -t response seems to be ok:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
why when I request from browser to appsazz.ir it still loads with not secure?
when I request on www.appsazz.ir Chrome responds with ERR_INTERNET_DISCONNECTED error
Your setup is correct and appsazz.ir is loading with https:// on the browser. I can also see the ssl certificate issued using let's encrypt. However www.appsazz.ir isn't configured properly in your DNS provider. A quick nslookup www.appsazz.ir is showing this:
Server: 1.1.1.1
Address: 1.1.1.1#53
** server can't find www.appsazz.ir: NXDOMAIN
Please configure the subdomain www to point to a valid IP or endpoint and it should work. In your case. appsazz.ir points to IP 188.121.122.161, I guess www.appsazz.ir should be pointing to the same.
I noticed something on an nginx config. There are 2 upstream blocks configured that are exactly the same:
upstream test1.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
proxy_pass test1.example.com;
ssl_certificate /opt/certs/example1.com.crt;
ssl_certificate_key /opt/example1.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
upstream test2.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
proxy_pass test2.test.com;
ssl_certificate /opt/certs/test.com.crt;
ssl_certificate_key /opt/test.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
I have 2 server blocks listening on port 443. So I have the same server listening for 2 separate connections on the same block... if that makes sense.
My thought was that this would fail because the same server listening for incoming https connections to test1 and test2.example.com wouldn't know 'where' to route the requests too. But that's not what's happening.
If I go to https://test1.example.com I am routed to the correct app. And https works as expected.
If I go to https://test2.example.com I am routed to the correct app. But https does not work as expected. This is confusing because both certs are wildcard certs. I am unsure why 1 succeeded and one failed.
If I comment out the first upstream block:
# upstream test1.example.com { server flaskapp.example.com:5000 }
# server {proxy_pass test1.example.com; }
Something stranger happens. Connecting to https://test2.test.com gives me a 'failed to connect to server' error message in my web browser. And the logs show this as the error:
No "ssl_certificate" is defined in server listening on SSL port while SSL handshaking
This is for test1.example.com, and I know the wildcard cert works. I'm using it elsewhere. So I'm unsure why I'm getting a 'failed to connect to server' error when I go to test1.example.com in this manner.
A few things to note:
Both test1.example.com and test2.test.com point to the same nginx server.
If both upstream/server blocks are working then test1.example.com shows the site is ssl secure. That is expected. But test2.test.com shows the website is insecure. This leads me to believe that only the first server/upstream block is working as expected. And the 2nd server/upstream block is being ignored.
actually does make sense, in that a server shouldn't be listening for incoming connections to the same port, and route to different servers. The proxy doesn't know what to do with 1 of the connections (bad explanation on my part).
But that doesn't explain why the 2nd server/upstream block would outright fail. Even when test2.example.com is the only server/upstream block configured.
Any advice is appreciate, thank you for your time and consideration. This is something I've been struggling to understand and make heads/tails of.
bossrhino
I think you need to use server_name directive. Because your web server listens on same ip and the same port for two subdomains.
I guess this config file should work properly:
upstream test1.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
server_name test1.example.com;
proxy_pass test1.example.com;
ssl_certificate /opt/certs/example1.com.crt;
ssl_certificate_key /opt/example1.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
upstream test2.example.com {
server flaskapp.example.com:5000
}
server {
listen 443 ssl;
server_name test2.example.com;
proxy_pass test2.test.com;
ssl_certificate /opt/certs/test.com.crt;
ssl_certificate_key /opt/test.com.key;
ssl_protocols TLSv1.2;
ssl ciphers "ECDHE-ECDSA-AES128-GCM-SHA256"
}
I want to access grafana from my browser and make it available publicly. However, I am receiving the following error:
If you're seeing this Grafana has failed to load its application files
1. This could be caused by your reverse proxy settings.
2. If you host grafana under subpath make sure your grafana.ini root_url setting includes subpath
3. If you have a local dev build make sure you build frontend using: yarn start, yarn start:hot, or yarn build
4. Sometimes restarting grafana-server can help
I tried going through some issues and added the domain name in the grafana's settings. My NGINX is perfect and as per the documentation. In fact, everything was working well. The problem is in the anonymous session i.e. if I try to load this in no-user mode, it doesn't load. In the logged-in mode, it loads but without all the dashboards that I had created.
My NGINX conf is as follows:
proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=grafana_cache:10m max_size=20g
inactive=60m use_temp_path=off;
server {
server_name foo.bar www.foo.bar;
location / {
proxy_cache grafana_cache;
proxy_pass http://127.0.0.1:3000;
include /etc/nginx/proxy_params;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/foo.bar/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/foo.bar/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = www.foo.bar) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = foo.bar) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name foo.bar www.foo.bar;
return 404; # managed by Certbot
}
I expect the grafana dashboard to be working with and without the user logging in.
I removed the hash_bucket_size set to 64 in my nginx.conf and got it working.
I have an nginx configuration with multiple virtual hosts and subdomains. Each subdomain needs to have a different SSL certificate bound. Here is the configuration for my first subdomain:
server {
listen 443;
server_name a.website.com;
ssl on;
ssl_certificate /etc/nginx/ssl/a/a.crt;
ssl_certificate_key /etc/nginx/ssl/a/a.rsa;
.....
The configuration for my second:
server {
listen 443;
listen 3443;
server_name b.website.com;
ssl on;
ssl_certificate /etc/nginx/ssl/b/b.crt;
ssl_certificate_key /etc/nginx/ssl/b/b.key;
....
The problem is if I go to b.website.com, the SSL certificate for both a.website.com and b.website.com are returned when I expect only b.website.com to be bound. I validated this using ssllabs.
Any advice?
I didn't notice that in ssllabs the second certificate was only returned if SNI wasn't enabled which makes sense because both certs are on the same IP. Apparently the integration we're working with doesn't support SNI (crazy I know) so I guess I have to spin up another server.
I have Mattermost installed in my server, currently I can login to it by browsing through http://192.168.x.x:8066, I've installed a self-signed cerrtificate for this IP, but when I tried to browse it with https://192.168.x.x:8065, it failed to redirect to the Mattermost page.
Below is the configuration of my nginx.conf:
server {
listen 443 http2 ssl;
listen [::]:443 http2 ssl;
listen 443;
server_name 192.168.3.201:8066;
ssl on;
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
}
However, when I just browse the URL without port 8066 , it displays the default nginx page with no errors.
What's wrong with my nginx.conf file? I'm still new to nginx FYI.
Any suggestions will be very much appreciated.
I suggest you follow the example nginx configuration from the documentation here. Start with that config file, updating server_name to be the domain name you want mattermost to be reachable from, and server to be the IP address and port on which mattermost is listening.
Once you've got that working, you can continue through the instructions to #9 which covers setting up SSL.