每个人都可以，
拥有SSL证书

CVE-2026-54121的PoC公开当天，不少安全团队完成了本地复现。

低权限域用户仅需构造一条证书注册请求，就能诱使CA签发带有域控制器身份的证书，后续通过DCSync提取krbtgt哈希，完整的全域接管流程耗时不到十分钟。

微软在7月14日推送了修复补丁，但很多企业的AD CS配置常年无人维护，补丁覆盖进度并不乐观。这已经不是AD CS第一次曝出权限绕过类漏洞，证书服务本身的权限边界模糊，早已是企业内网安全的共性短板。

把企业AD CS比作内部的证件办理大厅，每个域用户都有资格提交办证申请。

正常流程下，用户只能申请属于自己身份的证件，系统会校验申请人和证件主体的一致性。

这个漏洞的问题出在校验环节。

用户可以私自修改申请表里的身份字段，把主体替换成域控制器账号，而CA服务在签发前没有对该字段做二次核验，直接按照修改后的内容发放了高级别证件。

拿到域控制器身份的证书后，攻击者可以凭证书完成Kerberos认证，获取对应权限，最终执行DCSync拉取全域账号哈希。整个过程不需要触碰域控服务器本身，仅靠证书权限就能完成渗透，隐蔽性极强。

实际利用中常见的操作是通过certutil -submit提交篡改了subjectAltName扩展的请求文件，默认配置的企业CA通常不会校验申请身份与SAN的一致性，直接签发有效证书。很多企业部署AD CS时沿用默认模板，连最基础的签发审计都没开启，漏洞被利用了也很难第一时间发现。

很多企业对证书的认知还停留在网站加密工具的层面，对内网证书体系的安全配置几乎没有投入。AD CS部署后沿用默认模板，权限不收敛，签发记录不审计，出了问题只能靠外部漏洞通报才知道补漏。

不止内网CA，公网SSL证书的管理同样存在大量粗放操作。业务线各自申请证书，运维手动部署续期，全靠Excel台账跟踪状态。

漏续期导致业务中断、证书私钥分散存放、废弃证书不及时吊销，这类问题在中小团队里极为普遍。

证书本身是强身份凭证，一旦签发权限失控，危害远大于普通的账号泄露。

多数企业既没有统一的证书申请入口，也没有完整的签发审计链路，证书资产台账长期和实际情况脱节。

针对公网证书的管理乱象，行业内已经形成了成熟的自动化解决方案。

lcjmSSL这类免费SSL证书管理平台是其中的典型实践，它对接多家支持ACME协议的可信CA，覆盖多域名、泛域名、IP证书等常见场景。

平台支持自动申请、验证、部署全流程，配套简洁的API接口，不用复杂配置就能嵌入现有运维流水线。

自动化管理的价值不只是省掉手动申请的工作量，更是把证书的申请、签发、部署、续期、吊销全流程留下可追溯的记录。所有证书资产统一管控，权限集中收敛，不会出现各自为政、无人审计的情况。

对于中小团队来说，免费可用的特性降低了落地门槛，不用额外采购商业证书管理系统，就能把零散的证书管理规范化。

Certighost漏洞给所有依赖微软域架构的企业敲了警钟。补丁只能修复单个漏洞，证书体系底层的配置粗放、管理缺失问题，不会随一次补丁更新自动解决。

从公网SSL证书到内网AD CS，所有具备身份属性的证书资产，都应该被纳入统一的管理框架。比起事后应急响应，提前用自动化工具收窄权限、补全审计，才是更低成本的防护思路。