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.
Related
Sorry for the limited understanding of Nginx and SSL. I have a React and Django app deployed on a server running on Nginx.
The React app is accessible using "example.org"(name is faked for demo purpose) and for the Django app, I have configured it to be accessible with port 3000 ie "example.org:3000".
The domain has SSL certificates installed and certificates are seen in "example.org" but while accessing "example.org:3000", the certificates are not available to this port.
I have been trying to allow ssl certificates to the port as well but couldnt succeed. I changed nginx conf file with listen 3000 ssl without success.
Please help, is there a way or should we need to modify the ssl certificates?
Nginx config at the moment is:
server {
listen 80 default_server;
server_name example.org;
return 301 https://example.org;
}
server {
listen 443 ssl;
server_name example.org;
ssl_certificate /etc/nginx/ssl/ssl_bundle.crt;
ssl_certificate_key /etc/nginx/ssl/example.key;
location / {
root /home/ubuntu/example/build;
index index.html index.htm;
}
}
The Port has nothing to do with the certs OR TLS Termination in general. IN case my assumptions are correct and your Django app is exposing its port 3000 by itself you need a proxy configuration that terminates the TLS for you.
server {
listen 8080 ssl;
server_name example.org;
ssl_certificate /etc/nginx/ssl/ssl_bundle.crt;
ssl_certificate_key /etc/nginx/ssl/example.key;
location / {
proxy_pass http://127.0.0.1:3000/;
proxy_set_header Host $host;
.....
}
}
This will terminate the TLS Session for you on Port 8080 and forwards the traffic to your Django app. There are other, more advanced options, proxying traffic to your appserver but this one will do it.
Note: In case you want to proxy the traffic through NGINX make sure Port 3000 is not exposed to the public anymore.
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.
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 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.
My server is running NGINX. My problem is my site is accessible by both IP address and the domain. But I want that when someone browse the IP address the user shoulde be redirected to my domain.
Example :: When any one browse through http://107.170.126.xxx he should be redirected to http://mydomain.com
Please can anybody help me? Thanks in advance
so you can add the server block in the sites-available configuration file like below
server {
listen 80;
server_name 111.11.111.111;
return 301 $scheme://yourname.com$request_uri;
}
so above code will make sure that if you enter 111.11.111.111 it will redirect to http://yourname.com
make sure after editing the config file to reload nginx server
It is known as IP Canonical Issue
You want your ip address to be redirected to your domain name
for that you can add following code in nginx server block or add an additional server block in nginx configuration
server {
listen 80;
server_name www.example.com example.com 192.168.xxx.xx;
return 301 https://www.example.com$request_uri;
}
I use this configuration on my server; if you try an HTTP connection to the IP address of the VPS it will be redirected to my main web site.
i solved redirect from ip adress http/https in ispconfig with:
server {
listen *:80;
listen *:443 ssl http2;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /var/www/clients/client1/web1/ssl/domain.example-le.crt;
ssl_certificate_key /var/www/clients/client1/web1/ssl/domain.example-le.key;
server_name xxx.xxx.xxx.xxx;
return 301 https://domain.example;
}
server {
listen *:80;
listen *:443 ssl http2;
*#Required TLS Version*
ssl_protocols TLSv1.1 TLSv1.2;
*#SSL Certificate Path*
ssl_certificate /etc/nginx/keyfiles/ssl_certificate.crt;
ssl_certificate_key /etc/nginx/keyfiles/ssl_cert.key;
*#IP Address*
server_name 000.111.222.333;
*#Domain Name to be redirected*
return 301 https://www.domainname.com/;
}