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

8月20日CA/B Forum Validation子委员会的例会信息量不小。SC-100全票通过，DNSSEC验证规则要澄清整合；SC-102新版TLS Baseline Requirements正式发布；SC-103还在讨论交叉认证子CA的EKU问题。

但真正让我盯着屏幕多看了两遍的，是那个被正式列为讨论议题的短语：AI在证书验证流程中的使用边界。

这个话题被摆上台面，说明已经有CA或相关服务商在验证环节引入AI能力，而且用得不那么收敛。

验证流程本来是一套确定性极高的动作序列，AI的介入会直接动摇这个确定性。

证书验证的核心逻辑可以类比成机场安检。你拿身份证过闸机，闸机只做一件事：读取证件信息，比对公安系统数据，返回是或否。这个动作不涉及主观判断，不需要安检员看着你的脸琢磨像不像本人。DV证书的域名验证同理，CA发一个随机token，你放在指定路径或DNS记录里，CA去取，匹配上就过。

整个过程是机器对机器的确定性校验。

AI介入后会变成什么？相当于安检员开始凭经验判断你像不像身份证照片，像不像好人。这个判断引入了概率，而证书验证体系从根子上是排斥概率的。

有人可能会说，AI只是辅助识别验证截图或加速人工审核。

问题在于，验证流程中任何一环的判定依据被模型输出替代，审计链就断了。基线要求里每个验证动作都要有明确的方法编号、可复核的证据留存。模型给出置信度评分，这个评分本身不是证据，它只是对证据的另一种解读。

SC-100的DNSSEC验证规则澄清，在这个背景下更值得琢磨。DNSSEC验证依赖DNS解析链上的签名校验，一个常见的坑是CNAME链路中的签名状态。比如你验证a.example.com，它CNAME到b.example.net，DNSSEC签名在中间某一段断了，不同CA对验证是否通过的理解不一致。SC-100要整合这套规则，本质上是在收紧验证动作的可预测性。

运维侧的实际痛点是，证书续期和验证的自动化程度越高，越依赖验证规则稳定不变。

ACME协议本身已经足够成熟，但ACME只是通道，验证逻辑还是CA后端那套东西。验证规则一旦因为AI介入或标准修订产生模糊地带，自动化流水线就会在半夜告警。

拿DNSSEC举例，如果权威DNS的签名滚动没配好，ACME的dns-01验证请求可能返回SERVFAIL。终端上看到的是certbot报错：

urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up TXT for _acme-challenge.example.com

这种报错跟证书平台无关，纯粹是验证链路上的确定性被破坏了。

lcjmSSL这类基于ACME的证书管理平台，干的事其实就是把这套验证流程的复杂度压在平台侧。支持多域名、泛域名、IP证书，底层对接Let's Encrypt、Google Trust Services、ZeroSSL这几家CA。它的价值不在证书本身，证书哪家都能签，而在验证动作的编排和失败重试机制上。

当SC-100这类规则变更落地，各CA对DNSSEC验证口径统一后，平台侧的适配成本会低很多。

回到AI议题。短期看，CA/B Forum不会立刻出禁止性条款，更可能是先划定哪些验证环节允许使用机器学习辅助，哪些必须保留确定性校验。

开发者和运维人员真正需要关注的，是自己证书管理流水线里有没有引入非确定性的验证辅助手段。如果有，趁早拆出来。

标准组织和行业正在做的事，是让验证体系在自动化和严谨性之间找到一个不牺牲确定性的平衡点。

SC-100通过、SC-102发布、AI边界被讨论，都是同一个方向的注脚：验证动作可以快，可以自动化，但每一环必须可解释、可复核。丢了这条，HTTPS那把小锁头的信任基础就松了。