We are using NGINX on our cPanel server to reverse proxy ZKTeco ZKBioSecurity servers. Due to compatibility with some of their devices not supporting HTTPS, all our servers use HTTP, but, of course, all sessions to our NGINX server is secured with HTTPS and a Sectigo certificate provided by cPanel’s AutoSSL.
Here’s the problem: it seems that the ZKBioSecurity servers are detecting that the client is using HTTPS to connect to them through NGINX, and because of this, give the following prompt each time you want to log in, advising you to download and install the ISSOnline driver and certificate. The certificate, however, is issued to the ZKBioSecurity server for 127.0.0.1, so of course this is rather pointless as we are connecting to the NGINX server using a FQDN. This does not happen if we use HTTP:
So my question: is there something in the request (the HTTP header perhaps?) that NGINX forwards to the upstream server that contains the protocol (HTTPS) the client used to connect to the server? Because this somehow seems to be the case.
Here’s our NGINX config for ZKBioSecurity servers:
location /.well-known {
root /home/novacloud/public_html/subdomain/.well-known;
allow all;
try_files $uri = 404;
}
location / {
if ($scheme = http) {
return 301 https://$host$request_uri;
}
proxy_pass http://192.168.0.1:8080;
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
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 $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
}
The server_name directive is, of course, managed by cPanel. The above is an example of the include files we use in the main cPanel NGINX configuration file. I thought it was the proxy_set_header X-Forwarded-Proto $scheme, but even if I remove this, I still get the Driver Detection Exception prompt.
Here’s a Pastebin of a cURL of the ZKBioSecurity server from our cPanel/NGINX server
Related
I have two servers running on a DigitalOcean droplet. One is a Django/Wagtail application served with Gunicorn (used as a headless CMS), and the other is a SSR Nuxt.js app (front-end). Using the following nginx configuration I’ve made the Nuxt app available at example.com (works great), and now I’m trying to make my Django/Wagtail application available at the subdomain cms.example.com. (I’ve modified my local hosts file so the domain example.com actually functions)
/etc/nginx/sites-available/default
server {
listen 80;
listen [::]:80;
server_name example.com;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
server {
listen 80;
listen [::]:80;
server_name cms.example.com;
location / {
include proxy_params;
proxy_pass http://unix:/home/thomas/daweb/cms/cms.sock;
}
}
/etc/nginx/proxy_params
proxy_set_header Host $http_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 $scheme;
Result from curl --unix-socket /home/thomas/daweb/cms/cms.sock cms.example.com is html of the default Wagtail landing page, no errors.
However navigating to cms.example.com just gives me a connection error. If I swap the two, I can see the Wagtail interface at example.com, so I know they’re both working. However, I can’t seem to figure out how to configure a subdomain and I struggle to understand the nginx documentation. Also similar questions about configuring subdomains are usually about making static files available, not listening to active ports.
One extra layer of trouble is that the Wagtail CMS is accessible at /admin of its server root, so I’d like to make that page appear at cms.example.com rather than having to navigate to cms.example.com/admin. Any help would be greatly appreciated!
Check what is contained in /etc/nginx/proxy_params. I would expect something like this:
proxy_set_header Host $http_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 $scheme;
Also, to be sure Gunicorn is working correctly, try:
curl --unix-socket /home/thomas/daweb/cms/cms.sock cms.example.com
AWS EC2 Ubuntu 18.04
Keycloak 5.0.0
Nginx 1.15.8
I am trying to place an application (not my development) based on the Wildfly with the Keycloak integration (openid-connect) and am aware of posts that relate to my task, but I believe my question has not been covered in those posts.
In my case everything works fine, an application and a keycloak server behind a Nginx reverse proxy. What I can't understand is that according to this Keycloak document it is necessary to make the following changes in the keycloak standalone.xml (in my case):
<http-listener name="default" socket-binding="http" proxy-address-forwarding="true" redirect-socket="proxy-https"/>
<socket-binding name="proxy-https" port="443"/>
If I understand it correctly, this setup assumes that an application sends an authentication request to http-listener and it is redirected to the proxy-https. It is not quite clear where the proxy is supposed to sent its proxy_pass.
But anyway, in my case, an application sends the authentication request the following way:
<realm>MyRealm</realm>
<resource>MyRealm</resource>
<public-client>true</public-client>
<auth-server-url>https://<host name>:8843/auth/</auth-server-url>
<ssl-required>external</ssl-required>
I have just changed https port in the Keycloak stanalone.xml to 8943 and assigned port 8843 to the Nginx server with the location /auth/, like in this fragment:
server {
listen 192.168.80.40:8843 ssl http2 default_server;
server_name <host name>;
location /auth/ {
proxy_http_version 1.1;
proxy_set_header Host $http_host;
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 $scheme;
proxy_set_header X-Forwarded-Port 8843;
add_header Strict-Transport-Security "max-age=15552000";
proxy_set_header X-NginX-Proxy true;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass https://192.168.80.40:8943/auth/;
proxy_redirect off;
}
}
It works, but I am not quite sure if it is the right way to place a Keycloak server behind the Nginx reverse proxy, considering the above mentioned Keycloak article. It is basically a question not about something that doesn't work but rather why it works.
If some Keycloak experts can assure me that my setup is workable, I would very appreciate it.
My second question:
Is it possible to restrict an external access only to the application realm, if users decide to open:
https://<host name>:<port>/auth
I would like to block any external access to the master realm login screen.
When I am using /auth/realms/MyRealm/ in the Nginx location, it does prevent users from accessing the master realm login screen, but it shows just some ugly login screen for the application realm, which actually works, but looks unprofessional.
Thanks in advance.
UPDATE:
The only solution for my second question I have found so far:
location /auth/realms/master/ {
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_http_version 1.1;
proxy_set_header Host $http_host;
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 $scheme;
proxy_set_header X-Forwarded-Port 8843;
add_header Strict-Transport-Security "max-age=15552000";
proxy_set_header X-NginX-Proxy true;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
add_header Pragma "no-cache";
proxy_pass https://192.168.80.40:8943/auth/realms/master/;
proxy_redirect off;
allow X.X.X.X;
deny all;
}
And similar for the root location:
location / {
*
*
*
proxy_pass https://192.168.80.40:8943$request_uri;
proxy_redirect off;
allow X.X.X.X;
deny all;
}
The location /auth/ is not changed.
https://<host name>:<port>/auth still opens "Welcome to Keycloak" screen but access to the "Administration Console" is forbidden. At least, I have now a normal login screen for the application realm and rogue Internet people are going to nowhere from that Welcome screen.
I still need help with my first question.
I am trying to route requests such that those requiring websockets will route to a long-lived nginx process, and all others will go to the general reverse-proxy which handles all other traffic. These nginx processes exist in our AWS cloud behind an ELB that has been configured to use Proxy Protocol. Note that all of this works correctly with our current setup which uses only one nginx process that is configured to use proxy_protocol.
The change to this setup is as follows:
The first nginx server handling all ingress uses proxy_protocol and forwards requests to either the websocket or non-websocket nginx servers locally:
server {
listen 8080 proxy_protocol;
real_ip_header proxy_protocol;
charset utf-8;
client_max_body_size 20M;
#send to websocket process
location /client {
proxy_pass http://localhost:8084;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $proxy_protocol_addr;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Proxy-Scheme $scheme;
proxy_set_header X-Proxy-Port $proxy_port;
proxy_set_header X-ELB-Proxy-Scheme "https";
proxy_set_header X-ELB-Proxy-Port "443";
# Always support web socket connection upgrades
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
#send to non-websocket process
location / {
proxy_pass http://localhost:8082;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $proxy_protocol_addr;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Proxy-Scheme $scheme;
proxy_set_header X-Proxy-Port $proxy_port;
proxy_set_header X-ELB-Proxy-Scheme "https";
proxy_set_header X-ELB-Proxy-Port "443";
# Always support web socket connection upgrades
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
When any non-websocket request is sent to localhost:8082, I get an empty reply. If I remove proxy_protocol from the first server, I get a response as expected. Obviously, I need proxy_protocol to support the ingress from our ELB, so removing it is not an option. However, I would like to know what pieces I am missing to route traffic correctly -- and I would also like to know why proxying a request locally from a proxy_protocol enabled server to another nginx process (regardless of this second process using proxy_protocol or not) fails.
For reference, the basic configuration of this secondary nginx process is below:
upstream console {
server localhost:3000 max_fails=3 fail_timeout=60 weight=1;
}
server {
listen 8082;
client_max_body_size 20M;
location /console {
proxy_pass http://console
}
.
.
.
}
Turns out the non-websocket proxy block should not set the various proxy and upgrade headers:
location / {
proxy_pass http://localhost:8082;
proxy_set_header Host $host;
}
We have a situation where we need to serve the login page from server_A (NGINX), get the user authenticated from here and once authenticated route the request ta a page which resides in a different server i.e. Server_B. All subsequent requests will come to Server_A and it will first check the user and session validity and then route to Server_B. This way the session and security is maintained by server A and rest of the work is done by server B.
My question here is that can we acheive this from NGINX server ?
My question here is that can we acheive this from NGINX server ?
Yes, certainly.
How do you do that?
Taking for an example a modified Tomcat behind NGINX application config I have handy:
server {
listen 80;
server_name www.example.com;
location /{
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://servera.example.com:8080/app;
client_max_body_size 10M;
}
location /login{
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://serverb.example.com:8080/login;
client_max_body_size 10M;
}
}
This will both proxy requests to the TomCat server, and serve them like any HTTP server.
Same can be said for any application you may want to proxy to, just modify the proxy_pass line of the above config accordingly!
I am using phabricator by Docker image (https://hub.docker.com/r/hachque/phabricator/).
Because my phabricator server is in the LAN of a company, I cannot access it from the outside. I'm trying to use Ngnix as reverse proxy. I can access the login page, but when I try to login, following message was displayed:
Unhandled Exception ("AphrontMalformedRequestException") You are
trying to save some data to Phabricator, but the request your browser
made included an incorrect token. Reload the page and try again. You
may need to clear your cookies. This was a Web request. This request
had an invalid CSRF token.
Here is part of my Nginx reverse proxy configuration:
# phabricator proxy.
#
server {
listen 8080;
server_name 0.0.0.0;
location / {
proxy_pass http://193.177.1.238/;
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;
}
}
I'm not using the same image as you, but what i've installed PHP 7.1 with Nginx and the Phabricator sources on the Docker image, then the Nginx from docker listen to the 9000 port (in my case).
Then i run this image using the 8081:9000 port mapping, and the following VirtualHost config on the Nginx from the host machine:
upstream api_upstream {
server 0.0.0.0:8080;
}
server {
listen 80;
server_name phabricator.local.com;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
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 $scheme;
proxy_cache_bypass $http_upgrade;
proxy_pass http://api_upstream;
}
}
the phabricator.local.com host only works if you add this entry to the /etc/hosts file:
127.0.0.1 phabricator.local.com