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

2026年7月，公共CA HARICA连着栽了两个跟头，动静不小。

第一轮，它在6月15日到7月15日间签发了66,105张TLS服务器证书，全部违反了自己的策略——证书里带了clientAuth EKU。这事要是没人发现，可能就这么过去了。但证书透明度日志是公开的，任何人都能翻。

第三方研究人员从CT日志里比对出异常，直接捅到CA/Browser Forum。按规矩，HARICA必须在五天内吊销这些证书，实际吊销了63,525张。

第二轮紧跟着来。吊销完没消停几天，又发现一批证书少了AIA OCSP URI扩展，再次触发吊销。

两起事件没有任何密钥泄露，没有攻击者，没有漏洞利用。根因听起来有点荒诞：HARICA的内部策略文档（CP/CPS）保留了一个2026年6月15日停止签发含clientAuth证书的截止日期，而Chrome那边早就把行业截止日期延到2027年3月15日了。

签发系统没同步，文档是旧的，代码照着旧文档跑，直接批量产出不合规证书。

这就是典型的文档与系统脱节导致的自我伤害式合规失败。

运维圈子里有句话：手册和跑着的系统从来不是一个版本。HARICA用事实给这话做了个注脚。

很多人觉得CA出事就等于私钥泄露或被入侵，但这次的事提醒了一件事——吊销这柄剑，不光砍安全事件，也砍流程失控。对下游的运维和开发者来说，你绑死在某个CA上的证书，可能一夜之间就被合规原因成批吊销，跟你自己的服务安全性毫无关系。

怎么发现这种破事？靠的就是证书透明度。CT可以理解成一个公开的、只追加不删除的证书签发账本。任何CA签发的证书，都得往这个账本里记一笔。浏览器认不认你的证书，也会查这个账本。这就像快递单号全网可查，你发出去的每一个包裹，物流轨迹都晾在明面上。第三方研究人员做的事，其实就是在账本上 grep 了一下，发现HARICA签发的证书里有一大批长了对不该长的“腿”。

$ ct-fetch --ca harica --after 2026-06-15 --eku clientAuth
66000+ results found. CP/CPS violation confirmed.

这给运维提了个醒：不能等CA发邮件通知你吊销。

CT日志是实时的，OCSP响应是实时的，你自己的业务中断可不是等来的。HARICA在五天内吊销6万多张证书，这种规模的吊销行动，对依赖固定证书、手动替换的团队就是灾难。半夜告警、用户反馈连接失败、查半天才发现证书没了，这种场景光想想血压就上来了。

痛点就在这儿：证书从签发到吊销的整个生命周期，如果全靠人工盯着，出事的窗口期远大于你的反应时间。而且单一CA一旦出合规问题，你连快速切到备选CA的通道都没有。证书改个CA，往往意味着重新走一遍申请、验证、下发、部署的流程。

手动跑完这一套，业务都不知道凉了几轮了。

解决思路其实行业里已经收敛得比较明确——ACME协议加多CA接入。ACME让证书申请、验证、续签、吊销这一整套动作变成机器对机器的自动化流程，不再需要人去点网页、填CSR、收邮件、粘证书。更重要的一点是，ACME客户端通常可以配置多个CA端点。

你可以同时对接Let‘s Encrypt、Google Trust Services、ZeroSSL等，某一家CA出问题，客户端按策略切到下一个签发源，重新申请一张新证书，整个切换过程分钟级甚至秒级完成。

一些团队已经在这样用。比如借助lcjmSSL这类平台，把ACME客户端挂上去，一个接口绑多个域名和泛域名，甚至IP证书也能自动签发。

验证阶段用DNS-01或HTTP-01自动完成，部署直接调API推送到网关或负载均衡。证书临期了自动续，哪家CA爆出合规问题被大规模吊销，系统的反脆弱手段不是临时开会，而是自动切到备选CA重签，业务侧几乎无感。整个过程中，人只需要看监控，不用上手黏证书。

回到HARICA事件本身。它暴露的不是某个CA不可靠，而是整个信任链条上任何一环都可能因为内部流程脱节而失控。如果我们的证书管理还停留在“一张证书用一年，到期了再去申请”的状态，那每一次类似HARICA的吊销事件，都可能变成一次人工救火的实战演练。

证书生命周期自动化，不值得再观望了。