I know that NGINX is not supposed to be used as a forward proxy but I have a requirement to do so ... Anyway, obviously it is not to hard to get http to work as a forward proxy but issues arise when trying to configure https. I generated some self signed certs and then try to connect to https://www.google.com and it gives me the error ERR_TUNNEL_CONNECTION_FAILED. The issue has to do with my certs somehow but I have no idea how to fix the issue. Does anyone know how to achieve this functionality ?
Here is my config
server {
listen 443 ssl;
root /data/www;
ssl on;
ssl_certificate /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/certs/server.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;
location / {
resolver 8.8.8.8;
proxy_pass https://$http_host$uri$is_args$args;
}
}
The reason NGINX does not support HTTPS forward proxying is because it doesn't support the CONNECT method. However, if you are interested in using it as a HTTPS forwarding proxy you can use the ngx_http_proxy_connect_module
I was able to configure SSL/TLS forward proxying with this configuration, using the stream module.
stream {
upstream web_server {
server my_server_listening_on:443;
}
server {
listen 443;
proxy_pass web_server;
}
}
Resources:
https://nginx.org/en/docs/stream/ngx_stream_core_module.html
https://serversforhackers.com/c/tcp-load-balancing-with-nginx-ssl-pass-thru
Related
I have a web-app consisting of front- and back-end services. I want to secure my front-end service with let's encrypt certificate, but then I have to use secured connection between front- and back-end. I have the back-end service served on a custom port. For securing back-end I want to use nginx to proxy my server. However, I am struggling to get it right. Here is my nginx configuration:
server {
listen 8082;
server_name <my_domain_name>;
ssl on;
ssl_certificate /etc/letsencrypt/live/<my_domain>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<my_domain>/privkey.pem;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 SSLv3;
location / {
proxy_pass http://0.0.0.0:8081;
}
}
First, I just wanted to get it through, without ssl. But it does not work like this, nothing is served on 8082. If it works, I thought I could use my letsencrypt certificates here, though I'm not sure, whether it is possible and I understand things correctly.
I would appreciate any help! Thanks a lot in advance!
Update
I figured out the problem was in iptables. After I added the port 8082 to them, it worked. What I don't understand, why I can connect to the port 8081, although it is not in the iptables.
However, now I get ERR_SSL_PROTOCOL_ERROR when I try https://my_domain:8082.
I also tried to add ssl to the listen directive, like listen 8082 ssl;. Then I get ERR_CONNECTION_RESET.
Just for the record. The problem was indeed in the directive listen.
Adding
listen 8082 ssl;
and removing
ssl on;
solved it.
It is a mystery, why it didn't work and gave me ERR_CONNECTION_RESET before. Now it works.
location #backend {
proxy_pass http://backend;
}
#backend is a named location which allows you to reference it like a variable i.e. like
location / {
error_page 404 = #backend;
}
For your problem try something like
location / {
proxy_pass http://backend;
}
I have a definition in Nginx where by different ports, I need different SSL client verify options.
When I connect to :443/location1, Nginx will request a client cert, but will fail with "HTTP 400, Bad Request, Require Client Cert". It seems as if NGinx uses the server rule for port 444 which has a "ssl_verify_client off" on connect, but on the route, NGinx checks to see if a client cert was given since it's rule for port 443, says client verify is required and then fails in the actual HTTP request.
I dug around and can't seem to find any docs around this. Clearly same IP:PORT is an issue, but everything thus far indicates by PORT I can change the config but that doesn't seem to be the case.
server {
listen 443;
ssl on;
ssl_certificate /etc/nginx/ssl-certs/a.cert;
ssl_certificate_key /etc/nginx/ssl-certs/a.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_client_certificate /etc/nginx/ssl-certs/ca.pem;
ssl_verify_client on;
location /location1 {
[..]
}
}
server {
listen 444;
ssl on;
ssl_certificate /etc/nginx/ssl-certs/a.cert;
ssl_certificate_key /etc/nginx/ssl-certs/a.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_verify_client off;
location /location2 {
[..]
}
}
I eventually figured it out.
Client rejection is mandatory, but can happen either after the connection has been made or during the handshake.
NGINX will allow the handshake to complete, then enforce if the
client was verified.
APACHE (at least the last version I used) fails
the handshake.
Similar to this other question here I'm attempting to verify SSL Client Certificates with nginx that have been sent via AWS API Gateway.
I noticed that in the documentation, AWS API Gateway only sends the client certificate along with HTTP requests. Does this mean that HTTPS should not be configured?
Contrary to the link to the question I posted above, the domain that nginx is hosted on does not have https certificates setup.
Any help, or a link to a working configuration using ssl_verify_client without ssl configured for the domain would be greatly appreciated.
Here is the nginx configuration I'm working with currently:
daemon off;
events {
worker_connections 4096;
}
http {
server {
listen 2345 default_server;
ssl_trusted_certificate /certs/api-gateway.crt;
ssl_client_certificate /certs/api-gateway.crt;
ssl_verify_client on;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";
ssl_prefer_server_ciphers on;
location /ping {
proxy_pass http://my.http.public.endpoint.com;
}
location / {
if ($ssl_client_verify != SUCCESS) { return 403; }
proxy_pass http://my.http.public.endpoint.com;
proxy_set_header X-Client-Verify $ssl_client_verify;
}
}
}
You're misinterpreting the docs, though the reason is easily understandable.
API Gateway will use the certificate for all calls to HTTP integrations in your API.
The phrase to parse is "HTTP integrations" -- as opposed to Lambda or AWS Service proxy -- not "HTTP" as in "HTTP without SSL". They're using "HTTP" in a generic sense to describe a type, not the specific details of the transport.
SSL client certificates do not work without HTTPS, and won't work without an SSL certificate configured on the server.
First of all my problem is different.
I have used listen 443 default ssl; also listen 443 ssl; and commenting out # but seems nothing is working. Port 80 works fine but on port 443 I get this error.
Currently this is the default file for nginx.
server {
listen 80;
listen 443 ssl;
#listen 443 default ssl;
server_name .******.org;
keepalive_timeout 70;
#ssl on;
ssl_certificate /etc/ssl/private/lol/www.*******.crt;
ssl_certificate_key /etc/ssl/private/lol/www.********.key;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
On ssl_protocols I also tried to only use SSLv3 TLSv1 but its same. My nginx version is 1.2.1.
I have gone through many online sites even here but I think my problem is not being solved with any of those methods mentioned by different geeks.
So finally I am here.
Any suggestions?
P.S: I am using cloudflare, but there I have turned Universal SSL Off as I want to use other ssl.
You should write two server blocks one for http and one for https like:
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/public/;
index index.html;
#other settings
}
server {
listen 443;
server_name localhost;
root /var/www/public/test/;
index index.html;
ssl on;
ssl_certificate /etc/nginx/certs/wss.pem;
ssl_certificate_key /etc/nginx/certs/wss.pem;
#other settings
}
I have tried it with the default nginx settings and both ports work fine.
If you are experiencing this issue with Google Compute Engine / Google HTTP loadbalancer... Ensure you have your instance group setup with separate named ports for http: 80 and https: 443.
Or it will randomly select a port.
This came about in my case due to originally setting up the HTTP loadbalancer when it was still in beta. Then when I added another loadbalancer it refreshed the settings and started randomly failing.
It was failing 50% of the time, because I only had Nginx setup with a vhost for port 80, and it was trying to push HTTP requests to port 80 on the web boxes.
The error you get is most likely, because you send a unencrypted HTTP-request to the SSL-port.
Something like
wget http://example.com:443/
This is a client problem (the server just tells you that it refuses to answer non-encrypted messages on to-be-encrypted channels)
It is client problem.
I was having the same issue. Turns out the https prefix was being dropped in the URL.
In the browser inspect the network traffic to verify that the browser is sending an http request, not https. Issue found!
Manually type in the wanted URL with https to retrieve the page successfully.
Now you can go about applying a focused fix to your client.
I need to use Nginx as an SSL proxy, which forwards traffic to different back ends depending on the subdomain.
I have seem everywhere that I should define multiple "server {" sections but that doesn't work correctly for SSL. Doing that I would always have the SSL being processed in the first virtual host as the server name is unknown until you process the https traffic.
Scenario:
One IP address
One SSL wildcard wildcard
Multiple backends which needs to be accessed like the following:
https://one.mysite.com/ -> http://localhost:8080
https://two.mysite.com/ -> http://localhost:8090
Nginx says "if" is evil: http://wiki.nginx.org/IfIsEvil, but what else can I do?
I have tried this, but it doesn't work, I get an 500 error but nothing in the error logs.
server {
listen 443;
server_name *.mysite.com;
ssl on;
ssl_certificate ssl/mysite.com.crt;
ssl_certificate_key ssl/mysite.com.key;
location / {
if ($server_name ~ "one.mysite.com") {
proxy_pass http://localhost:8080;
}
if ($server_name ~ "two.mysite.com") {
proxy_pass http://localhost:8090;
}
}
Has anyone managed to accomplish this with Nginx? Any help/alternatives, link, would be much appreciated.
I found the solution which is basically to define the SSL options and the SSL certificate outside the "server" block:
ssl_certificate ssl/mysite.com.crt;
ssl_certificate_key ssl/mysite.com.key;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+EXP;
ssl_prefer_server_ciphers on;
server {
listen 80;
server_name *.mysite.com;
rewrite ^ https://$host$request_uri? permanent;
}
server {
listen 443 ssl;
server_name one.mysite.com;
ssl on;
location / {
proxy_pass http://localhost:8080;
}
}
server {
listen 443 ssl;
server_name two.mysite.com;
ssl on;
location / {
proxy_pass http://localhost:8090;
}
}
Key things:
"ssl on;" is the only thing that needs to be within the "server" blocks that listen in https, you can put it outside too, but what will make the "server" blocks that listen in port 80 to use https protocol and not the expected http.
Because the "ssl_certificate", "ssl_ciphers: and other "ssl_*" are outside the "server" block, Nginx does the SSL offloading without a server_name. Which is what it should do, as the SSL decryption cannot happen based on any host name, as at this stage the URL is encrypted.
JAVA and curl don't fail to work now. There is no server_name - host miss match.
The short answer is to use Server Name Indication. This should work by default in common browsers and cURL.
according to http://www.informit.com/articles/article.aspx?p=1994795, you should indeed have two "server" sections, with two different server names.
In each one, you should include your ssl_* directives.