This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(25.6, 47%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJ%3C/text%3E%3C/svg%3E)
We use an IIS SMTP server to relay emails from older scanners that don't support TLS to MS365 anonymous relay, which requires TLS. We're replacing an existing WS2012R2 server with SMTP with a new WS2022 server with the SMTP feature installed.
The WS2012R2 SMTP server finds its TLS cert. The WS2022 server does not.
We have a CNAME for the WS2022 server in internal DNS, 'relay.domain.net'.
We have a self-cert whose subject is 'relay.domain.net' in the Personal and Trusted Root CA's stores of Certificates.msc. When I open the cert, it shows, "You have a private key that corresponds to this certificate.", and Certificate Status is "This certificate is OK."
In the SMTP Virtual Server, Delivery-->Advanced-->Fully-qualified domain name is set to 'relay.domain.net', and Check DNS reports the name is valid.
Pretty sure that's all I've ever had to do to get the cert to be used by SMTP service on any other Windows Server in the past.
But here, I restarted the SMTP service--and for that matter, the server--and the Access tab still reports "TLS is not available without a certificate," and the Windows Service event log shows smtpsvc event 2001, "No usable TLS server certificate for SMTP virtual server instance '1' could be found. TLS will be disabled for this virtual-server." as the SMTP service starts.
Am I missing something? If not, is there a place I can kick it to make it work?
All Windows/IIS SMTP components became deprecated ever since Windows Server 2003 went end of life,
So, use search engines to see what alternatives (likely from third parties) you can migrate to.
Hmmm. Yes, I've seen that posted elsewhere. Irrelevant. Deprecated differs from unsupported. Just means it's not being developed. Since SMTP hasn't changed much since long before 2003, that's cool with me. And I can continue to leverage 2 decades' knowledge of using it. If MS wants me to stop using it, they need to stop including it in Windows Server. Since deprecation, it's been included with WS2008, WS2008 R2, WS2012, WS2012 R2, WS2016, WS2019 and WS2022. There doesn't seem to be much danger of it going away. If it does, I'll look elsewhere then. Until then, IIS SMTP Server is more than functional enough for this use.
And as it turns out, it IS functional. While the cert isn't displayed in the GUI as it should be, it is being used to encrypt the emails, because MS365 is accepting them for relay. The problem was cosmetic.
As IIS SMTP Server is deprecated, the bug will never be fixed. And given that it's icky on-prem stuff, a cosmetic bug wouldn't get much attention from MS these days, even if it wasn't deprecated. But I can live with deprecation and cosmetic bugs as long as my client can continue to scan-to-email from their obsolete copier via MS365. And they can.
I know this is a post that is 2 years old now. You have encountered a bug in the MMC snap-in for IIS 6.0 that is used to manage the Microsoft SMTP Service. When the snap-in the SMTP FQDN (the one present in the Advanced Delivery settings), it does not look at the certificate's common name, it looks in the SAN (subject alternative name) list. The bug is that it looks only at the first entry of the SAN list, so if you have the FQDN at any position other than the first one, the snap-in won't find it.