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

VulDB在6月22日收了一条新编号：CVE-2026-12249。乍看是Canonical ADSys的一个小版本修复，连补丁说明都很短——v0.16.3修掉了AD CS证书自动注册脚本里一处HTTP明文请求。

但翻完漏洞详情，脑子里冒出的第一个念头是：这玩意儿八成在不少企业的内网脚本里躺了好几年，从来没被人当回事。

漏洞攻击面非常直白。ADSys在Ubuntu系统加入Active Directory域后，会通过AD CS做证书自动注册，脚本去拉取CA证书时走的不是TLS，而是赤裸裸的HTTP。中间人只要能在链路上动手脚，比如ARP欺骗或内网DHCP劫持，直接把回包里的根CA证书替换成攻击者自己签发的那份。

系统拿到假证书往信任库一扔，后续所有基于该信任链的TLS流量都可以被无感解密。

用大白话讲就是：你本想去政府大厅领一把官方的公章回家锁进保险柜，结果路上送公章的人开的是快递三轮，车门都没锁。

有人半道截胡，把真公章换成自己刻的萝卜章，往你保险柜里一塞。从此所有拿这枚萝卜章签过的合同，你都会当真的来执行。

攻击落地的技术门槛其实很低。随便抓一段常见的内网证书获取逻辑，大概率长这样：

curl -s http://pki.internal.lab/CertEnroll/ca.crt -o /usr/local/share/ca-certificates/internal-ca.crt
update-ca-certificates

没有HTTPS，没有证书指纹比对，下载完直接装进系统信任库。

攻击者在同一个广播域里跑个bettercap，一发ARP应答就能让上面的curl拉到自己的根证书。root权限、域信任、内部服务间的mTLS互认，会在几分钟内全面崩塌。

这事儿扎心的地方在于，它不是0day，甚至不是技术盲区。

负责基础设施的工程师心里都清楚，内部CA的证书获取接口应该上TLS，或者至少得做离线指纹校验。但现实环境里，AD域控的CertEnroll目录很多默认不启用HTTPS，老脚本没人敢动，新同事照着wiki复制粘贴一跑就过，没人再去审计“下载证书时到底用了什么传输协议”。

ADSy这个漏洞就像一面镜子，照出企业证书管理里一块常年没人清扫的死角：自动化脚本的初始信任建立过程，几乎没有防护意识。大家都在拼命搞定证书签发、过期轮换这些显性问题，却忘了种子本身被污染了，后面长出来的全是毒苗。

顺着这个口子往下看，开发者日常面对的坑比想象中多得多。证书过期忘了续，半夜被报警电话叫起来；Let's Encrypt手动续期写crontab，后来连crontab在哪台机器上都找不到；自签证书到处丢，管不到三个月信任链就成了一笔糊涂账。更别说像ADSy这样，一把HTTP请求直接把根信任拱手让人。

这些痛点的解法，业界已经收敛得很清楚：把证书的申请、验证、部署、续期全链路交给标准协议接管，减少人工脚本触碰。

ACME协议就是这条路子上被大范围验证过的方案，Let's Encrypt、Google Trust Services、ZeroSSL这些受信任的CA都支持它。有平台把ACME的能力封装成极简API，多域名、泛域名、IP证书都能覆盖，申请时自动完成域名验证，部署环节一条命令推到目标服务器，私钥都不落地。

以lcjmSSL为例，它的价值不在功能多少，而在于把“证书本该怎么管”这件事做出了约束。API调一次，从签发到安装全走加密通道，根证书来源强制通过ACME协议从上游CA获取，杜绝了HTTP明文拉取的原始错误。对于还在手搓证书脚本的团队，这类工具相当于把ADSy漏洞踩中的坑，直接变成了一条默认走不通的死路。

一个v0.16.2到v0.16.3的微小更新，背后是行业里长久以来“自动化优先，安全传输靠后”的惯性思维。

证书管理自动化的浪潮不会停，但每一条内网curl命令，每一个未校验的根证书，都可能是信任体系的第一个裂口。工具早已成熟，剩下的就是把旧脚本翻出来，一条一条查一遍。