I am going to try to explain an issue that has been persistent for over a year now.
We have a Linux hosted server CentOS 7.5 with Plesk 17.5 and we use the LetsEncrypt service to secure both web and emails.
Clients using the server for email mostly are on Apple mail. I am talking MacBook’s, iPhones and iPads.
Regularly (as in every 3 months) when the certificate renews we run into issues.
Sometimes your laptop will just work and your phone will stop sometimes both sometimes just laptop and the phone will be fine. No consistency.
In most cases where it doesn’t work on a laptop a pop up will show saying this certificate is unknown and cannot be trusted. You then view the certificate and hopefull there is an option there (I am saying hopefully because sometimes with mail that option isn’t there) you will go in and select “always trust” and confirm with your password and all will be fine.
On the iPhone it’s a little more tricky.
You also get a pop up but then once you view the certificate there is no “trust” option.
The only way you get to see a trust option on a certificate is if you go and delete your mailbox and then re-create it. Then you get the same “unknown certificate” pop up but this time when you view it there is a TRUST option in the top right hand corner.
Right. Add on top of that the fact that you can easily confuse a machine by acting wild with settings while it tries to sync all that to your wonderful (I am being sarcastic right about now) iCloud Keychain and you have it. All my users are going wild every three months and I am growing tired of deleting and recreating mailboxes just to be able to “trust” the certificate…
Isn’t there a better way to do this? Surely I am an ignorant and this is a bad setup .
All of you who are using Linux servers and Apple devices out there…
Please enlighten me.
Yes. You don't have white-labelled certificates for your mail server, so you can't white-label the MX records or mail client settings. (Well, you can, if you either don't use SSL (bad) or manually trust certificates (also bad)).
That's one of the disadvantages of using Plesk, it doesn't use a mail server that supports SNI.
The gist of the problem is even though those certificates exist, Plesk’s mail server is not capable of using them. So it just uses the server-wide certificate, which is only valid for pandora.
There’s no loss of security, since all the domains end up going to the same mail server anyway. The mail server doesn’t care what SSL name was used to connect to it.
Unfortunately you are missing the point. The issue here is not a wrong host name. The user is complaining that every three months, Apple mail cannot handle the Let’s Encrypt certificate renewal properly. And that is indeed an issue, but it is not caused by Plesk, but by Apple mail. Other mail clients do not have that issue and accept a renewed certificate flawlessly.
This is clearly an issue with Apple mail. The user does not experience any host name validation issues when setting up a new account, but only once the certificate for an existing account is renewed.This needs to be resolved by an Apple mail update.
Rubbish. There's no such issue or bug with Apple Mail. There are untold millions of Apple Mail clients that happily connect to mail servers protected with Let's Encrypt certificates without encountering any trust problems.
OP's problem is clear, his users' workaround was to manually trust the mismatched certificate (which of course has to be re-trusted every time it's re-issued).
What I find strange is that each domains I host have their own certificates and they all renew on a 3months basis. So why can’t it see a certificate corresponding to the right name?
Cheers
The issue occurs only after a certificate is renewed. If you were right with your hypothesis that the mailserver name is wrong, the issue would occur at all times, not only when a certificate is renewed.
The underlying problem is that Apple mail does not realize that the new (the renewed) certificate continues to validate the connection. It compares the hash to what's been previously stored and then comes to the conclusion that the certificate is invalid. For that reason it is a bug in Apple mail, because ALL other systems, e.g. Outlook, Thunderbird, have no issues with a renewed certificate. This has nothing to do with the host name that the user has set.
If you are hosting your site on a Plesk host, that host uses a single mail server and one single certificate to protect all connections to and from this single mail server. That mail server must be addressed by the host name, not the domain name. The certificate it uses is always made out to that host name.
The different certificates you have in your subscription accounts on the system do not protect the mail server, but only your WWW traffic, e.g. your domain and the webmail-subdomain. If you have specific questions on this, I invite you to talk.plesk.com where such issues are discussed more thoroughly.
Are you related to the OP? Because this seems like reading too much into their wording. I think they have been manually trusting the certificate "the first time" as well, not just at renewal.
Both of your links describe a UI issue where it's not possible to trust an untrusted (x.509 verification fails for whatever reason, including name mismatch) certificate when it has been renewed..
If the certificate is actually verified, then there is no issue, because there is no reason for the user interface to prompt the user.
I think the underlying problem is that the devices are missing the root certificate that can validate Let’s Encrypt certificates. For that reason the software thinks that the renewed Let’s Encrypt certificate is a self-signed, untrusted certificate. As the “continue” button that formerly existed in iOS mail for such cases is now missing in the later OS versions, the user cannot trust the extended certificate.
Both of you are onto something.
Yes it’s the exact UI symptoms we are encountering.
What I am reading from _az is that it also could occur on name mismatch.
It’s true that the error message that comes up always says pandora.theripplehub.net regardless of the domain email concerned.
I still don’t know for sure if changing the mail domain name on iOS to pandora.theripplehub.net would actually fix it, haven’t attempted the switch. And I guess I won’t know for sure until the 3 months renewal.
Don’t forget that iCloud has a keychain sync once you trust a certificate it is supposed to sync across devices and not ask you again… that in my experience works randomly…
In any case thanks for the input and effort. I am sure we have our fingers quite close to the reason.
I agree @_az, the “problem” is that Plesk, for smtp and imap servers, only uses a certificate covering your host name instead of all your configured domains so, (as @_az said in post 2) in your mail client you must use pandora.theripplehub.net to connect to your smtp/imap servers instead of the domain names.
Just a couple of tests connecting to your domains using smtp on port 25 and imap on port 143 (both using starttls), you will see that the certificate provided by your smtp and imap server is covering only pandora.theripplehub.net so if you try to connect with other domain name your mail client won’t trust it.
This can be shown, both by documentation and by experimentation, to be false. The DigiTrust root has always been trusted in iOS, and the ISRG root is now as well.
