Database Mail Breaks with TLS 1.0 Disabled

Discovery

I ran across an issue where I had just configured database mail on a new server, went to send a test email, and I waited to receive it.  I waited…and waited…and waited, but still nothing.  I started to investigate and verified that database mail was indeed enabled, Service Broker was running, and the mail queue was started and running.  I went to go look at the sysmail_allitems view to see the status of my test emails to find that the sent_status column showed them as unsent.  The only errors I could find were these:

Log: SQL Server Agent
Message
[474] Unable to refresh Database Mail profile Server Mail. (reason: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException: Mail configuration information could not be read from the database.
System.Data.SqlClient.SqlException: profile name is not valid at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.Td)

Log: SQL Server Agent
Message
[260] Unable to start mail session.

I spent the better part of a day trying to figure this out.  Those error messages were not exactly helpful in pointing to the root cause.  Since this was a new server that I did not build myself nor did I install SQL myself I decided to uninstall and reinstall SQL.  When I ran the install it failed and upon investigation of the install log file I found an error that pointed me toward the issue.

Error: 17182, Severity: 16, State: 1.
2016-03-23 14:49:21.08 spid12s     TDSSNIClient initialization failed with error 0x80090331, status code 0x80. Reason: Unable to initialize SSL support. The client and server cannot communicate, because they do not possess a common algorithm.

At this point I knew I had a protocol issue.  The thing to note here is that this is actually blocking the install of SQL Server and I’ll explain why that is in just a minute.

Why

You may recall something called the POODLE attack that revealed a vulnerability in SSL 3.0 and TLS 1.0.  This particular server had SSL 3.0, TLS 1.0, and TLS 1.1 disabled in the registry.  Also note that TLS 1.2 was NOT disabled.  The server was running Windows 2012 R2.  These protocols were disabled to prevent the possibility of a POODLE attack.  If you are wondering how to disable these protocols on your servers then look at Microsoft Security Advisory 3009008.  To disable them for the whole OS scroll down to the Suggested Actions section and look under the heading “Disable SSL 3.0 in Windows For Server Software”.

I also want to note that the PCI Security Standards Council pushed back the date for getting off of SSL and TLS 1.0 to June 30th, 2018.  In addition to that, it should also be noted that Microsoft’s Schannel implementation of TLS 1.0 is patched against all known vulnerabilities.

You might be wondering how SQL Server was originally installed if having the protocols disabled prevented my subsequent installation attempt.  The reason is that the registry changes to disable them was made after the original install of SQL Server.  I’m glad this error happened on my subsequent install or I might not have ever figured this out.

Database Mail Breaks

So far the only issue I have run across by disabling these protocols (post installation) is that Database Mail can’t send emails and they just queue up with only the above vague messages.  The one that says it is unable to refresh a profile is an error and the other one is a warning in the SQLAgent log.  Most people don’t have alerts raised for this and if you sent those via Database Mail, you’ll never get them anyway.  This is where I want everyone to be cautious.  If these protocols have been disabled (and you may not be aware of it) then you will not get alerts for things like failed SQLAgent jobs that could be backing up your DBs or Hard IO errors, etc…  That means you could have issues on your SQL Server and might not even know about it, because the email notification is just sitting in the queue.

The Cause

The reason this issue exists is because Database Mail does not yet use the .Net Framework 4.6.1.  That is the newest version of the Framework and the only one that supports TLS 1.1 and TLS 1.2 for SMTP.  The .NET framework version 3.5 SP1 and earlier did not provide support for applications to use TLS 1.2 as a cryptographic protocol. In the update below they enabled the usage of TLS 1.2 in the .NET Framework 3.5 SP1.

The Fix

Microsoft could have fixed this in two different ways.  The first is that Database Mail be changed to utilize the .Net Framework 4.6.1 if it is installed.  The second is that the old versions of the .Net Framework be changed to support TLS 1.2.  As mentioned above, Microsoft chose option number two and just released a fix.  Check out THIS ARTICLE to obtain the fix.  The article will help you decide if you are running a vulnerable version or not and obtain the correct fix if needed.