Dovecot supports both different certs per IP and different certs on one IP using SNI. Of course most mail clients don't support SNI, so the multiple certs on one IP is not that useful, but a unique cert per IP is useful, just like it is in web server software, so having that feature would be nice to implement. If that were available, it would be easy to let customers use their own domain name for their email software, with SSL enabled, and no errors about the cert name.

Hi TomBob, thanks for your reply.

What's the solution than? One mail server per domain/certificate, right?

Joe, that is not possible as postfix for example doesn't support that.

See https://support.plesk.com/hc/en-us/articles/213924425 regarding that :
"NOTE : There is a single certificate for each of these services: SMTP, IMAP4, and POP3 over SSL. Multiple certificates cannot be used for multiple Plesk domains."

Search the net (or postfix documentation) for detailed info on that.

I am missing the option to choose for each domain a different mail SSL certificate. Could you please add this?

The letsencrypt certificate for hostname doesnt show up in SSL Certificates list to select it for mail server

@Hostasaurus: I disagree. What you are trying to say is that we can close all gasstations, because there are _some_ electric cars. I am sure you will agree that is not a viable solution, because there are still a lot of cars still using gasoline.

The same goes for this scenario. SNI e-mail services are only a solution when all or atleast the vast majority of mail clients support it, and IMAP/POP3/SMTP over SSL is completely removed (as SSL does not support SNI).

If you implement it now, the majority of your users will start complaining about invalid certificates, because they either connect over SSL or have a client that does not support SNI.

eg. as far as I know there are currently no mobile clients that support it, while perhaps mobile clients are the primary use case for this scenario because encryption is important for mobile users connecting over dubious WiFi connections.

You state that 'Using 587 with STARTTLS is the norm'. When is the last time you configured any e-mail client? As far as I know, all of them connect to port 25 by default.

Furthermore, eg. Outlook has a checkbox for 'Use SSL', but it does not have a checkbox for 'Use TLS'. You have to configure TLS in a dropdown menu option somewhere else. People know 'SSL' as beeing secure, and are prone to clicking on it just because they believe 'Oh, ssl. That is safe!'. So SSL usage on Outlook clients is most likely higher compared to other clients.

The same goes for eg. RFC 6186. While RFC6186 could potentially cure all these issues, almost none of the commonly used clients support it.

So, all in all my opinion is that it is _way_ too early to implement SNI on e-mail services and use it in production. We're just not there yet. Because of that, I believe Plesk should not implement this as of now because it lets Administrators believe a function exists and works, while in reality it will only work with 1 or 2 clients, granted those users have configured TLS instead of SSL.

If Plesk chooses to implement this feature, it should come with enormous warning signs saying 'Probably wont work!'. As most of the Plesk server owners are newbies ("My First VPS(tm)"), I believe we shouldn't go there.

@Tozz, I'm not clear on what definition of 'correct' you're using. You stated such a configuration was 'technically impossible' and 'So the short answer is: No. Impossible.' when there are already clients (Thunderbird) and servers (Courier, Postfix and Dovecot at a minimum) which explicitly support SNI with TLS. This is certainly a feature Plesk should be implementing and there's no technical reason not to. Regarding SSL, that's inconsequential since on the sending side, mail servers use port 25 and starttls as default for years now, and on the client side, using 587 with starttls is also the norm. I don't know any server that tries explicit SSL over starttls these days, and even if there are legacy systems out there that do, qmail for example, the server on the other end will simply respond with its default cert used when SNI is not asked for, and that gets us back to the same place we're already at.

@Hostasaurus : Actually, in reality I am correct. True, TLS does have SNI support, but currently only a very small handful of clients support it. Furthermore, e-mail does not exclusively use TLS. It also uses SSL, which does not have SNI support.

So, yes.. there is light at the end of the tunnel, but we're not there yet. So as of now, there is no way to really support multiple SSL certificates without facing a shitload of customer complaints due to failing certificate checks.

Not holding my breath on that; they tend to never roll new features into older versions since they don't seem to have any concern for organizations who have larger deployments, long change control processes, and configuration management to consider.

great work, Thanks!

one small question: is it likely to be implemented in 12.5 as well? Just thinking of the late adopters who may switch to Onyx only middle to end of next year.

@Tozz you are not correct. SNI is not exclusive to HTTPS, nor does it involve sending a 'host header' since that's specific to HTTP protocol. SNI occurs as part of TLS, and yes, it is possible to implement with ANY TLS-based connection, including IMAP, POP3 or SMTP. It sends the hostname it wants and then up to the other TLS-capable end point to decide how to handle that. In fact, Dovecot even supports such a feature, read about it at http://wiki.dovecot.org/SSL/DovecotConfiguration

@darkdragon: No, because that is technically impossible. E-mail such as IMAP, POP3 or SMTP does offer anything that would allow a server to serve multiple SSL certificates, based on the hostname the user is connecting to.

With eg. HTTP, there is a 'Host' header that the clients sends to the server, to allow the server to pick the correct certificate, based on the hostname that the client is requesting.

There is no such thing in the e-mail protocols I mentioned above, so the server cannot serve more than 1 SSL certificate. The only way to do that would be to have a unique IP-address per SSL certificate. With the IPv4 scarcity that is not a viable solution.

So the short answer is: No. Impossible.

Does anyone see a possibility to select certificates based on domain/hostname instead of only one global one?

Do you have news?

A fully automated quick hack for Letsencrypt users until this feature is finished: Just put the following lines to e.g. /etc/dovecot/conf.d/5-ssl.conf. (Be sure to have a domain with an empty website defined named mail.mydomain.tld to automatically obtain your certificate updates via the Letsencrypt extension.)

---

# SSL Certificates for Dovecot are defined here

ssl = required
ssl_cert = </opt/psa/var/modules/letsencrypt/etc/live/mail.mydomain.tld/cert.pem
ssl_key = </opt/psa/var/modules/letsencrypt/etc/live/mail.mydomain.tld/privkey.pem
ssl_ca = </opt/psa/var/modules/letsencrypt/etc/live/mail.mydomain.tld/fullchain.pem

We would also be grateful if that option were finally available.

@Daka media,
We expect it available in Sep

@Sergey L thank you. Is there any approximately Release Date as it would help me not to buy a extra Tool for this Function.

@Daka Media KG
Yes, there is definitely a progress. Working on it

Yes please, is there any progress on this topic?
we would love to have this feature with Let's Encrypt