直接答案：公开信任的 TLS 证书最长有效期正在从 398 天降到 200 天（2026-03-15 起）、100 天（2027-03-15 起）、47 天（2029-03-15 起）；域名/IP 验证数据的复用期同步从 398 天降到 200/100/10 天。200 天阶段已经生效，下一个硬节点是 2027-03-15 的 100 天。这不是“证书贵不贵”的问题，而是运维频率：一张证书每年至少续 1.8 次（200 天）、3.65 次（100 天）、7.8 次（47 天）；1,000 张证书在 47 天阶段约 7,766 次/年，约 21 次/天——手工上传不可能稳定。现在要做的不是等 2029，而是把“清单、ACME 自动签发、自动部署、到期/CT 监控、回滚”先跑通。
本文面向网站/电商运维、SRE、平台工程、CDN/负载均衡管理和采购团队，解释 CA/Browser Forum Baseline Requirements 的 200→100→47 天时间表、续期工作量、ACME 自动化、常见失败模式和 90 天落地清单。规则来自 CA/Browser Forum Baseline Requirements 当前文本（含 2026-03-15、2027-03-15、2029-03-15 生效条款）、Ballot SC-081v3，以及 IETF RFC 8555（ACME）与 RFC 8657（ACME CAA accounturi/validationmethods），均于 2026-11-08 访问。本文把“官方规则事实”“编辑测算”和“实施建议”分开写，不构成合规或采购建议。
① 200 天已经生效（2026-03-15），100 天在 2027-03-15，47 天在 2029-03-15；域名/IP 验证复用期同步缩到 200/100/10 天。② 47 天阶段 1,000 张证书约 7,766 次续期/年，手工流程一定会漏；ACME + 自动部署 + 监控是默认架构。③ 多年订阅不等于单张证书多年有效；每张证书仍受 200/100/47 天上限，采购要按“签发次数/自动化”而不是“买一次装一年”算。
时间表：398 → 200 → 100 → 47 天
CA/Browser Forum Baseline Requirements 当前文本给出三个硬节点：2026-03-15 起，Subscriber Certificate 最长 200 天；2027-03-15 起最长 100 天；2029-03-15 起最长 47 天。域名和 IP 地址验证数据的最大复用期同步为 200/100/10 天；主体身份信息（Subject Identity Information）的复用期在 2026-03-15 仍是 398 天，不要把所有验证数据都当成同一节奏。规则还明确“一天按 86,400 秒计”，小数秒/闰秒会多加一天，所以官方建议不要默认签发到最大值。
| 证书签发日 | 最长有效期 | 域名/IP 验证复用期 | 其他同步变化 |
|---|---|---|---|
| 2026-03-15 之前 | 398 天 | 398 天 | 旧规则 |
| 2026-03-15 – 2027-03-14 | 200 天 | 200 天 | DNSSEC 验证、禁止 IP 反向前缀、Precertificate Signing CA 退场 |
| 2027-03-15 – 2029-03-14 | 100 天 | 100 天 | ACME accounturi/validationmethods（RFC 8657） |
| 2029-03-15 起 | 47 天 | 10 天 | 更短周期成为常态 |
来源：CA/Browser Forum Baseline Requirements 当前文本（Section 6.3.2、4.2.1 及生效日期表）；Ballot SC-081v3（2025-04-11 通过、2025-05-16 生效）。表中为编辑整理；“最长有效期”指公开信任 TLS Subscriber Certificate，内部/私有 CA 不受同一 BR 约束。
续期工作量：从“一年一次”到“一年八次”
按“到期即续、无重叠”估算，单张证书每年续期次数约为 365/有效期：398 天约 0.92 次、200 天约 1.83 次、100 天约 3.65 次、47 天约 7.77 次。放到 100 张/1,000 张证书，就是 183/1,825 次（200 天）、365/3,650 次（100 天）、777/7,766 次（47 天）。如果其中 20% 仍靠人工，1,000 张在 47 天阶段约 1,553 次人工/年，约 4.3 次/工作日；这还没算失败重试、跨团队审批和部署窗口。
| 最长有效期 | 单证书续期/年 | 100 张/年 | 1,000 张/年 | 1,000 张中 20% 人工/年 |
|---|---|---|---|---|
| 398 天 | 约 0.92 | 约 92 | 约 917 | 约 183 |
| 200 天 | 约 1.83 | 约 183 | 约 1,825 | 约 365 |
| 100 天 | 约 3.65 | 约 365 | 约 3,650 | 约 730 |
| 47 天 | 约 7.77 | 约 777 | 约 7,766 | 约 1,553 |
编辑测算：365/有效期，按到期即续、无重叠估算；实际续期窗口通常提前，次数可能更高。未计多域名/SAN、通配符、跨区域部署、CDN/负载均衡上传和审批时间；“20% 人工”只是示例。
哪些证书受影响，哪些不受
规则针对“公开信任”的 TLS Subscriber Certificate：由受浏览器/操作系统信任的 CA 签发、用于公网 HTTPS/API/邮件等场景的证书。内部/私有 CA 签发的证书不受 CA/B Forum BR 的同一有效期约束，但可能受企业安全策略、行业监管或客户端限制；如果私有 CA 的根被导入公共信任库，或证书被用于公网，就要按公开信任规则评估。另要注意：证书“订阅/合同”可以是多年，但每张实际签发的证书仍受 200/100/47 天上限，CA 通常通过多次签发来履约。
| 对象 | 是否受 200/100/47 天限制 | 先核对 |
|---|---|---|
| 公网 HTTPS 网站/API | 是 | CA 是否公共信任、证书类型 |
| CDN/负载均衡上的证书 | 是 | 上传/自动部署能力、回滚 |
| 内部/私有 CA 证书 | 通常不受同一 BR 约束 | 企业策略、客户端信任、合规 |
| 自签名/测试证书 | 不受公共 BR 约束 | 不要用于生产/公网 |
| 多年订阅/合同 | 单张证书仍受限 | 合同是否按“多次签发”履约 |
| IoT/嵌入式/邮件/数据库 TLS | 看是否公共信任/客户端要求 | 设备更新能力、信任库 |
来源：CA/Browser Forum Baseline Requirements（适用范围与 Section 6.3.2）；表中为编辑整理。内部 CA、客户端信任和行业监管的具体要求以企业标准/适用法规为准。
自动化架构：ACME + 部署 + 监控
47 天阶段的核心不是“买哪家证书”，而是“能否在无人值守下完成签发、验证、部署、验证生效、回滚”。标准做法是 ACME（RFC 8555）：客户端向 CA 申请，CA 通过 HTTP-01、DNS-01 或 TLS-ALPN-01 验证域名控制权，签发后由部署器推到负载均衡/CDN/应用，监控器检查到期、链、CT 和实际握手。2027-03-15 起，CA 还必须处理 ACME 的 accounturi/validationmethods 参数（RFC 8657），这让 CAA 记录可以绑定账户和验证方法，降低被冒签风险。
| 组件 | 作用 | 实施要点 |
|---|---|---|
| 证书清单 | 知道有哪些证书、在哪、谁负责 | 域名/SAN、CA、到期日、部署位置、 owner、自动/手工 |
| ACME 客户端 | 自动申请/续期 | 支持 DNS-01/HTTP-01；失败重试、限速、日志 |
| 验证方式 | 证明域名控制权 | DNS-01 适合通配符/多域名；HTTP-01 需公网可达 |
| 部署器 | 把新证书推到 CDN/LB/应用 | 原子更新、灰度、回滚、证书链完整 |
| 监控 | 发现过期/链错误/部署失败 | 到期 30/14/7 天告警；CT 日志；外部握手探测 |
| CAA/账户绑定 | 限制谁能签发 | RFC 8657 accounturi/validationmethods（2027-03-15 起 CA 必须处理） |
| 应急 | CA/验证/部署故障 | 备用 CA、备用验证路径、手动兜底、回滚演练 |
来源：IETF RFC 8555（ACME）、RFC 8657（ACME CAA accounturi/validationmethods）、CA/Browser Forum BR 2027-03-15 条款；表中为编辑整理的实施建议。
常见失败模式：为什么自动续期也会过期
自动续期失败通常不是 ACME 本身，而是“验证/部署/监控”链路：DNS API 权限过期、CAA 记录不允许新 CA、HTTP-01 被 WAF 拦截、通配符证书需要 DNS-01、CDN 只上传了叶子证书没传中间链、负载均衡多节点只更新了一台、监控只看证书文件不看实际握手、时钟漂移导致提前/延后、CA 限速或账户被锁。47 天周期会把这些问题从“一年一次事故”变成“每月多次”，必须用演练和告警兜底。
| 失败模式 | 症状 | 控制 |
|---|---|---|
| DNS API 权限/凭据过期 | DNS-01 验证失败 | 最小权限、到期轮换、双凭据 |
| CAA 不允许新 CA | 签发被拒 | 变更前检查 CAA；绑定 accounturi |
| WAF/防火墙拦 HTTP-01 | 验证 403/超时 | 放行验证路径或改用 DNS-01 |
| 只部署叶子证书 | 部分客户端链错误 | 部署完整链、外部握手测试 |
| 多节点/多区域只更新一台 | 间歇性过期 | 原子发布、逐节点校验、灰度 |
| 监控只看文件 | 文件新、线上仍旧 | 从外部探测实际证书/到期 |
| CA 限速/账户锁定 | 续期排队失败 | 提前续、备用 CA、告警 |
| 时钟/时区错误 | 提前/延后生效 | NTP、UTC、留余量 |
编辑整理的常见故障与建议，不是官方清单；具体验证方式、CAA、CA 限速和部署约束以 CA/客户端/平台文档为准。
采购与 CA 选择：别把“多年订阅”当“多年证书”
采购时要区分“合同/订阅期”和“单张证书有效期”：多年合同通常允许在期内多次签发，但每次签发仍受 200/100/47 天上限。问 CA 的问题应该包括：是否支持 ACME、是否支持 DNS-01/通配符、API 限速、CAA accounturi/validationmethods、失败重试/告警、证书链/根更新策略、备用 CA、SLA 和价格是否按签发次数/域名数计。不要只看“单张年价”，要按 47 天阶段的年签发次数算总成本。
| 采购问题 | 为什么重要 |
|---|---|
| 支持 ACME 吗？支持哪些验证方式？ | 决定能否自动续期/通配符 |
| API 限速/并发/重试策略？ | 1,000 张证书集中续期会触发限速 |
| CAA accounturi/validationmethods 支持？ | 2027-03-15 起 CA 必须处理 RFC 8657 参数 |
| 证书链/根更新如何通知？ | 链变化会导致部分客户端失败 |
| 是否支持备用 CA/多 CA？ | 单 CA 故障时能切换 |
| 价格按证书/域名/签发次数？ | 47 天阶段签发次数大增 |
| SLA/支持/故障响应？ | 过期是生产事故，不只是采购问题 |
编辑整理的采购问题清单，不是厂商推荐；具体合同、价格和 SLA 以 CA 报价与条款为准。
90 天落地清单
先用 90 天把“证书清单、自动签发、自动部署、监控、演练”跑通，不要等到 2027-03-15。顺序是：盘点 → 选 ACME/验证方式 → 部署自动化 → 监控/告警 → 故障演练 → 采购/合同。47 天阶段只是把同一套流程跑得更频繁；如果 200 天阶段还在手工，100 天阶段就会崩。
| 阶段 | 动作 | 产出 |
|---|---|---|
| 第 1–2 周 | 盘点所有公开 TLS 证书：域名/SAN、CA、到期、部署位置、owner | 证书清单、风险排序 |
| 第 2–3 周 | 选 ACME 客户端/CA/验证方式；确认 DNS API、CAA、WAF 放行 | 自动化方案、权限模型 |
| 第 3–5 周 | 在测试/预发跑通签发→部署→握手验证→回滚 | Playbook、回滚步骤 |
| 第 5–7 周 | 接监控：到期 30/14/7 天、CT、外部握手、链检查 | 告警、仪表盘 |
| 第 6–8 周 | 做 CA 故障/验证失败/部署失败演练 | 演练报告、备用路径 |
| 第 8–10 周 | 按 47 天负载做容量/限速/并发测试 | 限速参数、批处理策略 |
| 第 10–12 周 | 更新采购/合同/SLA，明确多年订阅的签发次数 | 采购结论、预算 |
编辑整理的落地建议，不是官方模板；具体 ACME/CA/部署/监控实现以企业架构和厂商文档为准。
常见问题
200 天证书现在生效了吗？
生效了。2026-03-15 起签发的公开信任 TLS Subscriber Certificate 最长 200 天；域名/IP 验证数据复用期也是 200 天。之前签发的 398 天证书在到期前仍然有效。
100 天和 47 天什么时候开始？
100 天从 2027-03-15 起；47 天从 2029-03-15 起；域名/IP 验证复用期分别为 100 天和 10 天。
内部证书也受限制吗？
CA/B Forum BR 约束的是公开信任证书；内部/私有 CA 通常不受同一有效期限制，但可能受企业策略、客户端信任或行业监管约束。若私有根被导入公共信任库或用于公网，应按公开信任规则评估。
买多年证书能绕过吗？
不能。多年合同可以是多次签发，但每张实际证书仍受 200/100/47 天上限；采购要按年签发次数/域名数/自动化能力算，而不是“买一次装多年”。
必须用 ACME 吗？
不是强制，但在 100/47 天阶段手工续期不现实。ACME（RFC 8555）是自动签发/续期的标准协议；也可以用商业 CA 的 API/代理，但同样要解决部署、监控和回滚。
通配符证书怎么办？
通配符通常用 DNS-01 验证；证书本身仍受 200/100/47 天限制。要限制 DNS API 权限、绑定 CAA accounturi，并准备验证失败/部署失败的手动兜底。
证书链/根变化要注意什么？
只部署叶子证书、没传中间链，或根/链更新未同步，会导致部分客户端失败。部署后从外部做实际握手测试，监控链和到期，准备回滚。
怎么避免证书过期？
清单 + 自动续期 + 自动部署 + 外部握手监控 + 30/14/7 天告警 + CT 监控 + 定期演练；关键域名准备备用 CA/验证路径。
研究方法与局限
本文把“官方规则事实”和“编辑测算”分开：200/100/47 天时间表、域名/IP 验证复用期 200/100/10 天、2026-03-15 的 DNSSEC/IP 反向前缀/Precertificate Signing CA 变化、2027-03-15 的 ACME accounturi/validationmethods、2029-03-15 的 47 天/10 天，来自 CA/Browser Forum Baseline Requirements 当前文本（Section 6.3.2、4.2.1 及生效日期表）与 Ballot SC-081v3；ACME 协议来自 IETF RFC 8555，CAA 参数来自 RFC 8657。续期次数、人工比例、90 天清单和采购问题为编辑测算/建议。
局限有八个：① 不构成法律/合规/采购建议；② 只覆盖公开信任 TLS Subscriber Certificate，未展开私有 CA/客户端信任/行业监管；③ 续期次数按“到期即续”估算，实际受续期窗口、SAN/通配符、部署节点影响；④ 未计 CA 价格、限速、SLA 和合同差异；⑤ 未覆盖所有 ACME 客户端/CA 的实现差异；⑥ 未展开 CT/OCSP/CRL、证书链/根更新和 IoT 设备限制；⑦ 未评估多 CA/多区域/多租户的具体架构；⑧ 规则可能更新，实施前应复核 CA/B Forum BR 与 CA/平台文档。
数据来源与口径
- CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates（当前文本）：cabforum.org/working-groups/server/baseline-requirements/requirements。Section 6.3.2 最长有效期、4.2.1 验证数据复用期、生效日期表。访问 2026-11-08。
- CA/Browser Forum, Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods（2025-04-11）：cabforum.org/.../ballot-sc081v3。200/100/47 天与 200/100/10 天复用期、投票/生效信息。访问 2026-11-08。
- IETF RFC 8555, Automatic Certificate Management Environment (ACME)：rfc-editor.org/rfc/rfc8555。ACME 签发/验证/续期协议。访问 2026-11-08。
- IETF RFC 8657, ACME Profile for CAA accounturi and validationmethods：rfc-editor.org/rfc/rfc8657。CAA 账户/验证方法绑定；BR 要求 2027-03-15 起 CA 处理。访问 2026-11-08。
资料截止 2026-11-08；有效期/复用期以 CA/Browser Forum 最新 BR 和 CA/平台文档为准；本文不构成合规、采购或法律建议。