Let´s try it with https://plesk.uservoice.com/forums/184549-feature-suggestions/filters/new?category_id=82696 with a smart description so it won´t be marked as "finished" again.

When DNS records for the domain point to another IP than the mail server, an SSL certificate can not be issued? Why? Who hosts e-mails on the same server as websites anymore? Plesk dev team, why did you make such an effort and did not think of this? Please update this feature, I was waiting for this feature for years and I am very disappointed.

@Jayson, no, also a wildcard certificate isn´t possible when DNS records point to another server: Let´s Encrypt checks costumerdomain.tld/... and that´s a website URL, not a mailserver URL. Got it? And it is not made possible by creating other DNS records like TXT records with a token or so, in case you meant something like this, and even that would be too much and unnecessary effort.

@trilos, they do tell you what DNS record needs to be created for the wildcard certificate, so you could manually create it to complete the process.
But it could definitely be improved or have the option for mail only in the config.

@Jayson - Thanks, but no: It is not possible to secure mail.customerdomain.tld when DNS records for (www.)customerdomain.tld point to another server. (Workaround: Change customerdomain.tld in Hosting Serttings to mail.customerdomain.tld temporarily, secure and rename back again.)

@trilos - In Obsidian release, you can do configure this per domain and it works great. You create a wild card certificate for the domain, then under mail settings for that domain you select the let's encrypt certificate to enable secure connections. There are a couple of other smaller configs that you need to do int he back end if you have upgraded from onyx to obsidian and it take a few minutes before you can issue the certificate though as it needs to resolve a new DNS entry for the wild card verification.

This is compelling and it´s getting urgent and more urgent and... inacceptable to wait out longer!

This issue has gone over and over too much time and IS really annoying.
Do something for Christ sake!!

still needed!

@Jochen /signed

Could someone please finally update the description of the original request here to reflect that this feature suggestion is really about adding the "let's encrypt" part to this one here: https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/32132116-it-would-be-nice-to-provide-mail-ssl-tls-support-w ?

NetVicious: You didn´get the problem. The aim is to secure every customer´s own mailserver name
mail.customer1.com
mail.customer2.com
mail.customer3.com ...

it's not about subdomains ... it's about domains!

It's about this scenario (now with wildcard certs ...)
*.customer1.com
*.customer2.org
*.customer3.net

Don't loose time creating multiple certs for each subdomain. Let's Encrypt allows creating wildcards certificates (like *.example.com) from one year ago. Check next link:
https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579

@alexander postfix SNI has already been added so they can easily implement it. That information is old.

@TRILOS new media: Yeah, this has been discussed in the comments but not in the original feature request. My approach solves the original feature request. But I agree that the more advanced solution to secure mail with all the different domain names would be nice. This would also require implementation of SNI for postfix, which is not there yet: https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/32132116-it-would-be-nice-to-provide-mail-ssl-tls-support-w

@Alexander Blinne: You didn´get the problem. The aim is to secure every customer´s own mailserver name
mail.customer1.com
mail.customer2.com
mail.customer3.com ...

I do it like this:
1) Secure the plesk panel with Let's encrypt
2) Chose the same certificate for securing mail
3) Refer to the mail server by the same hostname as I use for the Plesk panel
And everything works fine.

Yes, we need this so each customer can input their own plesk hosted domain name in their email client (eg smtp.customerdomain.com) and securely connect to the Plesk mail server. This will help in many ways especially if we have to ever move a customer to another plesk server, the email can continue to work as their using their own domain name instead of the hosting provider plesk server (eg server104.hoster.com)

Actually this is possible by commandline. I would suggest for plesk developers to set an option like that of "Secure plesk panel" with the ability to let the admin chose at plesk installation, or in settings in the following way:
1) I setup my server that is named mainserver.domain.tld
2) Plesk asks me to secure the panel, I select the checkbox, letsencrypt will generate a certificate for mainserver.domain.tld
3) Plesk asks me which subdomain should use for the mail subscriptions: I input MAILSUBDOMAIN as a name or whatever I like
4) Plesk uses letsencrypt with option --expand to expand certificate for mainserver.domain.tld to include mailsubdomain.domain.tld
5) Everytime I create a new domain in plesk, plesk will automatically expand the existing certificate for mainserver.domain.tld and mailsubdomain.domain.tld adding mailsubdomain.domain2.tld mailsubdomain.domain3.tld etc up to 100 domains that it's the letsencrypt domain limitation(If I'm not mistaken)
6) Plesk assigns this ssl to the plesk panel and mail server automatically every time it is renewed and keeps in database the list of existing domains, so it gets renewed with all the mailname.*.tld

This way you have a standard that is used for mail service, and doesn't abuse letsencrypt.
All the domains mailsubdomain.*.tld will be virtual and redirected to one single directory for letsencrypt acme challenge. If someone opens mailsubdomain.domain.tld in the browser, it gets redirected to webmail(sort of alias)
All the rest of the domains remain like it is now.

That is my suggestion of how I think it would be the easiest way to implement, without too much hassle.

vote

How is this essential feature still open discussion