I have a use-case where upstream servers will trust different CAs. This is mainly happening during transition period and hence I would like to have my nginx proxy to the upstream servers by trying two different CA certs.
Currently I have an idea of doing something like:
location /upstream1 {
proxy_pass https://$http_host$uri;
proxy_ssl_certificate /home/keys/cert.pem
proxy_ssl_certificate_key /home/keys/key.pem
proxy_ssl_trusted_certificate /home/keys/trust.pem
proxy_intercept_errors on;
recursive_error_pages on;
error_page 495 496 = #use_cert2
}
location #use_cert2 {
proxy_pass https://$http_host$uri;
proxy_ssl_certificate /home/keys/cert2.pem
proxy_ssl_certificate_key /home/keys/key2.pem
proxy_ssl_trusted_certificate /home/keys/trust2.pem
}
Is this the most elegant way to have the logic of "try to use this certificate to proxy to upstream server. If the server doesn't like it, then use this different certificate".
Also it calls #use_cert2, does it preserve any rewrite that happened in the previous call block?
Apology in advance if the question does not have enough information.
Thank you for reading the post!
Related
So I have been working on a project on a separate server for a company and now they want me to set it up for production with their SSL certificate and Key.
Here is my nginx.config file that is on the server I am working on
`
server{
listen 443;
ssl on;
ssl_certificate "/etc/pki/tls/certs/example.cer";
ssl_certificate_key "/etc/pki/tls/certs/exampleKey.pem";
#ssl_session_cache shared:SSL:1m;
#ssl_session_timeout 10m;
#ssl_ciphers HIGH:!aNULL:!MD5;
#ssl_prefer_server_ciphers on;
server_name snap.example.gov;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location / {
proxy_pass http://localhost:80;
proxy_redirect off;
proxy_set_header Host $host ;
proxy_set_header X-Real-IP $remote_addr ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;
proxy_set_header X-Forwarded-Proto https;
}`
I've tried to follow all the tutorials but it still won't load over 'snap.example.gov'. I really need help to get this to load over https on the 'snap.example.gov' domain. What am I doing wrong? I'm still new to this so I'm not quite sure what to do.
Thank you guys in advance.
All the world is the internet and IP addresses are but its players. How does your computer know which computer server to connect to when you type 'snap.example.gov'? The answer is, it doesn't! Thus began the Domain Name System which affords your operating system the ability to go on the internet and query a series of well known servers that do know the IP address of every registered domain name on the internet. DNS knows that the IP address of stackoverflow.com is 151.101.65.69. Your computer doesn't.
So, you have to register your server's domain name with those DNS servers and tell them what the IP address to access your site is. The fee for this service is as low as $11 or so but can be up to $50 assuming the name is available at all. example.gov, for example, is owned by the GSA of the United States government so you are not likely going to be able to register that name.
There are a large number of domain name registrars and stackoverflow does not really like us to recommend one but searching for that will bring up some good ones.
My nginx upstream has multiple servers, eg:
upstream backend {
server backend1.example.com:12345;
server backend2.example.com:12345;
server anotherbackend.com:12345;
}
server {
listen 12345;
proxy_pass backend;
proxy_ssl on;
proxy_ssl_verify on;
proxy_ssl_name ??
The proxied HTTPS server can provide certificates with any of the subject names backend1.example.com or anotherbackend.com. Is it possible to configure the proxy_ssl_name to verify certificate with any of these subject names? Or do all the backend servers have to present the same certificate?
If you have corresponding certificate for every server, you can use
proxy_ssl_name $proxy_host;
Or can create one certificate with all Subjec Alt Name inside and distribute it to all backends
I have done some resarch for this matter and there are some unaswered question regarding my issue, however I managed to solve half of what is needed (thanks to people on the site).
Scenerio:
I have Nginx as a reverse proxy in internal corporate network. I need to pass traffic to Internet behind corporate proxy.
Half of the solution:
To achive this, following works fine:
server {
listen 80;
server_name myhost.com;
location / {
proxy_set_header Host google.com;
proxy_pass http://corporateproxy:9999/;
}
}
However, above solution does not use SSL between corporate proxy and google.com. Do you have any idea how to add SSL to this?
I have tried adding protocol or port to header but it is not working this way.
I cannot modify anything on the corporate proxy. It should work like this: the URL being accessed is with https it will be redirected to https; http to http. Unfortunatelly header that contains only dns name is treated as http request.
Unfortunatelly the simplest solution does not work because nginx does not respect http_proxy settings on RedHat Machine:
server {
listen 80;
server_name myhost.com;
location / {
proxy_pass https://google.com/;
}
}
Any help will be highly appreciated.
We are using MUP for Meteor deployment to AWS. Couple of weeks ago we got excited that we can now switch to a free cert, thanks to Letsencrypt and Kadira. Everything was working very nicely, until I realized in the logs that client IP is no longer being passed through the proxy... No matter what I do, I see 127.0.0.1 as my client IP. I was trying to get it in methods using this.connection.clientIP or headers package.
Well, after doing much research and learning in-depth how stub and nginx work, I came to conclusion that this was never working.
The best solution I came up with is to use proxy_protocol as described by Chris, but I could not get it to work.
I have played with settings of /opt/stud/stud.conf and attempted to turn write-proxy and proxy-proxy settings on.
This is what my nginx config looks like:
server {
listen 80 proxy_protocol;
server_name www.example.com example.com;
set_real_ip_from 127.0.0.1;
real_ip_header proxy_protocol;
access_log /var/log/nginx/example.access.log;
error_log /var/log/nginx/example.error.log;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto http;
}
}
Here is what my headers look like on production EC2 server:
accept:"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
accept-encoding:"gzip, deflate, sdch"
accept-language:"en-US,en;q=0.8"
cache-control:"no-cache"
connection:"upgrade"
host:"127.0.0.1:3000"
pragma:"no-cache"
upgrade-insecure-requests:"1"
x-forwarded-for:"127.0.0.1"
x-forwarded-proto:"http"
x-ip-chain:"127.0.0.1,127.0.0.1"
x-real-ip:"127.0.0.1"
So, the questions of the day. Using MUP with SSL, is there a way to get a pass-though client IP address?
I know you said you have tried using headers, but you may give it another shot and see if you can get something this way. I was having alot of problems with x-forwarded-for counts not staying consistent, but if I pull from the header chain, [0] is always the client IP.
Put this code in your /server folder:
Meteor.methods({
getIP: function() {
var header = this.connection.httpHeaders;
var ipAddress = header['x-forwarded-for'].split(',')[0];
return ipAddress;
}
});
In your browser console:
Meteor.call('getIP', function(err, result){
if(!err){
console.log(result);
} else {
console.log(err);
}
};
See what you get from that response. If that works, you can just call the method on Template.rendered or whenever you need the IP.
Otherwise, I'm pretty sure you should be able to set the IP to an arbitrary header in your nginx conf and then access it directly in the req object.
By the way, in the nginx config you included, I think you need to use real_ip_header X-Forwarded-For; so that real_ip will use that header to locate the client IP, and you should also set real_ip_recursive on; so that it will ignore your trusted set_real_ip_from
Alright, so after a sleepless night and learning everything I could about the way STUD and HAProxy protocol works, I came to a simple conclusion it's simply not supported.
I knew I could easily go back to have SSL termination at Nginx, but I wanted to make sure that my deployment has automation as MUP.
Solution? MUPX. The next version of MUP, but still in development. It uses Docker and has SSL termination directly at Nginx.
So there you have it. Lesson? Stable is not always a solution. :)
In the following scenario,
[client]---https--->[Nginx]---http--->[app server]
How (and what) would I pass down to the app server to uniquely identify the certificate? That is, Nginx validates the certificate, but app server doesn't see it. I need to distinguish between users at the app server, so they can't impersonate each other.
You could adapt the same technique as what's described in this question for Apache Httpd. You'd need the Nginx equivalent of something like:
RequestHeader set X-ClientCert ""
RequestHeader set X-ClientCert "%{SSL_CLIENT_CERT}s"
I haven't tried, but the documentation for the Nginx SSL module has a section about "Embedded Variables". More specifically:
$ssl_client_cert returns the client certificate in the PEM format for an established SSL connection, with each line except the first prepended
with the tab character; this is intended for the use in the
proxy_set_header directive;
This looks like what you need with a reverse-proxy setting, like the one you have.
Note that it's very important to clear this header on its way in, otherwise clients could just set the headers themselves and use any certificate they like.
How you then want to check this in your application server depends on the platform you're using. In Java, for example, you could write a Filter (or a Tomcat Valve) that sets the parameter in the request from this custom HTTP header.
It sounds like you want to use Nginx for SSL termination, but you want the backend servers to be able to tell with the original request was over HTTPS or HTTP.
I think something this could work:
server {
ssl on;
listen 443;
add_header X-Forwarded-Proto https;
proxy_pass ...
}
# If you need insecure requests as well
server {
listen 80;
add_header X-Forwarded-Proto http;
proxy_pass ...
}
Then your app server can check the value of the X-Forwarded-Proto header.
This is the same design pattern that Amazon Web Services uses for terminating SSL at their Elastic Load Balancers. They also set the X-Forwarded-Proto header for backend servers to check.