Closed liftoff-sr closed 1 year ago
Hi @liftoff-sr Mine looks like this. I wouldn't mess around with the paths, can't you just assign a complete subdomain to the mailserver's web services?
server {
server_name mail.example.com;
listen 443 ssl http2 ;
access_log /var/log/nginx/access.log vhost;
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_certificate /etc/nginx/certs/mail.example.com.crt;
ssl_certificate_key /etc/nginx/certs/mail.example.com.key;
ssl_dhparam /etc/nginx/certs/mail.example.com.dhparam.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/certs/mail.example.com.chain.pem;
add_header Strict-Transport-Security "max-age=31536000" always;
include /etc/nginx/vhost.d/default;
location / {
proxy_pass http://mail.example.com:81
}
}
Thank you Jeffry. This suggestion is a very good solution.
Is your feature request related to a problem? Please describe. Do not want to have unencrypted port 81 open on a public IP.
Describe the solution you'd like Use nginx to reverse proxy from https into http at the containers.
Describe alternatives you've considered I have implemented a working config file for nginx for 2 of the 3 services running at port 81. That is, RSPAMD and WEBMAIL are working ok with https out front and port 81 http behind the proxy. However the "admin" service is tricky and is conflicting with a standard HTTPS site that I have on that same box. This is because not every single $request_uri for the admin interface has a matchable pattern. Most of the URIs in the interfave are fine, but there is a tricky case right after providing the password where there is no crudAction in the URI.
It would be nice to have a fix for this so we can use nginx to hide the non-encrypted webmail passwords, etc.
I would consider it acceptable to run nginx outside of the containers, and only need a working admin interface and an example sites-available config file.