我们希望通过互联网安全地连接到 SQL 2008 R2 以进行报告。对于这些较小的数据集，速度并不是一个大问题，用户将使用需要 ODBC 连接的简单报告程序（例如 Access），而不是某种 API。在这种情况下，我们在本地网络（例如 sql.mydomain.local）上运行 SQL Server，该服务器通过 NAT（例如 sql.mydomain.com，端口 xyz）从外部世界访问。这在没有安全性的情况下可以正常工作，但是我们需要加密连接。简单的方法是将 SSL 添加到 SQL 服务器。不过，这是我遇到问题的地方：
- 如果我获得外部名称 (sql.mydomain.com) 的证书，SQL Server 会拒绝查看或使用外部 SSL 证书，因为它不是服务器名称或 FQDN，因为它是在本地配置的（根据http://technet.microsoft.com/en-us/library/ms191192.aspx）。通过 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.x\MSSQLServer\SuperSocketNetLib 手动添加证书似乎并没有改变这种行为。
- 如果我使用来自域控制器的自签名证书，我可以在 SQL 中查看和使用该证书。但是外部连接显然会抱怨该证书不受信任。如果我将域控制器添加为受信任的发布者，那么当我尝试连接到它时，SQL 会抱怨服务器名称与证书名称不匹配。
所有前进的道路看起来都有点奇怪：1. 为具有公共名称的服务器设置一个本地域（例如 mydomain.com），并将机器添加到那里，以便 FQDN 与受信任发布者生成的外部证书相匹配，希望 SQL 能够看到并使用该证书。2. 让用户修改他们的主机文件以创建 sql.mydomain.local 到 sql.mydomain.com 的 cname。
我到目前为止的理解中是否遗漏了什么？有没有办法绕过 SQL 关于使用非 FQDN 证书的限制？如果我为 sql.mydomain.com 购买了主题备用名称为 sql.mydomain.local 的证书，SQL 会看到并使用它吗？
答案1
这个问题的答案是使用主题备用名称证书，这样 SQL 就会顺利运行。我使用域颁发的证书进行了测试，并遵循了以下一些出色的步骤：https://web.archive.org/web/20160523005214/http://www.williamdurkin.com/2013/03/sql-server-connection-encryption-and-net-framework-4-5/
SQL Server 可以看到并使用该生成的证书，并且一旦域证书被添加为受信任的发布者，客户端就能够安全地连接。