Nirmal J via Mailman-users writes:
While I am opening mailman.log.1 It is displaying this.
Everything up to this ACCEPT is irrelevant:
Oct 28 15:46:33 2025 (678430) ACCEPT: <176164659325.678449.14176354478536014912@list1.iitm.ac.in>
Looks like the Mailman configuration is correct, at least up to the point of contacting the HyperKitty archiving code:
Oct 28 15:46:34 2025 (678434) Exception in "hyperkitty" archiver
But your TLS is misconfigured (probably not configured at all?):
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)
(Haven't we been here before?)
The most likely problem is that you did not configure the base_url in mailman-hyperkitty.cfg. If your SSL configuration is correct, then changing that line to something like
base_url: https://list1.iitm.ac.in/archives/
should do the trick (be careful, pretty sure it will be similar but the host part must match the SSL certificate used by the host).
In the most common installation, Mailman and HyperKitty are on the same host. If so, there's no point in using SSL. At least I cannot think of a scenario where an adversary can tap a local connection but doesn't have a dozen other ways to steal the same information. So if that is the case, an alternative to fixing the SSL configuration is to have a virtual host listening on port 80 that doesn't accept any requests except those reverse proxied to HyperKitty. Or even just going directly to http://localhost:8000/archive should work. (This has the possible disadvantage that accesses to HyperKitty from Mailman won't be logged by your webserver, but they will still normally be logged by HyperKitty itself I think.)
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan