这种情况我太懂了——明明让运维更新了加密证书，结果周一还是报错，自己又登不上服务器控制台，急得抓耳挠腮对吧？别慌，有几个不需要服务器权限的办法，能帮你远程验证当前SQL Server在用的加密证书详情：

方法一：故意触发证书错误查看完整详情（零特殊权限） #

这是最直接的办法，甚至不需要你能成功连接服务器：

• 打开SSMS，新建连接窗口，点击右上角的「选项」按钮
• 切换到「连接属性」标签，勾选「加密连接」，务必取消勾选「信任服务器证书」
• 点击「连接」，这时会弹出证书错误提示框，点击框里的「查看证书」
• 在这里你能看到证书的所有关键信息：有效期、颁发者、主题、指纹、序列号等等，直接和你提供的新证书对比就能知道问题出在哪——比如运维是不是装了旧证书，或者没把新证书配置给SQL Server用

方法二：通过服务器属性查看证书名称（需VIEW SERVER STATE权限） #

如果你能通过「信任服务器证书」成功连接服务器，可以用这个方法快速确认证书名称：

• 右键连接的服务器，选择「属性」
• 切换到「安全性」标签，在「服务器身份验证」区域的「证书」下拉框里，会显示当前SQL Server配置的加密证书名称
• 虽然看不到完整的证书细节，但能快速排除“运维选错证书”这种低级错误

方法三：用TSQL查询加密连接状态（需VIEW SERVER STATE权限） #

这个方法看不到证书本身，但可以辅助判断连接的加密状态，帮你缩小排查范围：

SELECT 
    c.session_id,
    c.encrypt_option,
    c.auth_scheme,
    s.login_name,
    c.client_net_address
FROM sys.dm_exec_connections c
JOIN sys.dm_exec_sessions s ON c.session_id = s.session_id
WHERE s.is_user_process = 1;

• 如果encrypt_option列显示TRUE，说明当前连接是加密状态；如果是FALSE，可能SQL Server根本没启用加密连接，或者证书配置完全失效

另外要提醒你：你提到的sys.certificates确实只显示数据库级别的证书（比如用于透明数据加密、备份加密的），而SQL Server加密连接用的证书是存在Windows本地机器的证书库里的，所以没法通过这个视图查到。

备注：内容来源于stack exchange，提问作者MWeber