I have developed an app which talks to a server over https.
I recently discovered that my certificate has expired, and now the app refuses to talk to the server.
NSURLConnection/CFURLConnection (kCFStreamErrorDomainSSL, -9814)
How can I do a quick fix so that my app will work (insecurely), until I can renew my certificate?
I tried the following, but the app still protests (as does browsers).
server {
ssl on;
ssl_certificate ssl/server.crt;
ssl_certificate_key ssl/server.key;
listen 443;
rewrite ^ http://$http_host$uri permanent; # temporary workaround
}
It is fundamentally impossible.
TLS handshake and all checks are done before any request will be sent. This is what "security" is about.
convert the ssl server to normal server and create a new ssl server that redirects all requests
server {
listen 443;
server_name whatever.com www.whatever.com;
return 301 http://$http_host$request_uri;
}
server {
listen 80;
server_name whatever.com www.whatever.com;
# old configurations from the ssl server
}
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'm trying to configure my Nginx in a way so that all HTTP requests are redirected to HTTPS. This is a testing environment and I don't have the domain, hence, I'm not sure whether the redirect can function properly. The host part is simply 127.0.0.1. This is the current configuration:
server {
listen 80;
listen [::]:80;
server_name _;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name _;
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
...
I also tried:
removing server_name _;
putting the return 301 in a location block;
adding further ssl settings, such as ssl_session_timeout, ssl_protocols, ssl_prefer_server_ciphers.
ssl on has been removed.
The syntax has been tested, nginx reloaded, the ports have been tested with nmap (both 80 and 443 are open).
When I curl -k (since the certificate is self-signed) 127.0.0.1 I get this message:
301 Moved Permanently
nginx/1.14.0 (Ubuntu)
When I curl -k 127.0.0.1:443 I get this message:
400 The plain HTTP request was sent to HTTPS port 400 Bad Request The
plain HTTP request was sent to HTTPS port nginx/1.14.0 (Ubuntu)
Could someone help me to understand what am I doing wrong? I'd be happy to provide more information. Thank you so much!!
So here is an nginx config that is working for me.
upstream app {
server app:8080;
}
server {
listen 80;
listen [::]:80;
server_name webprojects-dev.co.uk;
return 301 https://webprojects-dev.co.uk$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 http2;
server_name webprojects-dev.co.uk;
include /etc/nginx/common.conf;
include /etc/nginx/ssl.conf;
location / {
proxy_pass http://app;
include /etc/nginx/common_location.conf;
}
}
In this instance nginx is running in a stack of docker containers networked with docker compose but that shouldnt have any bearing on how it works.
The upstream is the app container (and port) for a reverse proxy.
The first server block is forwarding on requests to https. As you can see the main difference between mine and yours is the server_name is the domain name and is also included in the return 301 statement.
The second server block is for https. Again server_name is a domain but other than that the only other difference I can see is I don't have ssl on the line listen [::]:443.
Disclaimer: Not an expert on nginx. I just hacked away till I had a reverse proxy config that works for me and now I just copy and paste it for everything.
I'm trying to learn more about how CDN works. How does it knows which Edge sever should it redirect the client to for lowest latency? Thank you.
For this purpose, Upstream configuration is used in Nginx webserver.
nginx redirect users's requests to the destination server.
sample of Nginx upstream is as bellow.
upstream example.com {
server example.com;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
access_log /var/log/nginx/access.log custom;
location / {
proxy_pass http://example.com;
}
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'm trying to put a server#home in place with some basic services. All services run into a dedicated VM. Each VM is hosted on vSphere 5.5. So far I have :
Debian wheezy with nginx used as a reverse proxy : 192.168.1.12
Debian wheezy with nodeJS used as a webapp server : 192.168.1.43
192.168.1.43:3000 => http web server that makes a redirection on 192.168.1.43:3001
192.168.1.43:3001 => https web server that makes provides the service
Debian wheezy with madsonic installed : 192.168.1.35
As said in documentation I put --https-port=443 in the config to enable https access
I use nginx to be able to have things like this :
myapp.mydomaine.com => go to nodejs # 192.168.1.43
music.mydomain.com => go to madsonic # 192.168.1.35
I followed a tutorial and edited the "default" file in /etc/nginx/sites-enabled. Here is how it looks like :
server {
listen 80;
server_name myapp.domaine.com;
location / {
proxy_pass http://192.168.1.43:3000;
}
}
server {
listen 443;
server_name myapp.domain.com;
ssl on;
ssl_certificate [...];
ssl_certificate_key [...];
location / {
proxy_pass https://192.168.1.43:3001;
}
}
server {
listen 80;
server_name music.domain.com;
location / {
proxy_pass http://192.168.1.35:4040;
}
}
server {
listen 443;
server_name music.domain.com;
ssl on;
ssl_certificate [...];
ssl_certificate_key [...];
location / {
proxy_pass https://192.168.1.35;
}
}
The first redirection on myapp works. The redirection on music works when I had only http on the madsonic server. When I activate https on madsonic server I get a 502 Bad gateway error (but the URL in Firefox is https://music.domain.com).
I also tryed some other methods like mentionned here :
How to redirect on the same port from http to https with nginx reverse proxy
Did not work either.
I also saw in /var/logs/nginx/error.log that the 502 error is due to a SSL_do_handshake error (SSl23_GET_SERVER_HELLO:tlsv1). No idea if it is related to the 502 error or not.
I'm a bit confused because other https services work fine. Someone has a suggestion ? Thanks very much.
Here is the answer of the user "desasteralex" that was posted for the same question on serverfault.com. It worked so I share his answer here (and big thx him btw :D).
First of all, Nginx is your SSL terminator here. That means that you don't need to run your app in both - HTTP and HTTPS mode. HTTP would be enough.
So, for your app the config could look like that:
server { listen 192.168.1.12:80; server_name myapp.domain.com; location / { rewrite ^ https://$server_name$request_uri? permanent; } }
The directive above will redirect all HTTP requests to HTTPS.
server { listen 192.168.1.12:443; server_name myapp.domain.com; ssl on; ssl_certificate [...]; ssl_certificate_key [...]; location / { proxy_pass https://192.168.1.43:3000; } }
I've chosen the port 3000 in the proxy_pass here to point to the HTTP version of your app. You would need to turn off the redrection of your app to port 3001.
Regarding your music.domain.com redirection - for HTTP you use the port 4040 in the proxy_pass parameter, in HTTPS you don't. I assume that the madsonic server only listens on port 4040, so a config could look like this:
server { listen 192.168.1.12:80; server_name music.domain.com; location / { rewrite ^ https://$server_name$request_uri? permanent; } }
server { listen 192.168.1.12:443; server_name music.domain.com; ssl on; ssl_certificate [...]; ssl_certificate_key [...]; location / { proxy_pass https://192.168.1.35:4040; } }
Hope this helps.