• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

Issue plesk postfix TLS SNI smtp.mydomain.de from unknown [..] not matched, using default chain

PeterKi

Regular Pleskian
My system log always lists the above errors.
I am running Ubuntu 16.04.6 LTS with Plesk Obsidian Version 18.0.23 Update #2 with 2 domains and lets encrypt certificates.
I followed the guide at How to secure a Plesk mail server with different SSL certificates (SNI support)
If I run the given scriptlet on mydomains
echo 'Q' | openssl s_client -connect localhost:465 -servername mydomain -showcerts 2>&1 | grep -Eo 'CN=[^/]+' | uniq
I get the expected results
CN=mydomain.de
CN=Let's Encrypt Authority X3
CN=DST Root CA X3
What can I do do to get rid of these errors?
 
We are getting the same issue on
CentOS Linux 7.9.2009 (Core)
Plesk Obsidian Version 18.0.34 Update #2

We are only doing the email for the domain so can't get a letsencrypt cert to install.
Under the email settings
SSL/TLS certificate for mail says "not selected"
And there is nothing to be selected in the drop down.
 
Looks like Postfix uses the default SNI chain since no SNI configuration exists for smtp.mydomain.de
Check it with:

# postmap -s /var/spool/postfix/plesk/certs | awk '{print $1}' | grep mydomain.de

As a possible workaround try to Change the MX record for mydomain.de to mail.mydomain.de or mydomain.de:

# dig MX mydomain.de +short
10 mail.mydomain.de.
5 mydomain.de.
 
@Jllynch In your setup, the "error" message is the expected behavior and correct. There is no issue, it is simply a statement that no SNI configuration is present for smtp.yourdomain.tld. It's not harmful to the traffic.

For the original poster the same is true, because in his certificate he has not secured "smtp.domain.tld", but "domain.tld", so there is no matching cert for the wrong SMTP server name that he was using. The log message is merely a warning, but mail still works even if there is no match for the certificate.
 
@Jllynch In your setup, the "error" message is the expected behavior and correct. There is no issue, it is simply a statement that no SNI configuration is present for smtp.yourdomain.tld. It's not harmful to the traffic.

For the original poster the same is true, because in his certificate he has not secured "smtp.domain.tld", but "domain.tld", so there is no matching cert for the wrong SMTP server name that he was using. The log message is merely a warning, but mail still works even if there is no match for the certificate.
Is there a way to issue a Let'sEncrypt cert when the hosting and DNS is elsewhere for a domain? It can't just put a file in the root of their web for authentication...
 
Domain validated certificates are called domain validated, because they require to have a domain (with disk space) for their validation. If the web space is not hosted on the system, the Let's Encrypt token file cannot be written or read, hence the certificate cannot be issued for the server.
 
@Bitpalast, @Sebahat.hadzhi
This issue still persist and creates unnecessary log entries. Looks like the issue is simple to reproduce:

Assume Plesk is managing the following domains:
a.com (and potentially also more domains such as...)
b.com
c.com

And the server name itself is server.a.com (i.e., also myhostname in /etc/postfix/main.conf is configured to server.a.com). In addition, server.a.com is listed as MX for all domains. In that case, you get the following warnings in /var/log/mail.log:

Oct 9 19:00:08 server postfix/smtpd[2460031]: TLS SNI server.a.com from 4.3.2.1.a.myprovider.com[1.2.3.4] not matched, using default chain

It looks like the issues is that Plesk does not add the domain and its keys to /var/spool/postfix/plesk/certs.db (where
tls_server_sni_maps = hash:/var/spool/postfix/plesk/certs points to). However, according to the Postfix documentation this should be done:
Note that the SNI lookup tables should also have entries for the domains that correspond to the Postfix SMTP server's default certificate(s). This ensures that the remote SMTP client's TLS SNI extension gets a positive response when it specifies one of the Postfix SMTP server's default domains, and ensures that the Postfix SMTP server will not log an SNI name mismatch for such a domain. The Postfix SMTP server's default certificates are then only used when the client sends no SNI or when it sends SNI with a domain that the server knows no certificate(s) for.
 
Back
Top