我需要为我的应用程序和 Sql Server 2008 之间的传输实现 SSL。
我正在使用 Windows 7、Sql Server 2008、Sql Server Management Studio，并且我的应用程序是用 c# 编写的。
我尝试按照 MSDN 页面上的说明创建证书，这在“特定客户端的加密”下，但我完全糊涂了。我需要一些小步骤才能更进一步成功实施加密。
首先，我不了解 MMC。我看到里面有很多证书……这些证书是我应该用于自己的加密还是用于已经存在的东西？还有，我假设所有这些证书文件都位于我的本地计算机上，那么为什么会有一个名为“个人”的文件夹？
其次，为了避免上述问题，我使用自签名程序集做了一个小实验。如上面的 MSDN 链接所示，我使用在 SSMS 中执行的 SQL 创建了自签名证书。然后我使用以下连接字符串进行连接：
Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword;Encrypt=True;TrustServerCertificate=True
它连接成功了，并且正常工作。然后我删除了刚刚创建的证书，它仍然正常工作。显然它什么也没做，但为什么不呢？我怎么知道它是否真的在“工作”？我想我可能错过了一个中间步骤（不知何故？）将文件从 SSMS 转移到客户端？
我根本不知道自己在做什么，所以如果您能给我提供任何帮助、建议、评论和参考，我将不胜感激。
先感谢您。 ：）
答案1
如果我正确理解了 MSDN 规范，您只需要在连接字符串中指定Encrypt=True;TrustServerCertificate=True。这意味着客户端请求加密和愿意接受服务器可能使用的任何证书。如果没有其他可用证书，服务器始终会在服务器启动时生成自签名证书以供使用。如果客户端愿意接受任何证书，那么它将接受该服务器的临时自签名证书，与任何证书一样好。
这样的设置提供了应用程序和服务器之间的加密通信通道，这个通道不容易被窃听。然而，这个通道很容易受到恶意的中间人攻击。如果攻击者可以欺骗客户端连接到他而不是服务器（例如，通过控制 DNS 记录，更确切地说是客户端将使用的 DNS 服务器 IP，这是一个很容易控制的 DHCP 设置），那么攻击者可以呈现任何证书，并且客户端会接受它，然后它可以与客户端进行完整的身份验证往返，从而获得使用的 SQL 用户名和密码，然后它可以连接到真正的服务器并来回转发所有通信，并可以自由查看所有内容。客户端永远不会知道正在被“监视”。这就是“中间人”攻击。
为了防止出现上述情况，客户端必须移除连接字符串TrustServerCertificate=True。完成此操作后，服务器使用的证书有客户端无法信任，这时所有的问题都出现了。如果你对较弱的设置没有意见，即你有加密流量，但你理解你可能受到中间人攻击，并且您对此没有异议，则使用更简单的TrustServerCertificate=True设置。如果不是，那么不幸的是，您必须真正了解自己在做什么，而且这并不容易。如果数据是所以重要，那么也许为你的服务器花点钱买一个 VeriSign、Thawte 或 GlobalSign（这是每个 Windows 客户端信任的 3 个根）证书（约 500 美元/年）并不是那么奇怪。
答案2
“个人”是证书存储的误导性名称。当您在 MMC 中时，如果您看到可以选择的证书，则可能没问题。我建议使用真正的证书。这可以是使用 Microsoft 证书服务器内部创建的证书，也可以是从证书提供商处购买的证书。我不会使用自签名证书。还必须重新启动 SQL Server 实例服务才能使其生效。
一些一般建议：
如果在客户端强制加密，则客户端上的所有 SQL 通信都必须使用传输级加密。
如果您在服务器上强制加密，则该实例的所有 SQL 通信都必须使用传输级加密。
无论您选择哪种配置（选择性或强制），您的应用程序仍然需要支持各种连接选项。例如加密连接关键字。
我个人发现 SQL Native 客户端比内置 SQL 客户端提供了更多描述性错误消息，但您可以使用/强制加密。
微软的文档有点粗略，但也有一些不错的文章：
选择性地使用与 SQL Server 的安全连接
关联
如何使用 Microsoft 管理控制台为 SQL Server 实例启用 SSL 加密
http://support.microsoft.com/kb/316898
将连接字符串关键字与 SQL Server Native Client 结合使用
http://msdn.microsoft.com/en-us/library/ms130822.aspx