I am using this configuration down for nginx, i am using it for sidecar in azure, following this link
I can't figure it out what to change in the configuration to automatically redirect from http://domain to https://domain
# nginx Configuration File
# https://wiki.nginx.org/Configuration
# Run as a less privileged user for security reasons.
user nginx;
worker_processes auto;
events {
worker_connections 1024;
}
pid /var/run/nginx.pid;
http {
#Redirect to https, using 307 instead of 301 to preserve post data
server {
listen [::]:443 ssl;
listen 443 ssl;
server_name localhost;
# Protect against the BEAST attack by not using SSLv3 at all. If you need to support older browsers (IE6) you may need to add
# SSLv3 to the list of protocols below.
ssl_protocols TLSv1.2;
# Ciphers set to best allow protection from Beast, while providing forwarding secrecy, as defined by Mozilla - https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;
ssl_prefer_server_ciphers on;
# Optimize TLS/SSL by caching session parameters for 10 minutes. This cuts down on the number of expensive TLS/SSL handshakes.
# The handshake is the most CPU-intensive operation, and by default it is re-negotiated on every new/parallel connection.
# By enabling a cache (of type "shared between all Nginx workers"), we tell the client to re-use the already negotiated state.
# Further optimization can be achieved by raising keepalive_timeout, but that shouldn't be done unless you serve primarily HTTPS.
ssl_session_cache shared:SSL:10m; # a 1mb cache can hold about 4000 sessions, so we can hold 40000 sessions
ssl_session_timeout 24h;
# Use a higher keepalive timeout to reduce the need for repeated handshakes
keepalive_timeout 300; # up from 75 secs default
# remember the certificate for a year and automatically connect to HTTPS
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains';
ssl_certificate /etc/nginx/ssl.crt;
ssl_certificate_key /etc/nginx/ssl.key;
location / {
proxy_pass http://localhost:80; # TODO: replace port if app listens on port other than 80
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
}
EDIT:
After the suggestion in the first answer it didn't worked, with the two blocks added it was like this:
# nginx Configuration File
# https://wiki.nginx.org/Configuration
# Run as a less privileged user for security reasons.
user nginx;
worker_processes auto;
events {
worker_connections 1024;
}
pid /var/run/nginx.pid;
http {
#Redirect to https, using 307 instead of 301 to preserve post data
server {
# catch HTTP requests for all valid HTTP `Host` header values
listen 80;
listen [::]:80;
server_name _; # list all your domain names here
# do redirection to HTTPS
return 301 https://$http_host$request_uri;
}
server {
# default server listening on port 80
# getting here means the HTTP `Host` header is missing or had an incorrect value
listen 80 default_server;
listen [::]:80 default_server;
# close the connection immediately
return 444;
}
server {
listen [::]:443 ssl;
listen 443 ssl;
server_name localhost;
# Protect against the BEAST attack by not using SSLv3 at all. If you need to support older browsers (IE6) you may need to add
# SSLv3 to the list of protocols below.
ssl_protocols TLSv1.2;
# Ciphers set to best allow protection from Beast, while providing forwarding secrecy, as defined by Mozilla - https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;
ssl_prefer_server_ciphers on;
# Optimize TLS/SSL by caching session parameters for 10 minutes. This cuts down on the number of expensive TLS/SSL handshakes.
# The handshake is the most CPU-intensive operation, and by default it is re-negotiated on every new/parallel connection.
# By enabling a cache (of type "shared between all Nginx workers"), we tell the client to re-use the already negotiated state.
# Further optimization can be achieved by raising keepalive_timeout, but that shouldn't be done unless you serve primarily HTTPS.
ssl_session_cache shared:SSL:10m; # a 1mb cache can hold about 4000 sessions, so we can hold 40000 sessions
ssl_session_timeout 24h;
# Use a higher keepalive timeout to reduce the need for repeated handshakes
keepalive_timeout 300; # up from 75 secs default
# remember the certificate for a year and automatically connect to HTTPS
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains';
ssl_certificate /etc/nginx/ssl.crt;
ssl_certificate_key /etc/nginx/ssl.key;
location / {
proxy_pass http://localhost:80; # TODO: replace port if app listens on port other than 80
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
}
I suggest to use two additional server blocks:
server {
# catch HTTP requests for all valid HTTP `Host` header values
listen 80;
listen [::]:80;
server_name domain www.domain; # list all your domain names here
# do redirection to HTTPS
return 301 https://$http_host$request_uri;
}
server {
# default server listening on port 80
# getting here means the HTTP `Host` header is missing or had an incorrect value
listen 80 default_server;
listen [::]:80 default_server;
# close the connection immediately
return 444;
}
Check this answer for additional details on this configuration.
Update
Checking the documentation link given by OP looks like the provided example uses nginx container listening on port 443 taking the TLS encryption job and proxying requests to some "Hello World" example container that listen on port 80. To do the HTTP to HTTPS redirection via the nginx container you can try to change the "Hello World" example container listening port to 8080 and made nginx proxying the incoming requests to that port instead of port 80. Try the following configuration:
nginx.conf
# nginx Configuration File
# https://wiki.nginx.org/Configuration
# Run as a less privileged user for security reasons.
user nginx;
worker_processes auto;
events {
worker_connections 1024;
}
pid /var/run/nginx.pid;
http {
#Redirect to https, using 307 instead of 301 to preserve post data
server {
# catch HTTP requests for all valid HTTP `Host` header values
listen 80;
listen [::]:80;
server_name _; # list all your domain names here
# do redirection to HTTPS
return 307 https://$http_host$request_uri;
}
server {
# default server listening on port 80
# getting here means the HTTP `Host` header is missing or had an incorrect value
listen 80 default_server;
listen [::]:80 default_server;
# close the connection immediately
return 444;
}
server {
listen [::]:443 ssl;
listen 443 ssl;
server_name localhost;
# Protect against the BEAST attack by not using SSLv3 at all. If you need to support older browsers (IE6) you may need to add
# SSLv3 to the list of protocols below.
ssl_protocols TLSv1.2;
# Ciphers set to best allow protection from Beast, while providing forwarding secrecy, as defined by Mozilla - https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;
ssl_prefer_server_ciphers on;
# Optimize TLS/SSL by caching session parameters for 10 minutes. This cuts down on the number of expensive TLS/SSL handshakes.
# The handshake is the most CPU-intensive operation, and by default it is re-negotiated on every new/parallel connection.
# By enabling a cache (of type "shared between all Nginx workers"), we tell the client to re-use the already negotiated state.
# Further optimization can be achieved by raising keepalive_timeout, but that shouldn't be done unless you serve primarily HTTPS.
ssl_session_cache shared:SSL:10m; # a 1mb cache can hold about 4000 sessions, so we can hold 40000 sessions
ssl_session_timeout 24h;
# Use a higher keepalive timeout to reduce the need for repeated handshakes
keepalive_timeout 300; # up from 75 secs default
# remember the certificate for a year and automatically connect to HTTPS
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains';
ssl_certificate /etc/nginx/ssl.crt;
ssl_certificate_key /etc/nginx/ssl.key;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
}
deploy-aci.yaml
api-version: 2019-12-01
location: westus
name: app-with-ssl
properties:
containers:
- name: nginx-with-ssl
properties:
image: nginx
ports:
- port: 80
protocol: TCP
- port: 443
protocol: TCP
resources:
requests:
cpu: 1.0
memoryInGB: 1.5
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx
- name: my-app
properties:
image: mcr.microsoft.com/azuredocs/aci-helloworld
ports:
- port: 8080
protocol: TCP
resources:
requests:
cpu: 1.0
memoryInGB: 1.5
volumes:
- secret:
ssl.crt: <Enter contents of base64-ssl.crt here>
ssl.key: <Enter contents of base64-ssl.key here>
nginx.conf: <Enter contents of base64-nginx.conf here>
name: nginx-config
ipAddress:
ports:
- port: 80
protocol: TCP
- port: 443
protocol: TCP
type: Public
osType: Linux
tags: null
type: Microsoft.ContainerInstance/containerGroups
Related
I have a nodejs app that functions as a webserver listening to port 5050
I've created certificates and configured NGINX which works for normal https calls to the standard port (https://x.x/)
If I make a call to port 5050 with a normal http://x.x:5050 call it also works, but with an https://x.x:5050/conf call I get: This site can’t provide a secure connection
Below the NGINX config file:
(The names of the website are changed)
server {
root /var/www/x.x/html;
index index.html index.htm index.nginx-debian.html;
server_name x.x www.x.x;
location / {
try_files $uri $uri/ =404;
}
location /conf {
proxy_pass http://localhost:5050;
try_files $uri $uri/ =404;
}
location /wh {
proxy_pass http://localhost:5050;
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;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/x.x/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/x.x/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
}
What am I doing wrong here?
You configured nginx to serve as a reverse proxy, forwarding incoming requests from https://example.com/whatever to http://localhost:5050/whatever. You said you did that correctly and it works. Good. (Getting that working is a notorious pain in the xxx neck.)
You did not configure nginx to listen on port 5050. Nor should you; that's the port it uses to pass along requests to your nodejs program. You cannot forward requests from port 5050 to port 5050. If you try to have nodejs and nginx both listen to port 5050, one of them will get an EADRINUSE error when you start your servers.
Your nodejs program listens for http requests, not https requests, on port 5050. You can't easily make it listen for both http and https on the same port. Your nodejs program, when behind nginx, should not contain any https server, only http. (You're making nginx do the hard crypto work to handle https, and letting nodejs handle your requests.)
Nor do you want your nodejs program to listen directly for http-only requests from outside your server. Because cybercreeps.
If you can block access to port 5050 from anywhere except localhost, you can declare victory on your task of configuring your server. You can do this by using
server.listen({
host: 'localhost',
port: 5050, ...
});```
in your nodejs program. Or you can configure your server's firewall to block incoming requests on any ports except https (and ssh, so you can manage it). Digital Ocean has a useful tutorial on this point.
First of all, I'd like to apologize for the long post!
I'm almost close to figuring everything out! What I want to do is to use node-http-proxy to mask a series of dynamic IPs that I get from a MySQL database. I do this by redirecting the subdomains to node-http-proxy and parsing it from there. I was able to do this locally without any problems.
Remotely, it's behind an Nginx web server with HTTPS enabled (I have a wildcard certificate issued through Let's Encrypt, and a Comodo SSL for the domain). I managed to configure it so it passed it to the node-http-proxy without problems. The only problem, is that the latter is giving me
The error is { Error: connect ECONNREFUSED 127.0.0.1:80
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1174:14)
errno: 'ECONNREFUSED',
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 80 }
Whenever I set:
proxy.web(req, res, { target, ws: true }
And I don't know if the problem is the remote address (highly unlikely since I'm able to connect through a secondary device), or I have misconfigured nginx (highly likely). There's also the possibility that it may be clashing with Nginx which is listening to port 80. But I don't know why node-http-proxy would connect through port 80
Some additional info:
There's a Ruby on Rails app running side-by-side as well.
Node-http-proxy, nginx, ruby on rails are running in each own Docker container. I don't think it's a problem from Docker, since I was able to locally test this without any problems.
Here's my current nginx.conf (I have replaced my domain name for example.com, for security reasons)
The server_name "~^\d+\.example\.co$"; is where I want it to redirect to node-http-proxy, whereas example.com is where a Ruby on Rails application lies.
# https://codepany.com/blog/rails-5-and-docker-puma-nginx/
# This is the port the app is currently exposing.
# Please, check this: https://gist.github.com/bradmontgomery/6487319#gistcomment-1559180
upstream puma_example_docker_app {
server app:5000;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
# Enable once you solve wildcard subdomain issue.
return 301 https://$host$request_uri;
}
server {
server_name "~^\d+\.example\.co$";
# listen 80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
# Created by Certbot
ssl_certificate /etc/letsencrypt/live/example.co/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.co/privkey.pem;
# include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
# ssl_certificate /etc/ssl/certs/ssl-bundle.crt;
# ssl_certificate_key /etc/ssl/private/example.co.key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
# This is generated by ourselves.
# ssl_dhparam /etc/ssl/certs/dhparam.pem;
# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /etc/ssl/certs/trusted.crt;
location / {
# https://www.digitalocean.com/community/questions/error-too-many-redirect-on-nginx
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://ipmask_docker_app;
# limit_req zone=one;
access_log /var/www/example/log/nginx.access.log;
error_log /var/www/example/log/nginx.error.log;
}
}
# SSL configuration was obtained through Mozilla's
# https://mozilla.github.io/server-side-tls/ssl-config-generator/
server {
server_name localhost example.co www.example.co; #puma_example_docker_app;
# listen 80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
# Created by Certbot
# ssl_certificate /etc/letsencrypt/live/example.co/fullchain.pem;
#ssl_certificate_key /etc/letsencrypt/live/example.co/privkey.pem;
# include /etc/letsencrypt/options-ssl-nginx.conf;
# ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /etc/ssl/certs/ssl-bundle.crt;
ssl_certificate_key /etc/ssl/private/example.co.key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
# This is generated by ourselves.
ssl_dhparam /etc/ssl/certs/dhparam.pem;
# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /etc/ssl/certs/trusted.crt;
# resolver 127.0.0.1;
# https://support.comodo.com/index.php?/Knowledgebase/Article/View/1091/37/certificate-installation--nginx
# The above was generated through Mozilla's SSL Config Generator
# https://mozilla.github.io/server-side-tls/ssl-config-generator/
# This is important for Rails to accept the headers, otherwise it won't work:
# AKA. => HTTP_AUTHORIZATION_HEADER Will not work!
underscores_in_headers on;
client_max_body_size 4G;
keepalive_timeout 10;
error_page 500 502 504 /500.html;
error_page 503 #503;
root /var/www/example/public;
try_files $uri/index.html $uri #puma_example_docker_app;
# This is a new configuration and needs to be tested.
# Final slashes are critical
# https://stackoverflow.com/a/47658830/1057052
location /kibana/ {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
#rewrite ^/kibanalogs/(.*)$ /$1 break;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://kibana:5601/;
}
location #puma_example_docker_app {
# https://www.digitalocean.com/community/questions/error-too-many-redirect-on-nginx
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://puma_example_docker_app;
# limit_req zone=one;
access_log /var/www/example/log/nginx.access.log;
error_log /var/www/example/log/nginx.error.log;
}
location ~ ^/(assets|images|javascripts|stylesheets)/ {
try_files $uri #rails;
access_log off;
gzip_static on;
# to serve pre-gzipped version
expires max;
add_header Cache-Control public;
add_header Last-Modified "";
add_header ETag "";
break;
}
location = /50x.html {
root html;
}
location = /404.html {
root html;
}
location #503 {
error_page 405 = /system/maintenance.html;
if (-f $document_root/system/maintenance.html) {
rewrite ^(.*)$ /system/maintenance.html break;
}
rewrite ^(.*)$ /503.html break;
}
if ($request_method !~ ^(GET|HEAD|PUT|PATCH|POST|DELETE|OPTIONS)$ ){
return 405;
}
if (-f $document_root/system/maintenance.html) {
return 503;
}
location ~ \.(php|html)$ {
return 405;
}
}
Current docker-compose file:
# This is a docker compose file that will pull from the private
# repo and will use all the images.
# This will be an equivalent for production.
version: '3.2'
services:
# No need for the database in production, since it will be connecting to one
# Use this while you solve Database problems
app:
image: myrepo/rails:latest
restart: always
environment:
RAILS_ENV: production
# What this is going to do is that all the logging is going to be printed into the console.
# Use this with caution as it can become very verbose and hard to read.
# This can then be read by using docker-compose logs app.
RAILS_LOG_TO_STDOUT: 'true'
# RAILS_SERVE_STATIC_FILES: 'true'
# The first command, the remove part, what it does is that it eliminates a file that
# tells rails and puma that an instance is running. This was causing issues,
# https://github.com/docker/compose/issues/1393
command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -e production -p 5000 -b '0.0.0.0'"
# volumes:
# - /var/www/cprint
ports:
- "5000:5000"
expose:
- "5000"
networks:
- elk
links:
- logstash
# Uses Nginx as a web server (Access everything through http://localhost)
# https://stackoverflow.com/questions/30652299/having-docker-access-external-files
#
web:
image: myrepo/nginx:latest
depends_on:
- elasticsearch
- kibana
- app
- ipmask
restart: always
volumes:
# https://stackoverflow.com/a/48800695/1057052
# - "/etc/ssl/:/etc/ssl/"
- type: bind
source: /etc/ssl/certs
target: /etc/ssl/certs
- type: bind
source: /etc/ssl/private/
target: /etc/ssl/private
- type: bind
source: /etc/nginx/.htpasswd
target: /etc/nginx/.htpasswd
- type: bind
source: /etc/letsencrypt/
target: /etc/letsencrypt/
ports:
- "80:80"
- "443:443"
networks:
- elk
- nginx
links:
- elasticsearch
- kibana
# Defining the ELK Stack!
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:6.2.3
container_name: elasticsearch
networks:
- elk
environment:
- cluster.name=docker-cluster
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- elasticsearch:/usr/share/elasticsearch/data
# - ./elk/elasticsearch/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml
ports:
- 9200:9200
logstash:
image: docker.elastic.co/logstash/logstash:6.2.3
container_name: logstash
volumes:
- ./elk/logstash/config/logstash.yml:/usr/share/logstash/config/logstash.yml
# This is the most important part of the configuration
# This will allow Rails to connect to it.
# See application.rb for the configuration!
- ./elk/logstash/pipeline/logstash.conf:/etc/logstash/conf.d/logstash.conf
command: logstash -f /etc/logstash/conf.d/logstash.conf
ports:
- "5228:5228"
environment:
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
networks:
- elk
links:
- elasticsearch
depends_on:
- elasticsearch
kibana:
image: docker.elastic.co/kibana/kibana:6.2.3
volumes:
- ./elk/kibana/config/kibana.yml:/usr/share/kibana/config/kibana.yml
ports:
- "5601:5601"
networks:
- elk
links:
- elasticsearch
depends_on:
- elasticsearch
ipmask:
image: myrepo/proxy:latest
command: "npm start"
restart: always
environment:
- "NODE_ENV=production"
expose:
- "5050"
ports:
- "4430:80"
links:
- app
networks:
- nginx
# # Volumes are the recommended storage mechanism of Docker.
volumes:
elasticsearch:
driver: local
rails:
driver: local
networks:
elk:
driver: bridge
nginx:
driver: bridge
Thank you very much!
Waaaaaaitttt. There was no problem with the code!
The problem was that I was trying to pass a bland IP address without appending http before it! By appending HTTP everything is working!!
Example:
I was doing:
proxy.web(req, res, { target: '128.29.41.1', ws: true })
When in fact this was the answer:
proxy.web(req, res, { target: 'http://128.29.41.1', ws: true })
I'm very new to Nginx and I'm feeling like a monkey trapped inside a nuclear power plant facility — nothing makes any sense — and I desperately want to get some bananas.
Anyway, I'm using Nginx server for handling SSL and proxying all requests to the NodeJS app. Everything works just fine except for WebSockets. The client gives me an ERR_INSECURE_RESPONSE error. The server is live. What am I missing? What would you advice?
NodeJS
const express = require('express')
const app = express()
const server = require('http').Server(app)
const io = require('socket.io')(server)
app.use(express.static('../app'))
io.on('connection', (socket) => {
console.log('CONNECTED')
})
server.listen(5000)
Nginx config (taken from this tutorial Deploying a NodeJS app with ssl)
# HTTP — redirect all traffic to HTTPS
server {
listen 80;
listen [::]:80 default_server ipv6only=on;
return 301 https://$host$request_uri;
}
# HTTPS — proxy all requests to the Node app
server {
# Enable HTTP/2
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name olmeo.us;
# Use the Let’s Encrypt certificates
ssl_certificate /etc/letsencrypt/live/olmeo.us/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/olmeo.us/privkey.pem;
# Include the SSL configuration from cipherli.st
include snippets/ssl-params.conf;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://localhost:5000/;
proxy_ssl_session_reuse off;
proxy_set_header Host $http_host;
proxy_cache_bypass $http_upgrade;
proxy_redirect off;
}
}
SSL config (include snippets/ssl-params.conf)
# See https://cipherli.st/ for details on this configuration
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
# Add our strong Diffie-Hellman group
ssl_dhparam /etc/ssl/certs/dhparam.pem;
Client
io.connect('https://52.29.55.217')
Your SSL certificate is likely provided for a given domain, not for the IP address and you are using the IP and not a domain to connect:
io.connect('https://52.29.55.217')
Unless your certificate includes that IP address in the list of hosts that it covers (highly unlikely) then this will not work. Try it with the exact domain name that was used while creating the certificate with Let's Encrypt (not a subdomain, not an IP, the exact domain name).
I have been trying for a long time to set up a reverse proxy with nginx that works with both nodejs over ssl on port 3000 and apache over ssl on port 443. I have tried so many things that my conf files probably have tons of errors. My most recent attempt had this as the /etc/apache2/sites-enabled/000-default.conf:
<VirtualHost *:443>
# The ServerName directive sets the request scheme, hostname and port t$
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerAdmin admin#test.com
DocumentRoot /var/www/html/public
SSLEngine on
SSLCertificateFile /var/www/certs/test_com.crt
SSLCertificateKeyFile /var/www/certs/test_com.key
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
And my nginx configuration looks like this:
server {
listen 80;
access_log /var/log/nginx/secure.log;
error_log /var/log/nginx/secure.error.log;
server_name test.com;
ssl on;
ssl_certificate /var/www/certs/test_com.crt;
ssl_certificate_key /var/www/certs/test_com.key;
location / {
proxy_pass https://127.0.0.1:3000;
}
location /public {
proxy_pass https://127.0.0.1:443;
root /var/www/html/public; //this is where I keep all the html files
}
}
When I run netstat -tulpn I get:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::3000 :::* LISTEN -
udp 0 0 0.0.0.0:68 0.0.0.0:*
This is my first time setting up a server like this so I would really appreciate it if someone could explain how reverse proxies are supposed to work with a nodejs server that uses webpages from an apache instance over ssl.
I'm not sure how this works, but if I had to guess logically, I would want an nginx instance listening on port 80 that redirects all http traffic to https traffic. I would want apache configured on port 443 so I would be able to browse to my css stylesheet https://test.com/assets/css/stylesheet.css and be able to use that as a path in my node server.
I found this in my searches but was unable to correctly implement it:https://www.digitalocean.com/community/questions/how-to-setup-ssl-for-nginx-and-apache
I know I'm not explaining it very well, but I hope someone is able to understand what I need and help me out. Thanks!
Yes this sounds confusing. It is very common to have static assets served directly from nginx, then reverse proxy all other requests to some backend (node on 3000).
I am very confused by the need for Apache.
If you really need Apache this is how you can do it.
First, you said you want nginx to listen on port 80 and just redirect all http traffic to https, configure your nginx like this.
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
Thats it for nginx.
Now for Apache, you need mod_proxy, it will listen on 443 and handle TLS termination, then proxy requests to node listening on 3000
<VirtualHost *:*>
# your config here...
ProxyPreserveHost On
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
</VirtualHost>
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
I'm not sure why you want to do it this way, if you can, I'd suggest only using nginx to listen on 80, redirect to 443, handle TLS termination, serve static assets, and reverse proxy to your backend. It's much simpler to set up.
example
untested nginx config
# replace 'domain.com' with your domain name
# http server, redirects to https
server {
listen 80;
listen [::]:80;
server_name example.com;
return 301 https://example.com$request_uri;
}
# https server
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com;
ssl on;
# replace this with your cert+key path
ssl_certificate /etc/ssl/private/YOUR_CERT.crt;
ssl_certificate_key /etc/ssl/private/YOUR_SERVER_KEY.key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:20m;
ssl_session_tickets off;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_stapling on;
ssl_stapling_verify on;
# replace 'node-app' with your app name
access_log /var/log/nginx/node-app.access.log;
error_log /var/log/nginx/node-app.error.log;
location / {
# the path to your static assets
root /var/www/your-app/public;
try_files $uri $uri/ #nodebackend;
}
# all requests to locations not found in static path
# will be forwarded to the node server
location #nodebackend {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://localhost:3000;
proxy_redirect off;
}
}
I am developing a MEAN project with angular 4.1.0.
On my localhost, everything works without errors. When I deploy to the server however, retrieving a user with more than 8 question-answer pairs causes a net::ERR_CONNECTION_CLOSED error on the xhr request that angular's http module fires.
The digital ocean droplet I am hosting on uses an nginx reverse proxy and uses a letsencrypt SSL certificate.
I have tried:
Restarting server, nginx service, node.js etc.
Increasing client_max_body_size to 20M in the nginx config file
Increasing large_client_header_buffers' size to 128k in the nginx config file
Other important facts:
The GET request to qapairs?jwt=ey.. never reaches the node.js app
There is no mention of the request in /var/log/nginx/error.log
The failing requests shown in the /var/log/nginx/access.log are as follows:
89.15.159.19 - - [08/May/2017:14:25:53 +0000] "-" 400 0 "-" "-"
89.15.159.19 - - [08/May/2017:14:25:53 +0000] "-" 400 0 "-" "-"
Please point me in possible directions.
The chrome dev tool network tab screenshots
After logging in to an account where there are only 7 question answer pairs
Then, after going to mlab.com and manually adding another question answer pair to same account and then refreshing the page (notice the number of questions in now 8)
Finally, after logging in and out of the same account (notice the xhr request to qapairs?jwt=ey... returned a failed status)
/etc/nginx/sites-enabled/default
# HTTP — redirect all traffic to HTTPS
server {
listen 80;
listen [::]:80 default_server ipv6only=on;
return 301 https://$host$request_uri;
}
# etc
# HTTPS ^ ^ proxy all requests to the Node app
server {
# Enable HTTP/2
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name subdomain.example.com;
# Use the Let ^ ^ s Encrypt certificates
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Include the SSL configuration from cipherli.st
include snippets/ssl-params.conf;
# Increase allowed URL length
large_client_header_buffers 4 128k;
# Increase max body size
client_max_body_size 20M;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://subdomain.example.com:3001/;
proxy_ssl_session_reuse off;
proxy_set_header Host $http_host;
proxy_cache_bypass $http_upgrade;
proxy_redirect off;
}
}
qa-pairs.service.ts
The error is being caught here in the getQAPairs function. Being passed to the callback in the catch function a ProgressEvent object with a type property of
error, eventPhase of 2.
#Injectable()
export class QaPairsService {
/* etc */
getQAPairs () {
const jwt = localStorage.getItem('jwt') ? `?jwt=${localStorage.getItem('jwt')}` : ''
return this.http.get(this.qapairsUrl + jwt)
.map(response => {
this.qapairs = response.json().map((qapair: IQAPair) => new QAPair(qapair))
this.qapairsChanged.emit(this.qapairs)
return this.qapairs
})
.catch(
(error: any) => {
error = error.json()
this.errorsService.handleError(error)
return Observable.throw(error)
}
)
}
/* etc */
}
Solution:
/etc/nginx/sites-enabled/default
# other code here
server {
# other code here
# Increase http2 max sizes
http2_max_field_size 64k;
http2_max_header_size 64k;
}
The reason I found this so hard to debug was because there was
no mention of the request in /var/log/nginx/error.log
and I didn't realize that nginx has the ability to be more verbose with its logging (duh)
So after changing /etc/nginx/sites-enabled/default to include
server {
error_log /var/log/nginx/error.log info;
}
I saw
2017/05/08 16:17:04 [info] 3037#3037: *9 client exceeded http2_max_field_size limit while processing HTTP/2 connection, client: 89.15.159.19, server: 0.0.0.0:443
which was the error message I needed.
This helped me!!! Unfortunately there were no error messages.
It helps me:
client_header_buffer_size 1k; large_client_header_buffers 4 4k;