Input Add multidomain-support to Let´s Encrypt Certificate used for the mailserver

[Sascha Schlüter]

Hey,

i am hosting several domains including mail-services on one Plesk Onyx machine. When setting up a new hosting-account in the past I told my customers to use the subdomain mail.customerdomain.tld as the POP/IMAP/SMTP-hostnames in their mail clients. Obvious and easy to recall.

Since mailclients force to connect to servers using ssl-encryption and valid certificates, im getting more and more trouble, because the mailserver is secured with a Let´s Encrypt certificate for server name.tld, which is not accepted by my customer´s mailclient (which expects a certificate for mail.customerdomain.tld as specified in the hostname-setting).

Would´nt it be great to upgrade the Let´s Encrypt - implementation, so that it adds the mail.-subdomain of every hosted mail domain on the server to the Let´s Encrypt Certificate used to secure the mailserver?

 

[mr-wolf]

I was eager to find out your "input" only to find out it was a question....
Plesk is working on this.

 

[ChristophRo]

Sorry, this will never work, as it's not possible to store more than 4096 bytes in the related field (Subject Alternativ Name) of a certificate.
Sure, this would work for a couple (arbitrary number) of domain names, but nothing to justify an "official" solution or support for such a thing.

So imho it would be far better to get rid of this mail.customerdomain.tld stuff alltogether, and provide a built-in solution to serve the webmail unter the primary server name on port 80/443
Also for legacy reasons, it should redirect (http 302) http://mail.customerdomain.tld to this URL, so customers that used their own domainname for accessing the webmail, do not have to change their bookmarks and behaviour.

 

[redhell]

A solution could be if the hosting account has an dedicated IP adress, the domain's certificate for the mail server could be used. For shared IP adresses it would use the servers standard certificate.

 

[sebgonzes]

Well, it's something that a lot of plesk user we need : Question - Plesk 17.8 and domain SSL mail
Also still wait an solution for this, that would really we need, other feature of plesk are really menor for me.

 

[ChristophRo]

And how should such a solution look like, if you

a) can't have unlimited domain names within one certificate
b) POP/IMAP/SMTP servers do not support SNI. (so to support multiple certificates per IP address) .. not to mention that mail clients would need to support that as well, and not all do nowadays

One dedicated IP address per domain could solve that, as Dovecot/Postfix support different certificates for different IP addresses, but who does have spare IPv4 addresses for such stuff nowadays?



A compromise could be, that Plesk allows us to set multiple domain names (up till reaching 4096bytes for all these names) for the panel itself, and use them as Subject Alternativ Names for the LetsEncrypt certicate that is used for securing the panel.
As this cert is also used for the FTP, SMTP, POP and IMAP service, this would allow users to have their server be used under multiple names. (for all purposes)
For small servers (30-50 domains) this would even allow what you're seeking - "securing" ALL domains

 

[Sergio Manzi]

b) POP/IMAP/SMTP servers do not support SNI. (so to support multiple certificates per IP address) .. not to mention that mail clients would need to support that as well, and not all do nowadays

You sure about that? I have the impression that SNI is in fact possible (server side), but again limitation in the possible number of supported domain names and clients limitation still hold and therefore this is not a generally viable solution.

I have always sustained that using "mail.<domain>" for MX/SPF is plainly wrong (just think how rDNS is inevitably broken for those entries...) and I think Plesk has done a terrible mistake by setting those entries in the default "DNS Template". I understand that "fixing" this mistake now can be... quite complicated.

Having said that, I support @redhell call for supporting an ad-hoc configuration and certificates when a domain is associated to a dedicated IP address.

There should also be (at least) two DNS Templates: one for domains using the shared IP address and one for domains using a dedicated IP address. [O.T: actually I'd love to have "n" DNS templates available, like e.g. for when domains are associated to an external mail service like Google G Suite.]

I've also recently learned that nginx can act as a mail proxy (see: NGINX Docs | Configuring NGINX as a Mail Proxy Server) and I'm wondering if this can be something that could help in that context...

 

[mr-wolf]

I have a solution using one wildcard certificate and cnames for each client that I have.
Works flawless and does not rely on Plesk, Letsencrypt nor SNI.

Each client domain name gets a CNAME pointing to its mail.client.com.

client-com.wolf.com points to mail.client.com

The client needs to use client-com.wolf.com in his mail client.

Easypeasy and robust.
Working in the real world for over a year...


SNI is supported by dovecot.
But only modern clients support SNI

 

[Sergio Manzi]

The client needs to use client-com.wolf.com in his mail client.

Then why do you need a wildcard certificate?

 

[Sergio Manzi]

ah, ok, I see! wildcard under wolf.com, so users can use client-com.wolf.com and have their ego happy....

P.S.: actually a "partially happy" ego! TBH I don't see much value added in this solution...

 

[sebgonzes]

I have a solution using one wildcard certificate and cnames for each client that I have.
Works flawless and does not rely on Plesk, Letsencrypt nor SNI.

Each client domain name gets a CNAME pointing to its mail.client.com.

client-com.wolf.com points to mail.client.com

The client needs to use client-com.wolf.com in his mail client.

Easypeasy and robust.
Working in the real world for over a year...


SNI is supported by dovecot.
But only modern clients support SNI

I can't use this setting because I have too much user with mail.domain.com in our client program, but seem can be an solution with nginx mail in the future?

 

[Sergio Manzi]

Sorry if I insist, and please forgive me if I'm missing something:

"telling" your customers (or prospects...) that "with you" they will have "mail.theirdamndomain.com" as their mail "endpoint" can be of some value, as you can tell them that "with you" they will not be "locked in" and the day they'll so desire they will be able to move to another provider without having to re-configure all of their clients, and thus there is some value added (This actually "part of the story" as they'll have to find someone else that support your same configuration, but again, this is another story...).

Telling your customers that their email endpoint will be "theirdamndomain.myveryowndomain.com" instead of "myveryowndomain.com", where is the added value?

 

[MarkM]

Ya'll just tell them they don't need SSL, problem solved

 

[Sergio Manzi]

Ya'll just tell them they don't need SSL, problem solved

 

[ChristophRo]

You sure about that? I have the impression that SNI is in fact possible (server side), but again limitation in the possible number of supported domain names and clients limitation still hold and therefore this is not a generally viable solution.

Ok, I have to correcty myself, Dovecot has SNI support, but Postfix does not. (nur sure about qmail)
Also some clients do not support it, so it's really moot do put much effort in it, as it will never be a general solution.

I have always sustained that using "mail.<domain>" for MX/SPF is plainly wrong (just think how rDNS is inevitably broken for those entries...) and I think Plesk has done a terrible mistake by setting those entries in the default "DNS Template". I understand that "fixing" this mistake now can be... quite complicated.

MX records do not have anything to do with it and it's completely wayne,how you name them.
This name of the MX does not matter for TLS nor rDNS. (the later is completely up to the HELO string of a mailserver)


So, IMHO the only big mistake that Plesk really made (and I could not facepalm enough when I saw them realease that) is the possibility do allow user to use letsencrypt/https for webmail.DOMAIN.TLD.
I knew back then, that this would backfire, are people now also want to use that SSL for POP/IMAP/SMTP and that obviously can never work.

It would have been much better to run the webmail under https://pleskservername.domain.tld and http/302 redirect all requests from http://webmail.customerdomain.tld to this URL
Im mean, currently the only thing that runs under that URL now, is the plesk panel preview page...and nobody needs that.

 

[Sergio Manzi]

Also some clients do not support it, so it's really moot do put much effort in it, as it will never be a general solution.

Totally agree.

MX records do not have anything to do with it and it's completely wayne,how you name them.

Partially agree:

• There is always the rDNS issue and some picky server could test for it
• There is a general expectation (mind you, not any technical reason...) that whatever you put in the MX record will also be what you'll have to configure your clients with

So, IMHO the only big mistake that Plesk really made (and I could not facepalm enough when I saw them realease that) is the possibility do allow user to use letsencrypt/https for webmail.DOMAIN.TLD.

Disagree:

• Having "webmail.<domain> for accessing webmail is perfectly fine, it doesn't create any technical problem (nor with TLS nor in any other way) and makes customers happy

 

[ChristophRo]

Totally agree.
Partially agree:

• There is always the rDNS issue and some picky server could test for it
• There is a general expectation (mind you, not any technical reason...) that whatever you put in the MX record will also be what you'll have to configure your clients with

Sorry, have to dissapoint you, rDNS is and was never a problem or anyhow related to the MX name, not even for the most picky and strictly configured MTA out there.

There can also be no expectation that the MX name(s) relate to the server servername that clients need to configure to.
For 98% of all mailservices out there, this is not the case. (ever checked gmail or office365 on how they name their mx and what customers use for smtp/pop3/imap access)


I agree with you that there is not technical reason on to why not using http(s)://webmail.domain.tld for accessing webmail.
But why use the customer domain for webmail when you have to use the generic servername for smtp/pop/imap/ftps and control panel access anyway?

For more than ten years now, we tell our customers to use "servername.mycompanyname.tld" for accessing everything related to their service. That was fine and they only needed to know/remember one single FQDN
Any yes, we already had a custom workaround in place, to redirect http://webmail.customerdomain.tld to https://servername.mycompanyname.tld

 

[Sergio Manzi]

But why use the customer domain for webmail when you have to use the generic servername for smtp/pop/imap/ftps and control panel access anyway?

... because the webmail address is visible by every company employee using webmail, and, most important, it is visible by the CEO, CFO, CTO, etc., while the clients configuration is generally visible by the IT monkeys (that's me, no offense taken by anybody, please!).

As far as the rest, I'm perfectly aware of the G Suite configuration (of which I'm a big user), I stated that there is no technical reason, and I'm still convinced that such an expectation exists. But here we are out of the realm technical aspects, and more on a realm where, I hope, anyone is free of his opinion...

rDNS... I'll check... I'm quite sure I've seen some configuration parameter in SMTP servers where this was configurable... but I'm not putting 100$ on that...

 

[Sergio Manzi]

rDNS, some examples from a quick Google search...

• Postfix Configuration Parameters
• setting correct PTR record for domain and postfix email server
• Require PTR lookups for postfix
• Postfix Reverse DNS Lookup: 450 4.7.1 Client host rejected

and... have you noticed that tools such as mxtoolbox and the likes do make a PTR test?

 

[Jllynch]

Any update on this. Now bloody Apple iOS devices won't accept a certificate that doesn't match the mail server name you are looking up.