we have it too, it just means you arent using an SNI (more specific) cert, in our case a wildcard .. this is normal logging

We have this too.

AFAIK this message pops when SmarterMail can't find a certificate that matches the server name indication provided by the connecting client so it falls back to the main certificate that is configured in your port bindings.

For me this should be debug log as it spams a lot when you don't have a matching certificate matching the SNI installed in the new Certificates management stuff in latest builds.

We have IMAP sync issues on 8790 build and have locked the certificate to a specific IP.

I did this and waiting to see if the problems reappear...

https://serverfault.com/questions/579109/sni-and-wildcard-ssl-certificates-on-the-same-server-with-iis

I'm literally going crazy behind SSL certificates

Look here https://portal.smartertools.com/community/a95897/from-8664-to-8776.aspx

I did a lot of tests even spending money to buy certificates.

I also have an open ticket with SM but it seems they still know little about it either.

What I realized is that

1) Wildcard certificates create problems. Or rather they seem to work correctly as long as you load them into IIS with the name _.cert.pfx

But then if you run a test with a wildcard certificate on https://ssl-tools.net/mailservers it fails.

If you use a multidomain certificate as a fallback and a wildcard for IIS the test passes, but I also noticed that the fallback certificate is always used when looking at the logs. If you use the multidomain certificate also on iis for some reason it only works with the main dns name.

In short, it seems that you need to use a single domain certificate. That is, use its self-generation, but as it is it seems madness to me.

1) because I can't choose at domain level which ones to activate with customized SSL and which ones not.

2) why can't I choose at domain level which custom hostnames to generate ssl for?