Resolved Let's Encrypt cert not valid for webmail

[RenWeb]

I've tried with all recent versions of Let's Encrypt (now LE 2.0.3). At the stage that the Plesk interface seems to work with the LE certs and reports that the various domains have webmail covered by them.

But, email clients and webmail browsers seem to still disagree - they see the LE certificate as 'legit' for the domain but not for anything else?

Please point to errors (or log locations of them)

Using
Plesk Onyx 17.0.17 Update #22, last updated on April 10, 2017 11:29 PM
on a WebFusion (webfusion.co.uk) VPS using Ubuntu 12.04.5 LTS‬
Cheers

 

[UFHH01]

Hi RenWeb,

you miss the fact, that you still have to create a certificate for webmail.YOUR-DOMAIN.COM, to be able to use a LE - certificate to secure your webmail - subdomain - but it is now possible to secure a ( existent ) "webmail." - certificate over the Plesk Control Panel and you are now as well able to secure your mail - server with a ( existent ) "mail." - certificate over the Plesk Control Panel, which might not be pointed out very clearly in the change log.


Even that it would be possible ( but not yet implemented! ), to auto-add not only the additional "www." - domain in your LE - certificate, when you create one over the Plesk Control Panel for YOUR-DOMAIN.COM, but as well "webmail." and "mail.". This has been discussed several times here in the forum and the Plesk developpers are still working on a solution to satisfy all recent requests/demands/suggestions. Pls. be patient for some more time and you will ( hopefully ) like/love/adore the upcoming Plesk Extension Let's Encrypt vX.XX .

 

[mr-wolf]

But, email clients and webmail browsers seem to still disagree - they see the LE certificate as 'legit' for the domain but not for anything else?

Your email clients will NOT be satisfied in the future when the extension has been improved for webmail.
ONLY web browsers will be supported.

There is no multi-certificate solution for your mail clients (imaps, pops, smtps, smtp over TLS or imap over TLS).

You could use a scheme I'm using which involves a wildcard certificate:

Resolved - SSL certificates for mail server

 

[UFHH01]

... and we use Let's Encyrpt certificates for

DOMAIN.TLD
www.DOMAIN.TLD

and expanded these certificates with

autodiscover.DOMAIN.TLD

imap.DOMAIN.TLD
pop3.DOMAIN.TLD
smtp.DOMAIN.TLD
lists.DOMAIN.TLD
mail.DOMAIN.TLD
webmail.DOMAIN.TLD​

with the following DNS - records:

_autodiscover._tcp.DOMAIN.TLD. 14400 IN SRV  0 0 443 autodiscover.DOMAIN.TLD

autodiscover.DOMAIN.TLD. 3600 IN CNAME mail.DOMAIN.TLD

imap.DOMAIN.TLD. 3600 IN CNAME mail.DOMAIN.TLD
pop3.DOMAIN.TLD. 3600 IN CNAME mail.DOMAIN.TLD
smtp.DOMAIN.TLD. 3600 IN CNAME mail.DOMAIN.TLD

lists.DOMAIN.TLD. 3600 IN A XXX.XXX.XXX.XXX
mail.DOMAIN.TLD. 3600 IN A XXX.XXX.XXX.XXX
webmail.DOMAIN.TLD. 3600 IN A XXX.XXX.XXX.XXX

absolutely for FREE for all hosted domains and don't have any issues at all ( neither with webmail, nor with MS Outlook, nor with Thunderbird, nor with iPhone or any android phone ) - even "automatic renewing" and "autodiscover" works great.

Your email clients will NOT be satisfied in the future when the extension has been improved for webmail.
ONLY web browsers will be supported.

Absolutely wrong statement - sorry.

There is no multi-certificate solution for your mail clients (imaps, pops, smtps, smtp over TLS or imap over TLS).

Again, another absolutely wrong statement - sorry.




Additional note:
I think that Plesk should expand the Plesk Onyx and Plesk Let's Encrypt documentation, to avoid such returning posts @IgorG .

 

[mr-wolf]

AFAIK imap clients like Outlook or Apple mail do not use SNI to tell Dovecot which hostname it is using to connect.
Therefore there is no mechanism to provide that client with the proper certificate.
Of course I may be missing some information or trick, but what I think (for now) is that Plesk is indeed offering a LetsEncrypt certificate for your mail, but that certificate is more or less useless for a typical virtual host scenario where each client has its own hostname. This is what most users use Plesk for.

Does Plesk provide a way that different clients can connect with imap using Outlook using this scheme?

imap.client1.com
imap.client2.com
imap.client3.com
imap.client4.com

Dovecot (or courier) would need to provide the same certificate as the hostname which is used in the Outlook client.
AFAIK Outlook doesn't send an SNI when it connects (like Chrome, Safari and Firefox).

Again, I may of course be wrong.
But, are you certain Plesk provides you with a "trick" to pull this off?
If so, can you show me where Dovecot has all these certificates configured?

I want you to be right even, but I tried hard to find info if it's possibe to use more than 1 certificate for imaps or pops (993, 995).
If I would have found it I wouldn't have created a workaround for it.

On this page they promise to give a list of clients that doesn't work with SNI and ones that do:

SSL/DovecotConfiguration - Dovecot Wiki

With client TLS SNI (Server Name Indication) support
It is important to note that having multiple SSL certificates per IP will not be compatible with all clients, especially mobile ones. It is a TLS SNI limitation. See SSL/SNIClientSupport for list of clients known to (not) support S

TLS SNI Client Support
Works:

• Thunderbird (Linux)

Doesn't work:

• K-9 on Droid X2 (any Android?)
• Apple Mail (Mac OS X 10.10 and lower AND iOS 9.3 and lower)

That;s a very disappointing list and doesn't really help me further.
My guess is that all the Outlooks don't work either (with the possible exception of Outlook 2016)

Anyhow, even if it's a minority of clients (and it seems to be a majority) it's not a workable situation and my scheme is necessary to connect without getting confusing and disturbing messages (from the client's perspective) to our Dovecot server.

 

[UFHH01]

Hi mr-wolf,

Does Plesk provide a way that different clients can connect with imap using Outlook using this scheme?

=> #26

 

[mr-wolf]

Wonder if that works in real life.
It still means that this solution only works for SNI-enabled mail clients.

@UFHH01 you're not addressing that it relies on the mail clients supporting SNI. It's nice to see that Plesk's ready for that, but it doesn't help much if not all clients are working. Android and old Apple Mail appear to be the show stopper. I am very suspicious about Outlook (seeing how they treat other aspects of IMAP)

We can't force our users to change their mail clients.
I will do some tests, but will probably not use it because it does not work for all.

I'm sticking with my scheme. That same scheme also allows me to properly setup the clients for autodiscovery. Going back to the more friendly mail.client1.com would be nice, but would make the https autodiscovery a nightmare. Each client would then need an autodiscovery website. Now I can have a simple catch-all on my own domain with the wildcard certificate.

Provider (me)

wolf.com

On Dovecot & Postfix the certificate *.wolf.com
The clients will connect with client1-com.wolf.com. or client3-com.wolf.com.

provider zone

client1-com.wolf.com   IN CNAME mail.client1.com
client2-com.wolf.com   IN CNAME mail.client2.com
client3-com.wolf.com   IN CNAME mail.client3.com

client1 zone

mail.client1.com.                          IN A 15.20.10.10
autoconfig.client1.com.                IN CNAME        mail.client1.com.
_autodiscover._tcp.client1.com.   IN SRV 0 1 443 client1-com.wolf.com.

client2 zone

mail.client2.com.                          IN A 15.20.10.20
autoconfig.client2.com.                IN CNAME        mail.client2.com.
_autodiscover._tcp.client2.com.   IN SRV 0 1 443 client2-com.wolf.com.

part of Nginx config on each Plesk server

server {
    listen 15.20.10.20:443 ssl;
    server_name ~^[a-z0-9-]+[a-z0-9]-[a-z0-9]+\.wolf\.com$;
    root  /var/www/autoconfig_autodiscover;
.
.
.
.
server {
    listen 15.20.10.20:80;
    server_name ~^autoconfig\.[a-z0-9-]+\.[a-z0-9-]+$;

    root  /var/www/autoconfig_autodiscover;
.
.
.
.

 

[UFHH01]

Hi mr-wolf,

Wonder if that works in real life.

Well I use it on several servers with over 1000 domains... if this isn't "real life", I'm wondering about your definition and would like to ask you, if we have different ones.

@UFHH01 you're not addressing that it relies on the mail clients supporting SNI.

Well sorry... sometimes you can't have all desired wishes being fullified with a single configuration. I didn't see the need to tell you, that there are certainly as well eMail - clients, which don't support SNI and due to the fact that we can't change that, I recommend to use the ones which DO support it.

We can't force our users to change their mail clients.

No, you can't, but it is recommended for hosters to list compatible ( and up-to-date ) eMail-Clients. What you actually tell/recommend to your clients is totally up to you and should not be considered to be "Plesk-related" You might desire to open another thread in the forum => Home > Forum > General Discussion > Open Topics , if you desire proposals from other hosters and to ask them, how they are solving such issues.

Each client would then need an autodiscovery website.

Well, we solved that again with templates and pre-configured skeleton folder and files.

 

[mr-wolf]

Hi mr-wolf,


Well I use it on several servers with over 1000 domains... if this isn't "real life", I'm wondering about your definition and would like to ask you, if we have different ones.

Even if you are have a "different life" (I can only gratulate you with yours) it doesn't require that much imagination to know others aren't in such a fortunate position.
Our clients sometimes use

At the moment I'm trying to convince some organization (legal one even) that an IMAP-prefix named "INBOX" is a quite normal thing to have. Their brand new developed software can't cope with it and they now want to advice their (and our) client to seek another provider that doesn't use a prefix. I wonder what happens if I start mentioning SNI

Well sorry... sometimes you can't have all desired wishes being fullified with a single configuration. I didn't see the need to tell you, that there are certainly as well eMail - clients, which don't support SNI and due to the fact that we can't change that, I recommend to use the ones which DO support it.

So you're saying that you don't have clients trying to connect their 2009 MacBook or Android clients?

Android has an option to ignore SSL name mismatch that properly works.
The MacBook uses an exception dialogue and that one is flaky.
After renewing the certificate it suddenly stops (sometimes weeks after using it) and needs another confirmation of the exception. The user doesn't know what's going on as he's not reading it and sometimes this dialogue isn't presented at all.

I have no information of Outlook 2007, 2010, 2013 and 2016
All these versions are still being used by our clients.
I suspect the older versions are not supporting SNI.
What do you know about the SNI-capabilities of Outlook?
What about Windows Live Mail?

Mac OSX 10.10 is Yosemite.
This means Leopard, Snow Leopard, Lion, Mountain Lion, Maverick are all NOT compatible.
These Macs can't be updated over the Internet and most Macs in our client base are these old versions.

No, you can't, but it is recommended for hosters to list compatible ( and up-to-date ) eMail-Clients. What you actually tell/recommend to your clients is totally up to you and should not be considered to be "Plesk-related" You might desire to open another thread in the forum => Home > Forum > General Discussion > Open Topics , if you desire proposals from other hosters and to ask them, how they are solving such issues.

I see other hosters use their own hostname to be used on their mailservers.
This doesn't work well if your hosting platform consists of several Plesk servers where each server has some 200 domains.
I need to be able to direct them to another server without having them to change their way to connect to our servers.

Well, we solved that again with templates and pre-configured skeleton folder and files.

That's nice...
If I knew I might have waited for that.

But now I created the autodiscovery system myself and it works fine and it exactly fills my needs.
It consists of 2 PHP-scripts and an additional nginx config file for each server.
On the upside it doesn't rely on the LetsEncrypt service and Plesk doesn't need to touch my Dovecot and Postfix configs.

I do hope all this is optional and Plesk doesn't force me to use multiple certificates on Postfix/Dovecot when using LetsEncrypt!!!