TLS 1.3
Idea shared by Chris - 6/23/2022 at 8:03 AM
We have rolled out Windows Server 2022 specifically to deploy TLS 1.3. 

There is a good post on here on how to enable TLS 1.3 QUIC for Webmail HERE
I believe MAPI/EWS is running through IIS so this should enhance those connections with HTTP/3 as well.

Upon testing, it looks like Smartermail is still running TLS 1.2 for SMTP and likely IMAP/POP too.

Requesting TLS 1.3 support for SMTP/IMAP/POP

8 Replies

Reply to Thread
I am sure it is coming, but they will need to move off of .net fwk to .net core.
Matt Petty Replied
Employee Post
Actually looking into it, it is something that looks like we can enable fairly easily for the TCP protocols. I'll add a note to discuss adding either to our upcoming production minor or at least to our next major version.
Matt Petty Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
We are on week 2 and seeing some instability with TLS 1.3 QUIC. We have had a few crashes last week and some new unexpected behaviors with the same build running on Server 2022. 

Today we had a blue screen crash and the faulty item is HTTP.sys

This is what happens when you want to be on the bleeding edge of technology I guess. 

For now, we are disabling TLS 1.3 and QUIC in IIS. If things don't become stable again, we are going to go back to Server 2019.

In the meantime, we will just wait until Smartertools officially supports TLS 1.3 (fully tested and validated) 


We had to disable QUIC as well after the security certificates for our domains were renewed. Apparently Microsoft's implementation relies on some kind of stapling to the certificate so if the certificate HASH changes from a reissue or renewal then it fails with all kinds of errors in IIS and becomes unstable.

We were able to keep running TLS 1.3 & HTTP/3 just fine in Win2K22 (although as noted this doesn't affect other SmarterMail services that run on ports other than 443 currently).
Ah... so you are saying just disable QUIC? 

Because currently I have both disabled.

That is correct. Just enabling the checkbox for "Disable QUIC" in your first example is precisely what we had to do once the certificates were renewed and the pinned/stapled HASH changed.

Note that this has to be done for EVERY binding for the site in IIS (you may only have one but we have something like 180 bindings for SmarterMail Enterprise as we have multiple branded portals each on their own domain and Static IPs). If even one binding doesn't have Disable QUIC checked then IIS will continue to throw errors for the site.

You can also enable "Disable Legacy TLS" on each binding rather than rely on IISCrypto to disable legacy protocols (this setting will only allow TLS1.2 and TLS1.3 connections) via port 443.
We have been using TLS 1.3 with Smartermail for over 6 months with a large base of over 11,000 mailboxes and not seen any issues with TLS 1.3.

We have had to keep TLS 1.0 and 1.1 enabled in SmarterMail as old versions of Outlook require TLS 1.0 as do ASP.NET 4 websites that send emails which by default uses TLS 1.0 unless you explicitly set in the code to use TLS 1.2.

QUIC on the other hand, is a different matter, we have disabled QUIC on all our Windows Server 2022 web servers due to problems. As well as server crashes their is a kernel memory leak with MS QUIC that will randomly consume all available memory on the server requiring a reboot to release the memory. We have reported the memory leak to the MS QUIC team.
I am happy to report that disabling QUIC has prevented it from crashing, going on 10 days now. TLS 1.3 is running with no issues so far. 

Reply to Thread