在激活 ODBC 数据源和 TLS 的情况下创建与 SQL 服务器 2014 的连接时出现问题
Issue creating a connection to SQL server 2014 with ODBC data source and TLS activated
我正在尝试为我的应用程序创建/修改系统数据源，它需要通过 ODBC 数据源连接到我们的 Microsoft SQL Express 2014 数据库。
在我们启用 SSL 加密流程之前，该连接曾经有效，但是，
现在我们有一个加密的 link，连接不再有效。
以下是一些详细信息：
- 我们 运行 Microsoft SQL Server express 2014 SP1 具有最新的累积更新 (CU #3)（这是必要的，以便我们可以停用 SSL 3.0 和 TLS 1.0 和 运行 仅适用于 TLS 1.1 和 TLS 1.2)
- 数据库实例是命名实例，配置为 运行，具有 TCP/IP 连接和固定端口。
- 我们启用了 "Force Encryption" 选项并通过 "Sql Server Configuration Manager"
配置了证书
- 我们可以使用 Management Studio 或 SQL 命令行实用程序成功建立与数据库的连接
- 我们禁用了所有通过 Microsoft Schannel 完成的 TLS 1.1 版本之前的 SSL/TLS 使用。这要求我们将 SQL Express 2014 SP1 更新到最新的累积更新 (CU #3)
- 我们尝试配置（通过 ODBC 数据源管理器）的 ODBC 数据源是一个 "System DSN" 并使用 "SQL server" 驱动程序，目标服务器名称与在 Management Studio 中工作的服务器名称完全相同（其服务器名称对应于证书 CN 值中反映的计算机 FQDN）
- SQL 服务器 ODBC 驱动程序的版本是 "Microsoft SQL Server ODBC Driver Version 06.03.9600"
- 我正在直接通过 ODBC 数据源管理器工具测试连接。
- 第一个测试 运行 运行 在与托管数据库服务器的机器完全相同的机器上。
我们在 Microsoft SQL 服务器登录中收到两条连续的错误消息：
Connection failed:
SQLState : '01000'
SQL Server Error: 771
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionOpen(SECDoClientHandshake()).
Connection failed:
SQLState : '08001'
SQL Server Error: 18
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SSL Security error.
我查阅了所有我能找到的文献，但找不到解决方案。
编辑 2016 年 1 月 27 日 16:30
根据 erg 的建议，我尝试使用最后一个 MS SQL Server Native Client 版本（在我的系统上是 11.00.2100），但它仍然没有解决问题。不过，我遇到了另一个问题（无论我是否在客户端强制进行强加密都会导致同样的错误）：
Running connectivity tests...
Attempting connection
[Microsoft][SQL Server Native Client 11.0]TCP Provider: An existing connection was forcibly closed by the remote host.
[Microsoft][SQL Server Native Client 11.0]Client unable to establish connection
TESTS FAILED!
所以，经过一番努力，我终于成功了。
首先，SQL Server Express 2014 SP1 似乎还有另一个可用的 CU (CU4)。
我确实下载并安装了它，但它并没有解决我的问题：一旦我停用 TLS 1.0 和更低版本的 ODBC 就无法工作。
奇怪的是，尽管 CU3 和 .NET 4.6 的安装允许我在 Management Studio 中成功登录，但当我尝试执行
xp_readerrorlog 查询，它实际上失败了。
我为解决我的问题所做的是遵循马尔萨斯对另一个相关堆栈溢出问题的回答
https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0（从上数第 3 个答案）。
因此，我在我的计算机上激活了本地安全策略，并设法获得了指向我的 SQL 数据库的链接。
现在，我让 IIS 与我自己的服务和客户端一起工作。
顺便说一句，如果有人需要一种更加用户友好的方式来激活 SSL/TLS 版本和 Windows 上的加密算法，我偶然发现了一个不需要使用 regedit 的不错的 GUI 应用程序为此：
https://www.nartac.com/Products/IISCrypto。它是免费的，我不是 Nartac Software 的员工、经理或股东。
希望对您有所帮助！
EDIT Feb 25, 2016
It looks like the latest cumulative update (CU5 available at
https://support.microsoft.com/en-us/kb/3130926) removes the need to
activate the FIPS option for the System Cryptography.
I discovered this since I had to deactivate FIPS to enable another required
functionnality while still relying on a TLS 1.2 connection. Indeed, it
appears that activating the FIPS option for the System Cryptography prevents
.NET Framework to successfuly make use of some system algorithms (such as
SHA256Managed).
In addition, according to some discussions seen around the web (i.e.
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx)
it is not recommended to activate FIPS (except to strictly comply with
some governmental recommendations) since it breaks applications
relying on non-FIPS validated implementations of cryptographic
algorithms, which, however are provided in Microsoft system libraries.
我正在尝试为我的应用程序创建/修改系统数据源，它需要通过 ODBC 数据源连接到我们的 Microsoft SQL Express 2014 数据库。 在我们启用 SSL 加密流程之前，该连接曾经有效，但是， 现在我们有一个加密的 link，连接不再有效。
以下是一些详细信息：
- 我们 运行 Microsoft SQL Server express 2014 SP1 具有最新的累积更新 (CU #3)（这是必要的，以便我们可以停用 SSL 3.0 和 TLS 1.0 和 运行 仅适用于 TLS 1.1 和 TLS 1.2)
- 数据库实例是命名实例，配置为 运行，具有 TCP/IP 连接和固定端口。
- 我们启用了 "Force Encryption" 选项并通过 "Sql Server Configuration Manager" 配置了证书
- 我们可以使用 Management Studio 或 SQL 命令行实用程序成功建立与数据库的连接
- 我们禁用了所有通过 Microsoft Schannel 完成的 TLS 1.1 版本之前的 SSL/TLS 使用。这要求我们将 SQL Express 2014 SP1 更新到最新的累积更新 (CU #3)
- 我们尝试配置（通过 ODBC 数据源管理器）的 ODBC 数据源是一个 "System DSN" 并使用 "SQL server" 驱动程序，目标服务器名称与在 Management Studio 中工作的服务器名称完全相同（其服务器名称对应于证书 CN 值中反映的计算机 FQDN）
- SQL 服务器 ODBC 驱动程序的版本是 "Microsoft SQL Server ODBC Driver Version 06.03.9600"
- 我正在直接通过 ODBC 数据源管理器工具测试连接。
- 第一个测试 运行 运行 在与托管数据库服务器的机器完全相同的机器上。
我们在 Microsoft SQL 服务器登录中收到两条连续的错误消息：
Connection failed:
SQLState : '01000'
SQL Server Error: 771
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionOpen(SECDoClientHandshake()).
Connection failed:
SQLState : '08001'
SQL Server Error: 18
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SSL Security error.
我查阅了所有我能找到的文献，但找不到解决方案。
编辑 2016 年 1 月 27 日 16:30
根据 erg 的建议，我尝试使用最后一个 MS SQL Server Native Client 版本（在我的系统上是 11.00.2100），但它仍然没有解决问题。不过，我遇到了另一个问题（无论我是否在客户端强制进行强加密都会导致同样的错误）：
Running connectivity tests...
Attempting connection
[Microsoft][SQL Server Native Client 11.0]TCP Provider: An existing connection was forcibly closed by the remote host.
[Microsoft][SQL Server Native Client 11.0]Client unable to establish connection
TESTS FAILED!
所以，经过一番努力，我终于成功了。
首先，SQL Server Express 2014 SP1 似乎还有另一个可用的 CU (CU4)。
我确实下载并安装了它，但它并没有解决我的问题：一旦我停用 TLS 1.0 和更低版本的 ODBC 就无法工作。
奇怪的是，尽管 CU3 和 .NET 4.6 的安装允许我在 Management Studio 中成功登录，但当我尝试执行
xp_readerrorlog 查询，它实际上失败了。
我为解决我的问题所做的是遵循马尔萨斯对另一个相关堆栈溢出问题的回答 https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0（从上数第 3 个答案）。
因此，我在我的计算机上激活了本地安全策略，并设法获得了指向我的 SQL 数据库的链接。
现在，我让 IIS 与我自己的服务和客户端一起工作。
顺便说一句，如果有人需要一种更加用户友好的方式来激活 SSL/TLS 版本和 Windows 上的加密算法，我偶然发现了一个不需要使用 regedit 的不错的 GUI 应用程序为此：
https://www.nartac.com/Products/IISCrypto。它是免费的，我不是 Nartac Software 的员工、经理或股东。
希望对您有所帮助！
EDIT Feb 25, 2016
It looks like the latest cumulative update (CU5 available at https://support.microsoft.com/en-us/kb/3130926) removes the need to activate the FIPS option for the System Cryptography.
I discovered this since I had to deactivate FIPS to enable another required functionnality while still relying on a TLS 1.2 connection. Indeed, it appears that activating the FIPS option for the System Cryptography prevents .NET Framework to successfuly make use of some system algorithms (such as SHA256Managed).
In addition, according to some discussions seen around the web (i.e. http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx) it is not recommended to activate FIPS (except to strictly comply with some governmental recommendations) since it breaks applications relying on non-FIPS validated implementations of cryptographic algorithms, which, however are provided in Microsoft system libraries.