Just to confirm... the 8846 update while it addresses some issues with Certificates, DOES NOT resolve this issue.  The same error messages continue to repeat over and over in my Certificates logs in SmarterMail.

The server seems to be working just fine however.

Is there a way to suppress these messages since they appear to be of little to no importance ?

Thanks for reporting this exception Rod, I've passed it along to development as we're looking at these areas currently.

Thanks Kyle, my biggest concern is what is going to happen when the LE Certs have to renew and can't update the certs in IIS to the new ones?  Am I going to have to deal with manually updating those every few months?   If so, I'll just move back to using my own implementation thru WACS with a series of powershell scripts to update the certs on the SM server.   But I'd love to just allow SM to manage those for me instead :)

You're very welcome Rod. We found in your case we're potentially having trouble with the certificate generation leading to the binding addition to fail. That binding addition is being handled ungracefully by IIS resulting in this recurring exception you're seeing. We're going to work on getting a fix in place for this for you! In the meantime, HTTPS binding addition and cleanup should be handled automatically if we're generating the certificates successfully, so you should not need to update these manually in the future. 

A little bit of additional detail here for you Rod! In your case specifically we were trying to clean up the duplicate binding but this too failed, and so we'll need to do this manually per the administrative log. Can you try removing that duplicate HTTPS binding, then highlight that hostname in Settings>SSL Certificates>Automatic Certificates and click ...>Resolve Conflicts? Please let me know how that works out for you!

Have tried over and over and I cannot get the mail.mydomain.com to remove the duplicate entry.

That cert is NOT in the IIS Certs itself.

So, to avoid conflicts I've had to just disable it in the SM interface.

And whether enabled or disabled, the Resolve Conflicts is grayed out on that entry in AutoCerts.

It may be helpful to have a way to "Show path to certificate" as an option?

That way if something is installed in a non-standard place (I don't think it is, but can't find it, so it must be)... that would allow at least knowing where SM "thinks" it is at.

This is all taking place on my test server at home BTW (can't remember if I mentioned that), so the company server is NOT impacted by this.

I test EVERYTHING at home before ever bringing the tech to the office for implementation.

The office server uses actual signed certs from our primary domain, so this would not impact us the same way there as we would never turn on "auto-certs" there.

Hey Rod thanks for your follow up on this. First, I wanted to provide some details on an issue I found this week while troubleshooting a customer environment. When this customer upgraded, they had the Hostname field for all domains set to mail.domain.com, in addition to having all system level hostnames set the same. In previous versions this resulted in some of the duplicate behavior you're noting, so I recommend going through the hostname fields in SmarterMail to make sure they're unique. The domain's should have mail.mail.%domain%.com (exchanging that %domain% for the domain you're working on, whereas the Settings>General hostname at the system level will typically reflect the default hostname your server identifies itself as when not communicating on behalf of a specific domain name. 

With that being said and outlined though, we introduced some fixes for that behavior which should help to prevent duplicate entries, and prevent the binding issues associated with them. As such, I recommend completing an upgrade to our new release and giving the SSL certificate setup another go. If this continues to give you trouble lets get a ticket submitted and we can take a closer look for you. Thanks Rod!

Not sure that will be an issue.   My home server is running the FREE edition of SM, so there is only the one domain.  But I can see where that could be an issue on our company server.  We have several hundred domains and all are on the server named    mail.domain.com.

I'll look into it a little more tomorrow... head is spinning today... way way too much going on :)

That should be a nice easy verification for you home server too which is nice! Sounds good Rod, let me know if you have any questions along the way or anything you'd like me to confirm. Take it easy Rod!

I updated to 8853 on my home server this morning.

During that update, I see this in the certificate logs:

[2024.03.29] 08:30:49.940 ACME: Attempting to load cert into IIS for hostname: mail.mydomain.com, useCentralizedStore: False, IIS Cert Store Location: , HasKeyStoreCert: True

[2024.03.29] 08:30:50.218 ACME: Removing existing binding (*:443:mail.mydomain.com) is already bound to mail.mydomain.com on port 443; https binding count 2

[2024.03.29] 08:30:50.239 ACME: Attempting to add binding (*:443:mail.mydomain.com) for mail.mydomain.com on port 443 in IIS using sslFlags: Sni

[2024.03.29] 08:30:50.404 ACME: Certificate for mail.mydomain.com has been bound into IIS using Machine Key storage: key mail.mydomain.com [SmarterMail] 3/21/2024 8:35 AM to 6/19/2024 8:35 AM

[2024.03.29] 08:30:50.495 ACME: Attempting to load cert into IIS for hostname: smartermail.mydomain.com, useCentralizedStore: False, IIS Cert Store Location: , HasKeyStoreCert: True

[2024.03.29] 08:30:50.533 ACME: Removing existing binding (*:443:smartermail.mydomain.com) is already bound to smartermail.mydomain.com on port 443; https binding count 2

[2024.03.29] 08:30:50.534 ACME: Attempting to add binding (*:443:smartermail.mydomain.com) for smartermail.mydomain.com on port 443 in IIS using sslFlags: Sni

[2024.03.29] 08:30:50.650 ACME: Certificate for smartermail.mydomain.com has been bound into IIS using Machine Key storage: key smartermail.mydomain.com [SmarterMail] 3/21/2024 8:35 AM to 6/19/2024 8:35 AM

[2024.03.29] 08:30:50.720 ACME: Attempting to load cert into IIS for hostname: webmail.mydomain.com, useCentralizedStore: False, IIS Cert Store Location: , HasKeyStoreCert: True

[2024.03.29] 08:30:50.784 ACME: Removing existing binding (*:443:webmail.mydomain.com) is already bound to webmail.mydomain.com on port 443; https binding count 2

[2024.03.29] 08:30:50.786 ACME: Attempting to add binding (*:443:webmail.mydomain.com) for webmail.mydomain.com on port 443 in IIS using sslFlags: Sni

[2024.03.29] 08:30:50.841 ACME: Certificate for webmail.mydomain.com has been bound into IIS using Machine Key storage: key webmail.mydomain.com [SmarterMail] 3/21/2024 8:35 AM to 6/19/2024 8:35 AM

[2024.03.29] 08:30:58.174 [194.169.175.10][16461684] SNI using fallback binding certificate mail.mydomain.com.pfx for (no hostname passed to SNI).

[2024.03.29] 08:31:48.561 [194.169.175.10][52809666] SNI using fallback binding certificate mail.mydomain.com.pfx for (no hostname passed to SNI).

[2024.03.29] 08:32:55.310 [194.169.175.10][60924714] SNI using fallback binding certificate mail.mydomain.com.pfx for (no hostname passed to SNI).

[2024.03.29] 08:33:49.801 [192.168.1.37][51148083] SNI using certificate mail.mydomain.com.pfx for mail.mydomain.com.

[2024.03.29] 08:34:01.828 [194.169.175.10][31597228] SNI using fallback binding certificate mail.mydomain.com.pfx for (no hostname passed to SNI).

[2024.03.29] 08:34:10.831 [192.168.1.37][41841570] SNI using certificate mail.mydomain.com.pfx for mail.mydomain.com.

[2024.03.29] 08:35:07.730 [194.169.175.10][21419099] SNI using fallback binding certificate mail.mydomain.com.pfx for (no hostname passed to SNI).

[2024.03.29] 08:36:14.233 [194.169.175.10][16633417] SNI using fallback binding certificate mail.mydomain.com.pfx for (no hostname passed to SNI).

With regards to the hostname setup and physical machine name...

Physical Machine Name:   MAIL2022

Hostname in SM:  mail.mydomain.com

Checking the office SM server this morning as well.... (on 8451)

Physical machine name:  SmarterMail17s

Hostname on primary domain: sm-mail.mydomain.com

Spot checking a dozen other domains, they too are all using that same hostname.

So, we are NOT duplicating the physical name with the hostname, but we are using the same hostname across all the domains.  What SHOULD this be set to ?

Let's work from an example so there is no confusion on terminology... I have currently:

acadiancandles.com     hostname: sm-mail.mydomain.com

appsmn.com    hostname:  sm-mail.mydomain.com

basales.com   hostname:  sm-mail.mydomain.com

mydomain.com    hostname:   sm-mail.mydomain.com     (the primary domain)

What should those be changed to for SM to be "most happy" with ?

And... if we are NOT going to be implementing the AutoCert on the office server, is there any NEED to make those changes ?