添加TrustServerCertificate=true仍遇SSL证书验证错误的ADO连接问题

首先，咱们先搞清楚为什么你加了TrustServerCertificate=true没生效——大概率是参数的使用方式不对，或者驱动的特定要求没满足。我来拆解一下：

可能的原因 #

• 参数格式兼容问题：MSOLEDBSQL驱动对TrustServerCertificate参数的标准兼容写法是用Yes/No而非true/false，部分旧版本驱动对布尔值的解析更认可前者；另外要确保参数放在连接串的合理位置，避免被其他参数干扰解析。
• 驱动版本限制：如果你用的是较早的MSOLEDBSQL版本，可能对该参数的支持不完善，建议升级到2018年后发布的稳定版（比如18.x系列）。
• SQL Server端强制加密冲突：如果你的SQL Server实例设置了Force Encryption = Yes，单纯加信任证书参数可能不够，需要配合Use Encryption for Data=Yes一起启用加密并信任证书。

正确的连接串写法 #

试试这个调整后的标准化连接串：

cnTemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;Authentication=SqlPassword;User ID=sa;Password=secret;DataTypeCompatibility=80;TrustServerCertificate=Yes;Use Encryption for Data=Yes;"

这里的关键细节：

• 用TrustServerCertificate=Yes替代true，适配更多驱动版本
• 将加密相关参数放在连接串后半段，确保驱动能在触发SSL验证前解析到
• 保留Use Encryption for Data=Yes，适配SQL Server强制加密的场景

额外排查步骤 #

如果上面的连接串还是无效，可以试试这几个操作：

• 检查驱动版本：打开ODBC数据源管理器，查看已安装的MSOLEDBSQL驱动版本，确保是2018年重新发布后的版本，旧版本可能不支持该信任参数。
• ODBC测试验证：先通过ODBC数据源管理器创建一个MSOLEDBSQL驱动的DSN，手动勾选「Trust server certificate」选项，测试连接是否成功。如果成功，直接复制生成的连接串到VBA中，排除代码层面的问题。
• 简化连接串测试：先去掉非必要参数（比如DataTypeCompatibility=80），只保留核心连接和加密参数，确认能正常连接后再逐步加回其他参数。

为什么之前的参数无效？ #

最常见的几个场景：

1. 你使用的true值在部分旧版驱动中不被识别，换成Yes就能触发信任逻辑；
2. 参数位置靠前，驱动在解析到该参数前就已触发SSL证书验证，导致参数未生效；
3. 驱动版本过旧，本身不支持TrustServerCertificate参数，升级后就能正常识别。

内容的提问来源于stack exchange，提问作者Binarus