概括
我无法获得 Let's Encrypt R3 颁发的证书以在 SQL Server 2019 上使用。当使用 SSL 证书但不明确信任服务器证书时（在 SSMS 中，我选中“加密连接”但没有选中“信任服务器证书”），所有身份验证都会失败并显示以下错误消息：
已成功与服务器建立连接，但在登录过程中出现错误。（提供程序：SSL 提供程序，错误：0 - 目标主体名称不正确。）（Microsoft SQL Server，错误：-2146893022）
服务器配置
我立即核实的事情：
- 该证书以及链中的所有证书都安装在计算机证书存储区中。
- SQL 服务器服务运行的用户对私钥具有读取权限。
- 该证书在配置管理器中已正确配置。
- 证书的通用名称与服务器的 FQDN 匹配。
- 该服务器在域内并可访问。
其他值得注意的事项：
- 服务器在命名实例上运行，而不是默认实例。
- 尽管这篇文章重点关注 SQL Server 2019，但我在 SQL Server 2022 上重现了该问题。
背景
我们目前正在从内部 CA 切换到 Let's Encrypt。由我们的内部 CA 颁发的 SQL 服务器证书（到目前为止一直在使用，最近已过期）可以正常用于加密连接，没有任何问题。但是，在安装 Let's Encrypt 颁发的新证书后，加密连接中断。我找到了添加TrustServerCertificate=true到受影响的连接字符串的解决方法，但我认为这不是永久解决方案，因为这似乎真的很不安全。
到目前为止我尝试过的
本地和远程身份验证均因相同的错误而失败。
本地帐户和域帐户的身份验证均失败。
正如预期的那样，在服务器端强制加密与否没有什么区别。
我得到的建议是 MSSQL 可能默认不支持 ECDSA，这是自 Certbot 2.10（我使用的 ACME 客户端）以来的默认密钥类型。据我了解，ECDSA 依赖于 TLS 1.2，而 TLS 1.2 确实未启用。我根据这篇文章编辑了注册表：https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings?tabs=diffie-hellman#tls-dtls-and-ssl-protocol-version-settingsServer。我在和中都启用了 TLS 1.2 Client，并默认启用它。客户端当前使用的所有其他协议都默认禁用并启用，以尽可能不造成中断。不幸的是，问题仍然存在。
同样，我尝试将参数传递--key-type rsa给 Certbot 来创建 RSA 密钥。这也没什么用。我注意到签名仍然使用 ECDSA，而旧证书具有 RSA 签名。这是我看到的两个证书之间的唯一区别。这会是个问题吗？
我还认为该错误听起来像证书通用名称与服务器 FQDN 不匹配，但事实并非如此。
如上所述，未加密的连接或信任服务器证书都是可行的。
我可以使用可能需要的任何配置/其他文件来编辑该帖子。
答案1
证书链可能仍然存在问题，因此请重新检查。
之后，确保您在证书管理中添加了数据库用户读取权限，而不是通过默认文件权限管理。
要做到这一点：
- 搜索“证书”并打开“管理计算机证书”。
- 打开个人逻辑存储，然后打开证书对象。
- 现在右键单击您想要设置权限的 SSL 证书。
- 在“所有任务”中选择“管理私钥...”
- 将打开一个单独的窗口，您可以在其中添加 SQL Server 用户。
- 添加用户时，设置读取和应用更改的权限。
现在重新启动 SQL Server 服务并祈祷它能正常工作。
我希望这个评论对你有帮助。