I'm trying to set up a Debian 11 server with wikijs. As a webserver I use Nginx with a Let's Encrypt ssl certificate. The ssl certificate was created using certbot.
The site should be available under it's internal ip at port 7443 as well as https://wiki.url.com:7443
Wikijs config.yml:
port: 3000
db:
type: postgres
host: localhost
port: 5432
user: someuser
pass: somepassword
db: somedb
ssl: false
sslOptions:
auto: true
schema: public
ssl:
enabled: true
port: 7443
provider: custom
format: pem
key: /etc/letsencrypt/live/wiki.url.com/privkey.pem
cert: /etc/letsencrypt/live/wiki.url.com/fullchain.pem
passphrase: null
dhparam: /etc/letsencrypt/ssl-dhparams.pem
Node.js config file:
server {
server_name wiki.url.com;
# security
# security headers
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header Content-Security-Policy "default-src 'self' http: https: ws: wss: data: blob: 'unsafe-inline'; frame-ancestors 'self';" always;
add_header Permissions-Policy "interest-cohort=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# . files
location ~ /\.(?!well-known) {
deny all;
}
# reverse proxy
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
# Proxy headers
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;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/wiki.url.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/wiki.url.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 = wiki.url.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name wiki.url.com;
return 404; # managed by Certbot
The weird thing is that it has worked before on port 80 without any problems, until we installed the certificate using certbot. This tutorial was used after multiple failed attempts: https://www.vultr.com/docs/how-to-install-wiki-js-on-debian-11
Related
If I disable cloudflare everything works fine...however I'm not allowed to do that by tech advisors.
Here is my nginx config:
server {
server_name api.example.com;
#index index.html;
#root /home/ubuntu/www/example.com/Catalyze-ui/build;
add_header 'Cache-Control' 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
add_header 'Last-Modified' '';
if_modified_since off;
expires -1;
etag off;
listen [::]:443 ssl http2; #managed by Certbot
listen 443 ssl http2; #managed by Certbot
ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem; #managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/api.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
# ssl_protocols TLSv1.2;
#try_files $uri $uri/ /index.html;
client_max_body_size 10M;
location /api {
proxy_pass http://localhost:8080/api;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
I get a 404 when I hit api.example.com/api/1 which should give me a json object. If I hit http://localhost:8080/api/1 on the server I get the expected json response so its not a node issue.
How do I get this to work with cloudflare dns proxy?
My sites are
https://www.example.com
https://example.com
If I used https://example.com and login using google oauth2, after redirect back to https://www.example.com my cookies doesn't persists, it's restarted so I'm not able to login. If I use https://www.example.com and redirect back to same https://www.example.com, works fine. I'm not sure if it should be working fine since it is both same domain only doesn't have www. I'm using NGINX ssl certbot, currently my alternative plan is to make my redirect URI dynamic if I can't find solution.
map $sent_http_content_type $expires {
"text/html" epoch;
"text/html; charset=utf-8" epoch;
default off;
}
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
gzip on;
gzip_types text/plain application/xml text/css application/javascript;
gzip_min_length 1000;
location / {
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-Auth-Request-Redirect "https://www.example.com";
proxy_cache_bypass $http_upgrade;
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
#proxy_cookie_path / "/; SameSite=lax; HTTPOnly; Secure";
}
#location /api {
# proxy_pass http://127.0.0.1:3333;
# proxy_cookie_path / "/; SameSite=none; HTTPOnly; Secure";
#}
location /adonis-ws {
proxy_pass http://127.0.0.1:3333;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
proxy_connect_timeout 2592000;
proxy_send_timeout 2592000;
proxy_read_timeout 2592000;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/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 = www.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name example.com www.example.com 123.123.123;
return 404; # managed by Certbot
}
Update
My cookies doesn't share between www and non-www. I decided to force redirect my website to www instead since its working if same origin domain.
It's not something related to NGINX. It is related to browser's way how it deals with cookies. You should have your cookies scoped to parent domain(example.com) and not to subdomain(www.example.com)
i have a nodejs sails app proxied by nginx.Everything works fine but cant seem to connect to sails.io websocket.I get the error below in browser
Refused to connect to 'wss://youtmail.tk/socket.io/?__sails_io_sdk_version=1.2.1&__sails_io_sdk_platform=browser&__sails_io_sdk_language=javascript&EIO=3&transport=websocket' because it violates the following Content Security Policy directive: "default-src https: data: 'unsafe-inline' 'unsafe-eval'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback.
and here is my nginx conf
server {
server_name youtmail.tk;
location /{
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;
proxy_pass http://localhost:1338;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/youtmail.tk-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/youtmail.tk-0001/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 = youtmail.tk) {
return 301 https://$host$request_uri;
} # managed by Certbot
}listen 80;
server_name youtmail.tk;
return 404; # managed by Certbot
}
any help on how to solve this??
I'm trying to setup a node server for wiki.js with a NGINX reverse proxy. I followed the wiki.js installation instructions and have the files extracted into /var/www/site/main/wiki so the file structure looks as follows:
var
- www
- site
- main
- wiki
-assets
-config.yml
-LICENSE
-node_modules
-package.json
-server
I can run the node server command in that directory and it instructed me to continue the setup by going to http://localhost:3000. I then tried to visit the site by it's domain, and the page title is being set to wiki.js Setup so something is passing through the Nginx proxy, but all css/js files are returning a 404 error causing the page to fail to render.
I used a setup from https://nginxconfig.io to configure the Nginx proxy, and the server block is as follows:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com;
# SSL
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
# security
include nginxconfig.io/security.conf;
# reverse proxy
location / {
proxy_pass http://127.0.0.1:3000;
# This next block is actually include with a include
# nginxconfig.io/proxy.conf call but this is the contents of that file
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;
}
# additional config
include nginxconfig.io/general.conf;
}
# subdomains redirect
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name *.example.com;
# SSL
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
return 301 https://example.com$request_uri;
}
# HTTP redirect
server {
listen 80;
listen [::]:80;
server_name .example.com;
include nginxconfig.io/letsencrypt.conf;
location / {
return 301 https://example.com$request_uri;
}
}
I just ran into this issue myself. After poking and prodding, I found there are multiple issues with the nginxconfig.io setup; it seems to want to configure too many things and this gets in the way of wiki.js actually being able to do its own thing.
Content-Security-Policy needs to be unset
Removed all includes in an effort to debug faster
As of right now (2020-05-16_14-11) these are valid working server blocks:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name wiki.domain.invalid;
# SSL
ssl_certificate /etc/letsencrypt/live/wiki.domain.invalid/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/wiki.domain.invalid/privkey.pem; #managed by Certbot
ssl_trusted_certificate /etc/letsencrypt/live/wiki.domain.invalid/chain.pem;
# security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
#add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
add_header Strict-Transport-Security "max-age=0" always;
# . files
location ~ /\.(?!well-known) {
deny all;
}
# logging
access_log /var/log/nginx/wiki.domain.invalid.access.log;
error_log /var/log/nginx/wiki.domain.invalid.error.log warn;
# reverse proxy
location / {
proxy_pass http://127.0.0.1:3000;
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 $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;
#proxy_set_header X-Forwarded-Host $host;
#proxy_set_header X-Forwarded-Port $server_port;
proxy_next_upstream error timeout http_502 http_503 http_504;
}
# gzip
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml application/json application/javascript application/rss+xml application/atom+xml image/svg+xml;
}
# HTTP redirect
server {
listen 80;
listen [::]:80;
server_name wiki.domain.invalid;
# ACME-challenge
location ^~ /.well-known/acme-challenge/ {
root /var/www/_letsencrypt;
}
location / {
return 301 https://wiki.domain.invalid$request_uri;
}
}
I am cross posting this from Serverfault because it seems the Sails team monitors Stackoverflow.
I just started venturing in NGINX and SSL.
Using Ubuntu 16.04.
I am running a Sails server on the standard 1337 port and just set up NGINX with SSL (using letsencrypt). Port 80 is redirected to 443 and upstream goes to Sails.
I also have a Tomcat server listening on 8080 and use NGINX to redirect the same way.
Everything works fine: I can browse both servers on https without special ports on browser.
I have set up socket.io to use websockets protocol only (no polling). This is set on the server and on the browser client.
However, socket.io (sails.io) throws a 502 error no the browser. (polling gave an error too)
Here is my NGINX sites-available for the Sails server:
upstream sails {
server 127.0.0.1:1337 fail_timeout=0;
}
server {
listen 80;
listen [::]:80;
server_name mysails.server.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443;
listen [::]:443 ssl http2;
server_name mysails.server.com;
include snippets/ssl-mysails.server.conf;
include snippers/ssl-params.conf;
large_client_header_buffers 8 32k;
location / {
proxy_pass http://sails/;
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header Port $server_port;
proxy_set_header X-Real-IP $remot_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass_request_headers on;
}
location /socket.io/ {
proxy_pass http://sails/;
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header Port $server_port;
proxy_set_header X-Real-IP $remot_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
proxy_pass_request_headers on;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffers 8 32k;
proxy_buffer_size 64k;
}
}
The snippets/ssl-mysails.server.conf and snippers/ssl-params.conf files contain:
ssl_certificate /path/to/letsencrypt/fullchain.pem;
ssl_certificate_key /path/to/letsencrypt/privkey.pem;
and
# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
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;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable preloading HSTS for now. You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
Anyone has any clue on what's going on...?
** UPDATE **
I have added a lot of information about logs and behaviours on the Serverfault question
https://serverfault.com/questions/829100/socket-io-with-sails-js-node-js-and-nginx-on-ssl-bad-gateway
So the issue is a bad configuration on the NGINX sites-avalable conf file.
location /socket.io/ {
proxy_pass http://sails/;
...
}
should be
location /socket.io/ {
proxy_pass http://sails/socket.io/;
...
}
Pretty basic stuff: the "location" is not forwarded to the proxy_pass (why would it be, right?) -- So you need to make sure the socket requests are redirected to the exact socket endpoint.