Certificate of the mail server for different customers
Problem reported by Roger - 12/15/2022 at 1:57 PM
Hello all

I find the current approach with a single general certificate for all customers mail server (not the webmail) counterproductive. I believe that each client should have its own incoming and outgoing mail server, which uses an individual SSL certificate, as is easily possible with Microsoft 365. The current solution that the mail server contains all domain names (mail.domain.com and autodiscover.domain.com) is very questionable.

Apart from the fact that it is none of the customer's or external's business which domains are traded via the mail server, the certificate renewal with Let's Encrypt, for example, is also error-prone. If a customer changes the DNS entry of mail.domain.com and/or autodiscover.domain.com, the entire certificate is not renewed.

I have contacted support for this a few times and was told that this is currently not possible in any other way, but this must not be the continuing way. If someone could solve this differently I would be happy about hints.

I think this could also be solved with a proxy (SMTP/POP/IMAP) that uses the corresponding SNI analogous to the web server (TLS 443/TCP) for the use of individual certificates per customer (domain).

Thanks and greetings

1 Reply

Reply to Thread
Douglas Foster Replied
For the present product:

Are you using a certificate with a unique SAN entry for each customer?   I can see where that would make for disaster, because every domain owner gets a veto over your certificate issuance at every renewal.   If you were using anything other than LetsEncrypt, it would also be vey expensive.

With the current product, the workable designs are a single-name certificate for the server, or a wildcard certificate that allows you to configure <customer>.<yourhostingdomain> as the server name used by each client.   Both of these designs have reasonable cost when using a paid certificate authority that can issue 13-month certificates.

To move away from the multi-SAN design, you will need to get a wildcard certificate with extra SANs.   Then your new clients can use the wildcard and you can try to convince your existing clients to migrate to the new naming structure.
For your proposed redesign:

Having a unique certificate for each customer means that the customer has to manage the certificate renewal. The less sophisticated clients will mess it up and still call you when the certificate expires.

I managed Microsoft Exchange before managing SmarterMail.  It could do lots of fancy things, but it also required a PhD in Exchange, or better a team of people with those PhDs, to manage it successfully.  SmarterMail wins with a streamlined product, for those who want streamlined cost and complexity.  Sometimes that means giving up some nice-to-haves.

Reply to Thread