Applicable to:
- Plesk Obsidian for Linux
- Plesk Obsidian for Windows
Question
How to assign an SSL certificate per domain to secure the mail server in Plesk (SNI support)?
Answer
Requirements
Warning: If you're switching from Courier to Dovecot be aware of potential issues.
-
Issue a Let's Encrypt certificate for a domain, or upload a paid certificate
-
For each of the domains that should have a separate mail certificate, navigate to Domains > example.com > Mail > Mail Settings
-
Select the domain's certificate in SSL/TLS certificate for mail dropdown:
-
Click on Apply
-
Verify that the separate mail certificate is used:
-
On Windows:
-
Connect to the server via RDP
-
Run OpenSSL with the mail server's domain and check the certificate's CN field:
PS echo 'Q' | plesk sbin openssl s_client -connect localhost:465 -servername example.com -showcerts 2>&1 | SLS -Pattern 'CN=[^/]+' | % { $_.Matches } | % { $_.Value } | Get-Unique
CN=example.com
-
-
On Linux:
-
Connect to the server via SSH
-
Run OpenSSL with the mail server's domain and check the certificate's CN field:
# echo 'Q' | openssl s_client -connect localhost:465 -servername example.com -showcerts 2>&1 | grep -Eo 'CN=[^/]+' | uniq
CN=example.com
-
-
Comments
70 comments
Did not work, still receiving main domain's ssl information. Is there a method for doing this manually?
Anyone was able to resolved this issue... Keep getting MISMATCH SSL with emails
Hi,
I'd like to change the server name from domain.com to smtp.domain.com (as I'd like to keep domain.com proxied in Cloudflare)
Is that possible? How?
Thank you,
Plesk, please help - we're trying to solve this issue as well.
We're using CentOS7, Postfix & Dovecot. No Premium Plesk Email. We've verified that SNI is on, and that ports 465 and 995 are being listened to by postix & dovecot respectively according to netstat.
We've been testing this on numerous servers and domains - some that integrate cloudflare and some that do not - just to try and explore all possibilities. So far, it seems that it's strictly related to Plesk and have found no fix.
Currently we and all our clients are having to the server names like servername.ourdomain.com for all POP/SMTP traffic. (the mail SSL for the server is setup set in Plesk>Tools & Settings>SSL/TLS Certificates) That works fine, but mail.clientdomain.com would be much better and for future migrations we don't have to tell each one to change their mail server settings.
To clarify, for the most recent test moments ago:
We re-issued an SSL to a clean, non-Cloudflare domain (we'll call it clientdomain.com) that previously did not have the "Assign the certificate to the mail domain" checked.
Previously, the "openssl s_client..." command lookup for mail.clientdomain.com resulted in showing the CN of the server itself like servername.ourdomain.com . But this results in a domain/certificate error is apps like Outlook.
Once the SSL was re-issued with "Assign the certificate to the mail domain" checked, the "openssl s_client..." command for mail.clientdomain.com results in a CN of clientdomain.com .
So that's close, but no cigar since that's still technically not the mail.clientdomain.com that outlook is trying to connect to. Therefore another SSL/certificate error.
If we try to connect simply to clientdomain.com as the mailservers in outlook, the connection times out.
Also see this related issue: https://talk.plesk.com/threads/lets-encrypt-and-assign-the-certificate-to-mail-domain-problems-and-autodiscovery-issues-caused-by-this.360307/
The command referred to above to check the CN is:
#echo 'Q' | openssl s_client -connect localhost:465 -servername mail.clientdomain.com -showcerts 2>&1 | grep -Eo 'CN=[^/]+' | uniq
netstat command to check port listening:
#netstat -tlnp | grep 995
Actually we may have just found a workaround, although it requires additional steps and waiting.
On another domain (let's say thedomain.com) we re-issued its certificate using a wildcard certificate and "Assign the certificate to the mail domain".
To do so requires adding the provided TXT record to the domain's DNS and then waiting for it to be publicly propagated.
After finishing the wildcard SSL installation, the "openssl s_client..." still yields a CN of thedomain.com WITHOUT any mail. subdomain in front. However, Outlook sent/received using mail.thedomain.com without any complaint or SSL issues whatsoever.
But ideally, Plesk would fix this for us so that the checkbox in the domain settings work and a wildcard SSL isn't required for it to work.
Magestyx, I can confirm the issue and work around. To me this sounds like a recent issue or did this never work as it should? I rather not use 'Wildcard SSL/TLS certificate' if I don't have to.
So the bug seems to be: "Assign the certificate to the mail domain" does exactly what it says but not exactly what I would expect: it assigns the created certificate to the mail server for use with IMAP, POP, SMTP but it does not take care of a certificate for mail.domain.tld. mail.domain.tld SSL will only work after a Wildcard SSL/TLS certificate is created.
Hi, Mark.
I agree - it's preferable to not use Wildcard SSLs and for this just to work as it's supposed to.
I can confirm that this a new issue. Our old/previous servers were using CentOS6 and only a slightly older version of Plesk. We had a number of clients using mail.theirdomain.com as their mail servers. So it was definitely working then. We updated/migrated all clients and domains to new CentOS7 systems with the latest Plesk, and that's when we noticed the issue and have been troubleshooting ever since. The servername.ourdomain.com method works fine for now, but if/when we have to migrate to the next gen of servers it could require us having to contact each of these clients and have them change their mail server to differentservername.ourdomain.com - which takes a TON of extra time.
So really it's just up to Plesk to fix this issue.
Regarding the secondary thread you mentioned - that'd be a separate issue since I don't see how Let's Encrypt could verify a domain with the A record pointed elsewhere. Unless of course the A record is simply a proxy to the real server location like when using Cloudflare. Let's Encrypt has to write files to the server being secured and then verify those files, so pointing the record totally somewhere else seems like would totally break its verification method.
Perhaps Plesk removed the feature to secure mail.domain.tld in favour of using *.domain.tld to secure POP/SMTP/IMAP because Plesk cannot do a HTTP-01 challenge for mail.domain.tld and therefor it can only validate using a DNS challenge. Since a DNS challenge is already being done for *.domain.tld a separate DNS challenge for mail.domain.tld became absolute.
Unfortunately they seem to have forgotten those of us that do not use *.domain.tld SSL.
Plesk created this Uservoice request for me but I do not think it or my reply to it give the best explanation or possible solution: https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/45565207-issuing-let-s-encrypt-certificates-for-mail-domain
We have clients that only have email service. We don’t have web or dns hosting. This doesn’t allow the use of customerdomain.tld as mail server on email client.
A good workaround was add webmail.customerdomain.tld as a server name indication (SNI):
Please sign in to leave a comment.