SQL Server 2017 CLR严格安全模式 已签名程序集突然再次出现CLR严格安全异常

对照你给出的环境配置，核心触发根源 #

• 最直接的原因：用于程序集签名的MyCertificate已经超过你设置的2022-12-20 12:00:00.000有效期
  • SQL Server对CLR程序集的签名校验，不会因为证书在有效期内完成过一次签名就永久信任该凭证。不管是执行CREATE ASSEMBLY/ALTER ASSEMBLY操作，还是运行时加载已部署的程序集，数据库引擎都会实时校验关联签名证书的状态，包括有效期范围、关联关系是否有效。
  • 哪怕你全程没有改动证书二进制、没有调整程序集的编译产物，只要证书超过有效期，之前靠签名关联打通的UNSAFE ASSEMBLY权限链路就会失效，数据库引擎就会回到clr strict security=1的默认拦截逻辑，抛出你遇到的报错。
  • 这套配置稳定运行2年才报错，通常是因为之前的SQL Server累积版本对过期证书的校验存在兼容宽松策略，直到近期实例安装了相关安全更新，才启用了对过期签名证书的严格校验，直接触发了权限失败。
• 其他可排查的次要诱因
  • 与MyCertificate绑定的服务器级登录主体被误删，或者该登录被授予的UNSAFE ASSEMBLY权限被回收
  • 本次触发报错的程序集操作没有沿用原有签名流程：比如直接上传了未签名的程序集二进制执行修改，没有匹配之前的签名，自然会被严格安全规则拦截

快速定位的排查步骤 #

• 运行以下语句查询证书状态，直接对比到期时间和当前系统时间，确认是否为证书过期导致：

  SELECT name, expiry_date, subject 
  FROM sys.certificates 
  WHERE name = 'MyCertificate'
  

• 运行关联查询，确认证书对应的登录是否仍保有对应权限：

  SELECT perm.permission_name, perm.state_desc 
  FROM sys.server_permissions perm
  JOIN sys.server_principals sp ON perm.grantee_principal_id = sp.principal_id
  JOIN sys.certificates c ON sp.sid = c.sid
  WHERE c.name = 'MyCertificate'
  

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