How to assign an SSL certificate per domain to secure the mail server in Plesk (SNI support)?

Follow

Comments

71 comments

  • Avatar
    Hüseyin Şevki TOPUZ

    Did not work, still receiving main domain's ssl information. Is there a method for doing this manually?

    0
    Comment actions Permalink
  • Avatar
    Mariano Loo

    Anyone was able to resolved this issue... Keep getting MISMATCH SSL with emails

    0
    Comment actions Permalink
  • Avatar
    Nicola Urbinati

    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,

    0
    Comment actions Permalink
  • Avatar
    kalin clements

    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

    1
    Comment actions Permalink
  • Avatar
    kalin clements

    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.

     

     

    1
    Comment actions Permalink
  • Avatar
    Mark (Edited )

    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.

    0
    Comment actions Permalink
  • Avatar
    kalin clements

    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.

    0
    Comment actions Permalink
  • Avatar
    Mark

    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.

    0
    Comment actions Permalink
  • Avatar
    Mark

    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

    0
    Comment actions Permalink
  • Avatar
    Pleskadminlinux

    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):

    • How can we configure webmail.customerdomain.tld as a server name indication (SNI)?
    • A good and easy improvement to PLESK was add webmail.customerdomain.tld as a server name indication (SNI) by default.
    0
    Comment actions Permalink
  • Avatar
    Yocu

    Dear Mikhail,

    I have a plesk server running on ubuntu 20.04.5. I can use your script and everything is fine, but: it is still impossible to connect with thunderbird 102.2.2 (64bit) running on linux.

    I have also checked https://support.plesk.com/hc/en-us/articles/360015529259-How-does-mail-autodiscover-function-work-in-Plesk, these requests are working fine, too.

    I have configured https://talk.plesk.com/threads/unable-to-connect-with-imap-via-mail-client-webmail-works.362352/. If I use the autodiscover url I always get 'failed to verify the legitimacy of the server and therefore could not establish a secure connection to it"'

    I wonder, because certificates are well configured. I do not know the reason, can you help?

     

    0
    Comment actions Permalink

Please sign in to leave a comment.

Have more questions? Submit a request