finished long ago

I believe that was done. - assigning to you for closure.

You wanted to redirect the MM UI unconditionally to HTTPS, so as long as it preserves the rest of the URL, then all archive URLs will properly be redirected and work well. The current HTTPS setup works well, so GOGOGO!

Yes, SMTP is opportunistic. If we want to secure specific links it is possible to setup Postfix for it but this require some settings and maintenance IIRC. Still this is better with than without.

Manual certs is currently using Digicert: one need to generate a CSR, send it to Digicert, wait for the CSR to be generated, install it and restart service manually. Currently OSAS has access, but I guess ACLs could be created to allow other people for the domain. Currently OSAS support the cost for the various communities we provide certs for, but delegating to non-OSASers is against being in control of the cost, so I wonder how it would work.

So, I'm ok with sharing the cert. Tell me when SMTP is plugged with letsencrypt so I can destroy the previous Digicert cert.

> what level of security we can reach and the associated cost of maintenance.
That's exactly my point - using a common Let's Encrypt cert is really easy and fully automates renewal.

Just to state the current state of things:

• MailMan web UI reachable via plain HTTP

• SMTP has STARTTLS but plaintext sending is also possible

Anyone who can control traffic to some users can do MITM and alter contents of communication:

• sending mail to lists (user sends email to a list, attacker alters its content)

• receiving mail from lists (list sends mail to subscriber, attacker alters its content)

• viewing archives/subscribing (user visits UI, attacker alters the HTML)

All of the above is possible right now given that the attacker can alter traffic going to a certain user (by controlling their firewall, hijacking their DNS, etc). Enforcing TLS will greatly complicate this kind of attack irregardless of the number of certificates used as long as they're signed by a globally trusted CA. This is what I am aiming for - making sure traffic from our lists is protected against MITM.

As you noted having the same certificate shared across three services is less secure than having separate ones. Since this is essentially the same machine and same service (mailing lists) with three public endpoints I do not see a huge issue here.

Moreover, we can always separate certificates once there are more ACME clients supporting it. We can even leave the digicert certificate on SMTP but who will be responsible for renewing it and what's the process as this sounds like a manual thing?

currently letsencrypt using the web method only allows only cert per name. Using DNS we might be able to do it but it requires work. I hope to have time to explore this with Misc, we already had a look, but that's not gonna happen in 5 minutes.

So for what's possible right now:
1) either we use different certs for each service, but the MTA and IMAP services would have to use another CA (like Digicert, we have an account and OSAS can provide/pay for them), nevertheless this is a manual process to renew
2) or we use the web certificate for SMTP and IMAP, like you already setup for IMAP. It's a bit less secure but not critical according to Misc, and automated

I'm stating the solutions I see and it feels important to understand what level of security we can reach and the associated cost of maintenance. I'm extremely demanding when it comes to my own private systems so I tend to favor an extra level of security out of ease of maintenance, but maybe that's too much and unnecessary.

As for installing Apache, I talked about this because we might need a certificate on a host with no web vhost, so in this case how are we to handle this? install Apache to use letsencrypt or use another CA and install the cert manually?