What could be the misconfiguration in my api_gateway.conf file that is leading me to the error SSL_do_handshake() failed - node.js

I am getting this message in nginx (1.18) error.log file
*39 SSL_do_handshake() failed (SSL: error:1408F10B:SSL routines:ssl3_get_record:wrong version number) while SSL handshaking to upstream
I saw a lot of answers here, but none of them solve my problem.
I am trying to implement an api gateway. It should be the simplest thing in the world...
api_gateway.conf
include api_keys.conf;
server {
access_log /var/log/nginx/api_access.log; # Each API may also log to a
# separate file
auth_request /_validate_apikey;
root /var/www/api;
index index.html index.htm index.nginx-debian.html;
listen 443 ssl;
server_name api.example.com.br;
location /microservices/ {
proxy_pass https://127.0.0.1:10001/;
}
location /ms-email-sender/ {
proxy_pass https://127.0.0.1:10002/;
}
# Error responses
error_page 404 = #400; # Treat invalid paths as bad requests
proxy_intercept_errors on; # Do not send backend errors to client
include api_json_errors.conf; # API client-friendly JSON errors
default_type application/json; # If no content-type, assume JSON
# API key validation
location = /_validate_apikey {
internal;
if ($http_apikey = "") {
return 401; # Unauthorized
}
if ($api_client_name = "") {
return 403; # Forbidden
}
return 204; # OK (no content)
}
ssl_certificate /etc/letsencrypt/live/api.optimusdata.com.br/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/api.optimusdata.com.br/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
}
server {
if ($host = api.optimusdata.com.br) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name api.optimusdata.com.br;
listen 80;
return 404; # managed by Certbot
}
My services are written in node.js
I tried to put some directives under location block like
proxy_ssl_verify off;
I changed a lot of things the api_gateway.conf
I saw several tutorials in the web and all of them are quite look alike that one.

Related

receiving a 502 CORS error having used them in the server

I have two servers, running on the same virtual machines:
https:xxx.domain1.com (the front-end)
https:yyy.domain1.com (the back-end only called from the front-end)
Both are running under nginx and the run correctly on my development Ubuntu 20.04.1 machine.
Now I' moving them on AWS: I created a Linux machine the same OS, and transferred both the machines.
So now I have
https:xxx.domain2.com (the front-end)
https:yyy.domain2.com (the back-end only called from the front-end)
The second server will be always called only by the first one. It should be considered hidden.
I run them, but, when accessing the front-end for the login, I received the following errors:
OPTIONS https://xxx.domain2.com/login CORS Missing Allow Origin
Now, in the server https:yyy.domain2.com I always specified
const router = express();
router.use(cors())
and the full nginx config file is as follow
server {
server_name xxx.domain2.com;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:3000;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/xxx.domain2.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/xxx.domain2.com/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
}
server {
server_name yyy.domain2.com;
add_header Access-Control-Allow-Origin "xxx.domain2.com";
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:3001;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/xxx.domain2.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/xxx.domain2.com/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
}
server {
if ($host = xxx.domain2.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name xxx.domain2.com;
return 404; # managed by Certbot
}
server {
if ($host = yyy.domain2.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name yyy.domain2.com ;
return 404; # managed by Certbot
}
Please note that I added the line
add_header Access-Control-Allow-Origin "xxx.domain2.com";
that I don't have on my development server.
====================== FIRST ADDENDUM ==========================
This is the client offending piece of code: The error is in response to the const res = await axios.put(cfLogin, { 'cf': cf }); request below.
const handleSubmitCf = async (e) => {
e.preventDefault();
setSudo(false)
try {
const res = await axios.put(cfLogin, { 'cf': cf });
if (res.status === 200 || res.status === 201)
{
nextPhase();
setResponse(res.data.data1);
}
setErrore('');
}
catch (error) { setErrore(error.response.data); };
}

Nginx location /yyy redirected to root location

I have 2 locations in my nginx conf like so :
upstream server {
server 127.0.0.1:XXXX;
}
server {
listen 443 ssl;
server_name example.com;
ssl_certificate XXXX;
ssl_certificate_key XXXX;
location /yyy {
proxy_pass http://server/YYY/;
...
}
location / {
proxy_pass http://server/XXX/;
...
}
}
But it seems that https://example.com/yyy redirects to http://server/XXX/ instead of http://server/YYY/ as if nginx considered it as a subpath of mydomain.com and not a different location.
However if I try to access https://example.com/yyy/ then it redirects to http://server/YYY/.
I would like that both https://example.com/yyy/ and https://example.com/yyy redirect to http://server/YYY/

Nginx empty responses for an upstream, although the upstream is healthy

So I have a node.js express app, and the backend seems very healthy, but nginx returns the correct status code, but no response, response is always empty
this is my configuration for a 3x upstreams using 3 different subdomains over SSL
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
upstream frontend {
server web:80;
}
upstream api {
server backend:4000;
}
upstream manage {
server admin:5000;
}
server {
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
# root /var/www/html;
# Add index.php to the list if you are using PHP
# index index.html index.htm index.nginx-debian.html;
server_name example.com test.example.com api-test.example.com www.example.com manage-test.example.com; # managed by Certbot
# if ($subdomain = '') {
# return 301 https://www.example.com$request_uri;
# }
set $upstreamed "frontend";
if ($host = 'api-test.example.com') {
set $upstreamed "api";
}
if ($host = 'api-manage.example.com') {
set $upstreamed "manage";
}
location / {
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*' 'always';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, PATCH, DELETE, OPTIONS' 'always';
#
# Custom headers and headers various browsers *should* be OK with but aren't
#
add_header 'Access-Control-Allow-Headers' 'Authorization,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
#
# Tell client that this pre-flight info is valid for 20 days
#
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
if ($request_method = 'POST') {
add_header 'Access-Control-Allow-Origin' '*' 'always';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, PATCH, DELETE, OPTIONS' 'always';
add_header 'Access-Control-Allow-Headers' 'Authorization,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' 'always';
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' 'always';
}
if ($request_method = 'GET') {
add_header 'Access-Control-Allow-Origin' '*' 'always';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, PATCH, DELETE, OPTIONS' 'always';
add_header 'Access-Control-Allow-Headers' 'Authorization,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range' 'always';
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' 'always';
}
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect off;
proxy_buffering off;
proxy_pass http://$upstreamed;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/test.example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/test.example.com/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
}
server {
if ($host = manage.test.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = api-test.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = test.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = www.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = example.com) {
return 301 https://www.$host$request_uri;
} # managed by Certbot
listen 80 ;
listen [::]:80 ;
server_name example.com test.example.com api-test.example.com www.example.com manage-test.example.com;
return 404; # managed by Certbot
}

ERR_CONNECTION_TIMED_OUT when calling backend NodeJS server behind VPN

I just created a website in reactJS (create-react-app) with a login possibility.
I configured autosigned SSL certificates with letsencrypt, added some DNS entries for HSTS and everything that make my website properly traffic-encrypted. My website is running on port 3001 (front-end) and my nodeJs backend is up on port 3000.
Everything works fine, however when some people try to connect to my website behind some VPN (not all of them), they see the page of my app (front-end) but when they try to login (connection to back-end), they get an ERR_CONNECTION_TIMED_OUT.
I cannot reproduce the bug because I do not have such VPN (with my NordVPN its working ok). So I would like you to help me to discover where this problem stems from.
Here is my nginx config file:
# xxx.fr nginx config file
user xxx;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 1024;
use epoll;
}
http {
upstream frontends {
server xxx.fr:3001;
}
charset utf-8;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
keepalive_timeout 65;
proxy_read_timeout 200;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
gzip on;
gzip_min_length 1000;
gzip_proxied any;
gzip_types text/html text/css text/xml
application/x-javascript application/xml
application/atom+xml text-javascript;
proxy_next_upstream error;
#include /etc/nginx/sites-enabled/*;
server {
# default_server;
#listen [::]:80;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload ';
#add_header Content-Security-Policy "default-src 'self';";
server_name xxx.fr www.xxx.fr;
client_max_body_size 50M;
location ^~ /build/static {
root /home/xxx/x/public;
index index.html;
if ($query_string) {
expires max;
}
}
location = /favicon.ico {
rewrite (.*) /public/favicon.ico;
}
location = robots.txt {
rewrite (.*) /public/robots.txt;
}
location / {
proxy_pass_header Server;
#add_header Strict-Transport-Security "max-age=31536000; includeSubDomains, preload" always;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_redirect off;
proxy_set_header X-Scheme $scheme;
proxy_pass http://frontends;
proxy_ssl_name $host;
proxy_ssl_server_name on;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/xxx.fr/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/xxx.fr/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
}
server {
if ($host = www.xxx.fr) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = xxx.fr) {
return 301 https://$host$request_uri;
} # managed by Certbot
#listen 80;
server_name xxx.fr www.xxx.fr;
return 404; # managed by Certbot
}
}
And in my nodeJS server (back-end), I have the following header set:
app.use(function (req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Methods", "*");
res.header("Access-Control-Allow-Credentials", true);
// res.header("Access-Control-Allow-Credentials", "true");
res.header(
"Access-Control-Allow-Headers",
"Origin, X-Requested-With, Content-Type, Accept, Authorization"
);
next();
});
Can anyone tell me how to fix the ERR_CONNECTION_TIMED_OUT ?
Thank you so much

Nginx v1.14.2 -- too many redirects

In my limited experience with Nginx, I get too many redirects when I deploy many WEB projects on the one domain.
I want to use one 'location' to match multiple items.
File path: /mnt/vue/web and /mnt/vue/admin and /mnt/page/web
When I visit https://${domain}/page/single, it is wrong. It redirects to https://${domain}/page/single/index.html/index.html/index.html/...
When I visit https://${domain}/vue/web, it is ok.
I've tried multiple variations of this, but none of them seem to work. Any ideas? Thanks in advance.
Here is my Nginx conf:
server {
listen 443 http2;
server_name ${domain};
ssl on;
ssl_certificate /etc/nginx/conf.d/cert/web/web.pem;
ssl_certificate_key /etc/nginx/conf.d/cert/web/web.key;
ssl_session_timeout 5m;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
# wechat verify
root /mnt/wechat;
# for vue h5-wechat
location ~ /(.*)/web {
root /mnt;
try_files $uri $uri/ /$1/web/index.html =404;
}
# for vue admin-web
location ~ /(.*)/admin {
root /mnt;
try_files $uri $uri/ /$1/admin/index.html =404;
}
# for api
location ~ /(.*)/api/(.*)$ {
proxy_pass http://172.16.184.254:$1;
rewrite /(.*)/api/(.*)$ /$2 break;
}
# for single pages !!!!! Where the problem occurred.
location ~ /(.*)/single/ {
alias /mnt/$1/web/;
index index.html;
}
# for cache
location ~ /(css|img|js|fonts|image)/ {
add_header Cache-Control "public, max-age=300";
}
location /files {
rewrite /files/(.*)$ /$1 break;
proxy_pass https://172.16.92.152;
}
}
server {
listen 80;
server_name ${domain};
return 301 https://$server_name$request_uri;
#rewrite ^(.*)$ https://$host$1 permanent;
}
Using alias within a regular expression location block, you need to capture the entire URI. See this document for details.
For example:
location ~ ^/(.*)/single/(.*)$ {
alias /mnt/$1/web/$2;
index index.html;
}

Resources