Strange behaviour when SSL (https) is activated
Hi,
I do a fresh install of Mailman3 and Mailman3-web on Debian 11 and all seems working fine using non-ssl access.
But if I activate SSL on the web server, I'm unable to login. I go to the /admin, prompted for the user/pass, and got a Firefox error page saying "Échec de la connexion sécurisée".
Main django account was created with:
mailman-web createsuperuser --username XXXX --email xxxx@xxxx.xx
extract of /var/log/mailman3/web/mailman-web.log :
[pid: 103142|app: 0|req: 40/40] 192.168.200.252 () {48 vars in 1039 bytes} [Mon Jan 3 11:26:32 2022] GET /accounts/login/ => generated 9321 bytes in 37 msecs (HTTP/1.1 200) 7 headers in 429 bytes (1 switches on core 0) Mon Jan 3 11:26:40 2022 - uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 248] during POST /accounts/login/ (192.168.200.252) OSError: write error [pid: 103142|app: 0|req: 41/41] 192.168.200.252 () {54 vars in 1008 bytes} [Mon Jan 3 11:26:40 2022] POST /accounts/login/ => generated 0 bytes in 704 msecs (HTTP/1.1 302) 9 headers in 0 bytes (1 switches on core 1)
All is working fine on non-ssl connection.
Any hint appreciated ;)
François TOURDE writes:
But if I activate SSL on the web server, I'm unable to login. I go to the /admin, prompted for the user/pass, and got a Firefox error page saying "Échec de la connexion sécurisée".
According to Google Translate, this means "Secure connection failed", which seems to be a webserver problem, not a Mailman problem. Recent Firefox is very picky: it wants a proper certificate (although free certificates such as CertBot will do), and it won't accept SSL or TLS versions less than 1.2. Make sure that your webserver is properly configured to use TLS >= v1.2, and has a properly configured certificate.
[pid: 103142|app: 0|req: 40/40] 192.168.200.252 () {48 vars in 1039 bytes} [Mon Jan 3 11:26:32 2022] GET /accounts/login/ => generated 9321 bytes in 37 msecs (HTTP/1.1 200) 7 headers in 429 bytes (1 switches on core 0) Mon Jan 3 11:26:40 2022 - uwsgi_response_write_headers_do(): Broken pipe [core/writer.c line 248] during POST /accounts/login/ (192.168.200.252) OSError: write error [pid: 103142|app: 0|req: 41/41] 192.168.200.252 () {54 vars in 1008 bytes} [Mon Jan 3 11:26:40 2022] POST /accounts/login/ => generated 0 bytes in 704 msecs (HTTP/1.1 302) 9 headers in 0 bytes (1 switches on core 1)
This suggests that you're seeing a variant on the "redirect from HTTP to HTTPS loses POST data" problem. The description of the problem is different and I have no idea what your configuration is, but if the advice (not the problem description) looks familiar the following post may be of help: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
Any hint appreciated ;)
More information about your webserver and Django configurations would be useful.
Le 18995ième jour après Epoch, Stephen J. Turnbull écrivait:
According to Google Translate, this means "Secure connection failed", which seems to be a webserver problem, not a Mailman problem. Recent Firefox is very picky: it wants a proper certificate (although free certificates such as CertBot will do), and it won't accept SSL or TLS versions less than 1.2. Make sure that your webserver is properly configured to use TLS >= v1.2, and has a properly configured certificate.
Yep, and maybe I wasn't clear enough, but all other pages display correctly. It's only when I try to log-in (ie: POST request).
This suggests that you're seeing a variant on the "redirect from HTTP to HTTPS loses POST data" problem. The description of the problem is different and I have no idea what your configuration is, but if the advice (not the problem description) looks familiar the following post may be of help: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
Unfortunately, it seems no related as far as I understand this post.
More information about your webserver and Django configurations would be useful.
You're right :) ... The request path is as follow:
Firefox --> haproxy front --> nginx on mailman server --> mm3-web socket (unix:/run/mailman3-web/uwsgi.sock)
The nginx conf is close to the proposed one on the Debian package:
upstream list.my_dom.ain_mm3 { server unix:/run/mailman3-web/uwsgi.sock fail_timeout=600; }
server { listen 443 ssl; listen [::]:443 ssl;
server_name list.my_dom.ain; server_tokens off;
ssl_certificate /etc/letsencrypt/live/list.my_dom.ain/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/list.my_dom.ain/privkey.pem;
location / { uwsgi_pass list.my_dom.ain_mm3; include /etc/nginx/uwsgi_params; } ...
Django config is as installed by Debian mailman3-web package.
Thank you whatever for your help !
On 1/3/22 11:02 AM, François TOURDE wrote:
Yep, and maybe I wasn't clear enough, but all other pages display correctly. It's only when I try to log-in (ie: POST request).
When you go to the login page, is the url in your browser's address bar an https url?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Le 18995ième jour après Epoch, Mark Sapiro écrivait:
When you go to the login page, is the url in your browser's address bar an https url?
Yes, it is.
But I need to investigate a bit more about 2 or 3 issues I just noticed. I got oom-kill on uwsgi (argh !), and some timeouts (but not clearly related to) on haproxy side.
I'll come back here once these issues clarified.
Thanks all for your replies !
Le 18996ième jour après Epoch, François TOURDE écrivait:
But I need to investigate a bit more about 2 or 3 issues I just noticed. I got oom-kill on uwsgi (argh !), and some timeouts (but not clearly related to) on haproxy side.
Finally I found a bad timeout value (500ms on a slow and old Xen host supporting too much VMs) which caused the issue.
I moved 2 VMs on another Xen, freeing enough memory to increase mailman VM size. No more oom-kill now.
My haproxy config had global timeouts, backends timeouts ... plus a specific one on my frontend https config. Removing this one solves the problem. Due to Ansible deployment, and because my frontend is global for all URLs, I didn't notice it :(
Thanks for your support !
participants (3)
-
fr-mm3＠tourde.org -
Mark Sapiro -
Stephen J. Turnbull