I would like that when a domain points on the server and the mail service is active, Let's Encrypt should be automatically activated for "mail.domain.***" as it happens for "Webmail.domain.***".

As others have noted, I would love to have the option to include mail.example.com when generating a certificate, even if the domain is not set to "No hosting".

Just make it a generally available checkbox like the webmail one. Just don't hide it when the "Hosting" option is on.

People, I don't understand why you are still complaining. Suppose your domain's A and AAAA records point outside the Plesk server - or the domain is behind CloudFlare, which I will address separately. In that case, the resource hosted on the Plesk server under the domain (excl. sub-domains) is, by definition, unreachable, so I don't understand why you would still keep the hosting turned on unless you have subdomains (in which case there is a valid point for an issue), so I understand why Plesk would make this a feature just for "No web hosting".

You can always create a subdomain as a "domain", say `subdomain.mydomain.com` as a workaround for the subdomain of a domain with "No web hosting" until the issue is resolved - sorry, I know, wordy.

Webmail operates separately from the hosting and can be enabled from the mail settings even under "No web hosting". When "No Web Hosting" is set, you still can create mailboxes and run a Webmail for the said domain. In that case, you CAN choose whether to generate a "webmail" or "mail" subdomain certificate along with Dane.

As for Cloudflare. If you are running Cloudflare and exposing your server by making the IP of `mail.yourdomain.com` visible via "DNS Only" records, you are not using the CF service correctly, as CF primarily protects the server from DDoS attacks; it's not there to be pretty. All it takes for an attacker is to look at your MX records and see what domain or IP is listed, then direct the attack on that IP, circumventing all DDoS protection you'd typically get with CF. For CF, there is a service called mail routing, which you can use to route emails from CF to your mail server or mailbox which allows you to host emails on your mail server while not exposing your server's IP address, and it's even free up to 50 users.

It genuinely frustrates me when people start commenting while not providing any constructive feedback (i.e. whining), not least because it generates a ton of emails on my end - remember, this might not be the only software I'm keeping track of feedback for. If there is something that this fix isn't addressing, politely ask for it to be addressed as well, or create new feedback.

For instance, the inability to set "No web hosting" on `mydomain.com` while keeping the subdomains like `another-resource.mydomain.com` is indeed a valid issue, which would prevent generating "mail" and "webmail" SSL certificates - which seems to be an oversight.

This sadly does not fix the problem.

In my case I use CloudFlare, so I can't use the tld like "domain.com" as the mail hostname, cause the tld is proxied and my email client won't be able to connect. That is why I have "mail.domain.com" as an A record but NOT proxied, DNS only, so my mail client talks directly to my server, not through CF.

All one would have to do is add a button to issue an LE certificate for a subdomain of my choosing. Hosting is not required.

Example:

/usr/local/bin/zerossl-bot certonly -n --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/cloudflare-api-token --dns-cloudflare-propagation-seconds 60 -d 'mail.domain.com' --zerossl-api-key=[apikey] -m "some@emaladdress.com" --agree-tos --no-eff-email

And of course enable automatic renewal. The above command waits for propagation of CF so there's no manual intervention.

A record pointing elsewhere is NOT enough. You need to also consider use case scenarios like mine, and thousands others using CloudFlare with proxied domains.

What's the hold up? Why is it taking so long to catch-up to modern usage of internet tools & services?

CloudFlare is an industry standard, it needs to be made a priority and be fully integrated into Plesk.

The problem is not resolved for me! It will be solved when I can specify for which domains (including their subdomains) I want to obtain a certificate and for which domains I do not need one. This would allow me to disable certificate generation for domain.com while enabling it for mail.domain.com and webmail.domain.com.

The initial suggestion was:

Issue Let's Encrypt SSL certificate for mail server when the "A" DNS record for domain is pointing to another server

and not

Issue Let's Encrypt SSL certificate for mail server when the domain has a subscription with 'no web hostting'.

!!!

I agree with some of the comments. Just because example.com isn't hosted with us, there may be webmail.example.com, subdomain1.example.com, etc. Would be best not to link this to the existence of a hosting plan and instead, if I check the box for webmail.example.com, to just include mail.example.com in the SSL.

It would also be nice if "mail.<domain>" was also included even when A record is pointing to Plesk server (if mail.<domain> IP address is the same as A record for <domain>).

So this feature is now working only with the "no web hosting" subscription type : this is a progress.
But if we have an hosting enabled, because we host subdomains, but the "A" DNS record for main domain is pointing to another server, seems there is still no way to do this...

so plesk gmbh took basically 5y to implement a stupid *** feature almost 200 people are requesting on this uservoice, plus the countless other who didn't bother or perhaps don't even know of this platform, meanwhile people like me migrated off three different other platforms, including a self made cronjob-script-managed half assed together private server, and yet they still hand't yet made this ssl thing official.
wow, then people ask me why I never used plesk again and I'm actively hating it and recommending against... I think the reason is pretty clear
I literally lost count of the amount of bugs I reported to plesk during my just 5 months of use before ditching this **** all together for anything decent but this

We have a few customers that for one reason or another we don't host the website on the Plesk server, but still host DNS and email. There is no easy way to have a mail.<domain> SSL certificate generated by Let's Encrypt like it can for webmail.<domain>. I'd like to see mail.<domain> be an option for SSL generation so that mail clients can connect securely to the mail server and not have to explain to them about using 'webmail.<domain>'.

Any update on this? cPanel does it well, but not Plesk? WhY?

Hi,

is this feature not available in PLESK at the moment? Definitely necessary!

This is absolutely essential. Configuring domains solely for email services on Plesk can be quite cumbersome. To maintain SSL certificates, you have to create subdomains like "mail.domain.com", and the renewal process sometimes fails, which complicates things further.

cPanel has been able to do this for years using DNS challenges. Now, trying to migrate all of our clients to Plesk is becoming a challenge. We don't have a huge amount of email only clients but our resellers do, we'll definitely hear it from them.

This has been a request on this site since beginning of 2020, so over 4 years ago. Since every browser and email program requires SSLs, why hasn't this moved up the list yet?

Very frustrating, this should be a critical feature to be implemented...

Now that Mailman3 is supported on Debian 12, can you also add the ability for adding a Let's Encrypt SSL certificate for the list subdomain when the domain is not pointing to the Plesk server?

I've made a small Script to work around this issue. Should be pretty self explanatory and easily adjustable to custom needs - hope it helps some of you as Plesk isn't going to fix anything soon as it seems ... 🙄

https://github.com/futureweb/Plesk-Postfix-SNI-TLS-Cert-Fixer

This function is critical for us and probably a reason to move to cPanel.

Here is my temporary solution for it:
https://gitlab.com/nixoeen/plesk-mail-sni

Is this a joke? This makes no sense that this problem persists!

That means we can't sell 'email only' accounts?!

Yes will be usefull