结论：Chrome 将在 10 月 27 日上午（太平洋时间）停止信任 emSign ECC Root CA - G3，Mozilla 已在 10 月 20 日决定在 Firefox 里做同样的事。影响范围是这条根下约 30,800 张未过期证书，其中 99.9% 由 InCommon 签发；eMudhra 自己估算需要迁移的约 3 万张，97% 通过 ACME 自动签发。挂在 emSign Root CA - G1（RSA）下面的证书目前仍在信任列表里。
今天要做的
先确认证书挂在哪条根上。对每个对外域名跑一次：
bash
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
| grep -E '^ *[is]:'输出里出现 emSign ECC Root CA - G3 的，27 号之后会失效。出现 emSign Root TLS CA - G1 的暂时还能用，但别当长期方案，原因见下一节。链上只有 Let's Encrypt、DigiCert 或 InCommon 自己的 CA 名字、不出现 emSign 的，不用动。
再看这张证书的时间：
bash
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -subject -dates换证走 ACME 的话，先空跑一次，别直接打到速率限制上：
bash
certbot renew --cert-name example.com --dry-run
certbot renew --cert-name example.com --force-renewal最后一件事最容易漏：不经浏览器的信任库。浏览器更新不会替你改这些。
bash
# 系统 CA bundle
grep -ril "emSign" /etc/ssl/certs /usr/local/share/ca-certificates 2>/dev/null
# Java truststore
keytool -list -cacerts -storepass changeit 2>/dev/null | grep -i emsign
# 镜像里自带的 bundle
docker run --rm your-image sh -c 'grep -ril emSign /etc/ssl/certs 2>/dev/null'参数与坑
| 项 | 值 |
|---|---|
| 受影响根 | emSign ECC Root CA - G3 |
| Chrome 生效 | 10 月 27 日上午（PT） |
| Firefox | 10 月 20 日决定停止信任 |
| 根下未过期证书 | 30,800（Chrome 统计 CT 日志，截至 10 月 21 日） |
| 其中经 InCommon | 99.9% |
| 需迁移 | 约 30,000，97% 走 ACME |
| 备用根 | emSign Root CA - G1（RSA），当前仍被信任 |
限制条件有四条：
- 标准 ACME 客户端只在续期窗口内动作。窗口没到，它不会因为你着急就续，除非客户端支持 ACME Renewal Information（ARI），或者你手动
--force-renewal。这正是那 3 万张证书里最危险的一批。 - 从 ECC 换到 RSA 不只是换一张证书。客户端配置里的密钥类型要改，部分老 SDK 对曲线和链顺序更挑。
- G1 这条根也不干净。10 月 14 日发布的 CRL 签名对不上该 CA 自己的密钥，公开 bug 里的分析认为是用 OCSP 证书的密钥签的，Chrome 已就此提问。拿它做过渡可以，做终点不行。
- 问题不在 P-384。CERT-In 的结论是 2025 年 4 月 30 日那次密钥生成里，脚本在 wrap/unwrap 环节多造了一套弱密钥，八个私钥的值都小于 256，从公钥几乎可以直接还原；六个拿去签 TLS，两个签代码。eMudhra 声明没有从这八个中间 CA 签发过终端证书，CERT-In 说截至 10 月 21 日没有确认的恶意利用。这两条只降低"已被利用"的概率，不改变"必须换"的结论。
Decisions API 的参数边界
10 月 22 日转正，端点是 POST /v1/decisions，只支持 gpt-6-luna。
| 项 | 值 |
|---|---|
| 输入 | $0.10 / 百万 token |
| 缓存输入 | $0.01 / 百万 token |
| 输出 | 不计费 |
| 单次问题数 | 1--400 |
| 题型 | predicate / choice / score |
| 返回 | 0--1 概率、选项加置信度、rubric 加权分 |
| 不支持 | 文件、音频、item 引用、file_id |
| 有依赖的判断 | 拆成多次请求 |
| 缓存命中 | 共享输入前缀 ≥1,024 token |
score 型返回的是概率加权平均，落在两档之间是正常结果，别按整数断言。档位数限定在 2 到 10。图片可以走 base64 data URL 或公网 HTTP(S) URL，PDF 这类文件不行。
论文方法：把 fuzz 入口变成定理
Anthropic 10 月 22 日那篇的做法能拆成四步，适合拉去做内部试点。
一，选入口。他们选的是 OSS-Fuzz 的 fuzz target，123 个库共 239 个入口。入口是作者自己留的测试前门，语义清楚，比整库验证便宜一个数量级。
二，把命题写窄。命题是"对任意小于 64MB 的输入，程序正常退出、不触发 ASan 报告的内存错误、断言不失败"。条件越具体，证明越短，模型越不容易跑偏。
三，落到汇编层。代码编译成静态链接 musl 的 RISC-V 二进制，再为这个 ISA 生成形式语义，证明做在汇编层。语义也是模型生成的，验收方式是能在语义上单步启动一个 Ubuntu 用户态。
四，用 Rocq 检查。证明由模型产出，对错由检查器兜底，模型自己说什么不算数。他们对"把程序改成永不崩溃来骗过证明"做了惩罚，并要求额外证明输入范围，压住这类奖励劫持。
产物是公开的一部分证明，加上 RISC-V 与 OS 的形式语义；Theorem 提供把同一套流程跑在别的开源项目上的服务，另外放了一个 Claude skill 给开发者起步。
边界要写清楚：只覆盖单线程、静态链接 musl 的 RISC-V 二进制，实际部署多是 x86/ARM 加 glibc；ASan 本身检不出全部内存错误，入口也没验全；整个库不等于所有入口之和。所以"这个库不会崩"这句话，限定条件比结论长。