I'm trying to create the following setup:
- paperless-ngx running in a docker-compose setup exposing a single port 8050 and configured for URL https://paperless.example.com
- nginx running on the same machine reverse-proxying SSL traffic from port 8060 to localhost:8050 adding certbot-supplied certificates for a subdomain paperless.example.com
nginx site conf:
server {
server_name paperless.example.com;
listen 8060 ssl; # ssl added after certbot successfully retrieved certs
location / {
proxy_pass http://localhost:8050;
}
#listen 443 ssl; # added by Certbot, removed by me
ssl_certificate /etc/letsencrypt/live/paperless.example.com/fullchain.pem; # managed by Cert>
ssl_certificate_key /etc/letsencrypt/live/paperless.example.com/privkey.pem; # managed by Ce>
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
- a home router forwarding port 8050 + 8060 (8050 to make certbot work) to the internet on a dynamic IP, but an available dyndns domain name like example.dyndns.net
- a VPS with an nginx as reverse proxy using SSL-pass-through with the stream{} module for port 4433 and
pass_through.conf included in nginx.conf:
stream {
upstream dyndns {
server example.dyndns.net:8060;
}
server {
listen 4433;
proxy_pass dyndns;
}
}
nginx site conf:
server {
server_name paperless.examples.com;
location / {
proxy_pass https://localhost:4433;
}
location /.well-known {
proxy_pass http://example.dyndns.net/.well-known;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
}
listen 80;
listen 443 ssl http2;
}
- the subdomain paperless.example.com pointing its A-record to the IP of the VPS
Current result: Visting paperless.example.com gives me a SSL_ERROR_BAD_CERT_DOMAIN because the cert I get is from a different subdomain on the same VPS.
The other subdomain is also a reverse-proxy, but without SSL-pass-through.
If I switch to http, I get working but unencrypted connection to the service.
nginx site conf of the other subdomain:
server {
server_name nextcloud.example.com;
location / {
proxy_set_header Host example.dyndns.net;
proxy_pass https://example.dyndns.net:443;
}
listen 443 ssl http2; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/nextcloud.example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/nextcloud.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 = nextcloud.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80 ;
server_name nextcloud.example.com;
return 404; # managed by Certbot
}
The questions:
How do I fix this mess? 1.1 Can I tell the docker-compose setup to use the ssl-certs directly, without using a local reverse-proxy? (But with certbot still working for renewal.) 1.2 Can my router ONLY forward the https port and still have certbot work for renewal? 1.3 Can I tell nginx to use the stream module for SSL-pass-through for a single subdomain without going through that extra port?
stream{}doesn't work in the site-confs andserver_nameshouldn't be in the nginx.conf. 1.4 How do I tell the VPS's nginx to hand-through the :443 https request to the inner nginx listening on port 8060 waiting with the correct certs? It seems not to work my way.How to understand this mess? 2.2 Why is http working? Port 8050 is nowhere mentioned on the VPS setup. 2.3 Why is the wrong cert delivered? Why would nginx send a cert although it is only mentioned with a different
server_name?
Remarks:
- Yes, I could use a ssh/openvpn/wireguard tunnel between the VPS and the local server making SSL-pass-through obsolete, but I'm not looking for that right now.
- Why do I need example.com if example.dyndns.net already works? Connecting to an dynamic IP-block is blocked in some environments.