Try to Implement Template for The message sent to subscribers when a subscription confirmation is required
My NGINX configure redirect for HTTP to HTTPS. For the domain below, mailman.example.com = my actual domain
-NGINX config server { # EXTERNAL: Redirects all port 80 traffic to HTTPS listen 80 default_server; listen [::]:80 default_server; # server_name mailman.example.com; server_name mailman.example.com; # no issue for accessing from outside, it will redirect to https return 301 https://$host$request_uri; # Redirect http to https server_tokens off;
}# INTERNAL: Listens ONLY on 127.0.0.1 to handle local HTTP requests server { listen 127.0.0.1:80; server_name localhost;
location / {
include uwsgi_params;
uwsgi_pass unix:/run/mailman3-web/uwsgi.sock;
uwsgi_param HTTP_HOST $host;
}
location /mailman3/static {
alias /var/lib/mailman3/web/static;
}
location /mailman3/static/favicon.ico {
alias /var/lib/mailman3/web/static/postorius/img/favicon.ico;
}-The URL syntax https://mailman.example.com/mailman3/lists/list-id/confirm/?token=$token
-The error message when tried to add subscriber HTTP Error 400: HTTPSConnectionPool(host='localhost', port=443): Max retries exceeded with url: /postorius/api/templates/list/list-id/list:user:action:subscribe (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1029)')))
Please help!
Thanks, Marin
On 2/16/26 18:37, msok--- via Mailman-users wrote:
-The URL syntax https://mailman.example.com/mailman3/lists/list-id/confirm/?token=$token
-The error message when tried to add subscriber HTTP Error 400: HTTPSConnectionPool(host='localhost', port=443): Max retries exceeded with url: /postorius/api/templates/list/list-id/list:user:action:subscribe (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1029)')))
What is your setting for POSTORIUS_TEMPLATE_BASE_URL?
How is your Mailman installed? Did you follow <https://docs.mailman3.org/en/latest/install/virtualenv.html>, install packages or install some other way?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
I installed it via Debian package. sudo apt install -y mailman3-full
Thanks, Marin
msok--- via Mailman-users writes:
My NGINX configure redirect for HTTP to HTTPS.
That all looks fine to me. The error below is a TLS authentication error:
HTTP Error 400: HTTPSConnectionPool(host='localhost', port=443): Max retries exceeded with url: /postorius/api/templates/list/list-id/list:user:action:subscribe (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1029)')))
Which log did you find this in (nginx or uwsgi)? It says it couldn't verify a certificate, which suggests to me that that the httpd's database of CA certificates is incomplete.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Why would you double book port 80? That's really a bad idea and causes issues like the one you see...
Your "EXTERNAL" server binds to port 80 on all IP addresses available.
Your "INTERNAL" server binds to 127.0.0.1 port 80, only.
Thus only connections to 127.0.0.1 on port 80 end on the internal server, if the host requested is "localhost".
Everything else goes to the external server and is redirected there to https.
Usually localhost in /etc/hosts resolves to 127.0.0.1 and ::1. Usually IPv6 should be preferred.
Thus if you access http://localhost:80/ you will most likely end up in the external server because it will use IPv6 which only binds on the external server.
I highly recommend to use a different port, e.g. 8080, for the "INTERNAL" server. That makes it so much simpler and easier to understand than double booking port 80 and hoping everything goes the way it should...
-Gerald
On 17.02.26 03:37, msok--- via Mailman-users wrote:
My NGINX configure redirect for HTTP to HTTPS. For the domain below, mailman.example.com = my actual domain
-NGINX config server { # EXTERNAL: Redirects all port 80 traffic to HTTPS listen 80 default_server; listen [::]:80 default_server; # server_name mailman.example.com; server_name mailman.example.com; # no issue for accessing from outside, it will redirect to https return 301 https://$host$request_uri; # Redirect http to https server_tokens off;
}# INTERNAL: Listens ONLY on 127.0.0.1 to handle local HTTP requests server { listen 127.0.0.1:80; server_name localhost;
location / { include uwsgi_params; uwsgi_pass unix:/run/mailman3-web/uwsgi.sock; uwsgi_param HTTP_HOST $host; } location /mailman3/static { alias /var/lib/mailman3/web/static; } location /mailman3/static/favicon.ico { alias /var/lib/mailman3/web/static/postorius/img/favicon.ico; }-The URL syntax https://mailman.example.com/mailman3/lists/list-id/confirm/?token=$token
-The error message when tried to add subscriber HTTP Error 400: HTTPSConnectionPool(host='localhost', port=443): Max retries exceeded with url: /postorius/api/templates/list/list-id/list:user:action:subscribe (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1029)')))
Please help!
Thanks, Marin
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to vogt@spamcop.net
Gerald Vogt writes:
Why would you double book port 80? That's really a bad idea and causes issues like the one you see...
When I read that I assumed that nginx would resolve in favor of the narrower interface:port declaration. If double-booking is happening, nginx should be issuing an error, or (nginx being pretty picky in my experience) even refusing to start.
Anyway, OP should look for messages about problems binding to ports in the nginx and uwsgi logs.
Your "INTERNAL" server binds to 127.0.0.1 port 80, only.
That's not quite true. Normally the WSGI service will bind to another port for Postorius/HyperKitty, typically 8000.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 17.02.26 09:29, Stephen J. Turnbull wrote:
Gerald Vogt writes:
Why would you double book port 80? That's really a bad idea and causes issues like the one you see...
When I read that I assumed that nginx would resolve in favor of the narrower interface:port declaration.
But IPv6 is still a different interface and ::1 would always go into that "EXTERNAL" server as that's also the default_server. You cannot connect with IPv6 into the other "INTERNAL" server.
And I think beyond that there is no "narrow" measure for interface:ports declarations. If two server blocks use the same interface and port, the server will use the server_name to determine which block to use (named-based virtual-host) and if none matches either the declared "default_server" or if no default server has been declared it's using the first matching block.
If double-booking is happening, nginx should be issuing an error, or (nginx being pretty picky in my experience) even refusing to start.
Maybe I have used the wrong term "double-booking", but most often, you have full overlap on your servers (i.e. server name virtual hosts, listening to all your interfaces on ports 80 and/or 443).
Anyway, OP should look for messages about problems binding to ports in the nginx and uwsgi logs.
Your "INTERNAL" server binds to 127.0.0.1 port 80, only.
That's not quite true. Normally the WSGI service will bind to another port for Postorius/HyperKitty, typically 8000.
I am only referring to the nginx config posted. That is listening to 127.0.0.1:80 specifically which means it is not listening to [::1]:80.
The "INTERNAL" server overlaps on 127.0.0.1:80 with the other block. i.e. on 127.0.0.1:80 it will use the server_name to determine which block to use and only "localhost" will go into the "INTERNAL" block.
So only connections to 127.0.0.1:80 or localhost:80 using IPv4 will go into the "INTERNAL" block.
Any other network connection to port 80 will always go into the other block including [::1]:80 or localhost:80 using IPv6.
As I have suggested, it would be better to use a different port number for the "INTERNAL" block.
-Gerald
participants (4)
-
Gerald Vogt -
Mark Sapiro -
msok＠lalawlibrary.org -
Stephen J. Turnbull