修复 SQL Server 加密错误 - 一键解决方案

阅读错误 - 这是信任问题，而不是网络问题

您的网络良好并且服务器正在运行。连接到达 SQL Server，服务器为登录提供加密通道，但您的 PC 拒绝了它，因为证明服务器身份的证书不是由您的 PC 信任的任何人签署的。 SSMS 显示的完整错误是：

默认情况下，SQL Server 使用它自己创建的自签名证书来保护登录。自签名证书确实会加密流量，但它无法证明服务器确实是您的服务器，因此要求经过验证的加密的客户端会拒绝它。每个诚实的修复都是以下两件事之一：让客户端在知情的情况下接受此特定服务器（步骤 2 和 3），或者为服务器提供客户端信任的证书（步骤 4）。

SSMS 中的快速客户端修复 - 信任服务器证书

这是视频中显示的快速路线。它不会改变服务器上的任何内容；它告诉这个连接接受服务器的证书，而不检查谁签署了它。在 SSMS 连接到服务器窗口中，单击选项打开额外选项卡，转到连接属性选项卡，将加密设置为强制（或保留为所提供），勾选信任服务器证书，然后单击连接。登录立即完成。

应用程序连接字符串内的相同修复

如果应用程序失败而不是 SSMS，则相同的交换机将保留在其连接字符串中。显式添加两个设置 - Encrypt=True 打开受保护通道，TrustServerCertificate=True 是 SSMS 复选框的连接字符串拼写：

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

使用您自己的服务器名称、数据库和登录名来代替示例值。这种权衡与步骤 2 中的复选框完全相同，但有一个额外的危险：在交付的应用程序的配置中，跳过的检查会无形且永久地应用于每个用户。将其保留在开发和暂存配置中，并在生产中将其视为借用时间，直到步骤 4 中的服务器证书就位。

正确的修复方法 - 为服务器提供真实的证书

永久修复在服务器上发生一次，然后每个客户端都严格连接，没有复选框，也没有警告。首先，使用服务器身份验证从内部证书颁发机构或公共 CA 获取服务器完整 DNS 名称的证书（例如 sql01.company.local）。将其及其私钥导入到 SQL Server 计算机上的本地计算机证书存储中。然后右键单击该证书，选择所有任务→管理私钥，并授予 SQL Server 服务帐户对私钥的读取权限。打开SQL Server 配置管理器，展开SQL Server 网络配置，右键单击MSSQLSERVER 协议，选择属性，然后在证书选项卡上选择证书。在标志选项卡上，您还可以将ForceEncryption设置为是，以便每个客户端都需要加密。重新启动 SQL Server 服务 - 在您重新启动之前，更改不会执行任何操作。

以严格的方式验证修复

悄悄成功的登录证明比人们想象的要少，因为某些设置组合在没有真正保护的情况下进行连接。证明两半。首先，以严格的方式从客户端重新连接：使用服务器的 DNS 名称（证书内的名称）进行连接，将加密设置为“强制”，并取消选中信任服务器证书。登录应该成功且没有任何警告。然后，在同一会话中，通过在 SSMS 中运行以下查询来询问服务器连接是否实际上已加密：

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option 显示 TRUE 表示及格。如果登录有效，则为 FALSE 意味着通过放弃保护连接成功，并且工作尚未完成。通过测试才是真正的终点线：任何正确配置的客户端（包括未来的 SSMS 版本）现在都可以通过完全验证进行连接，无需特殊设置。