# 47 天 SSL 证书：2026–2029 时间表与应对方法

> CA/浏览器论坛 SC-081v3 投票把 TLS 证书最长有效期从 398 天逐步缩到 47 天，域名验证复用期缩到 10 天。具体日期、原因和准备清单。

Source: https://ssl.sh/zh/learn/47-day-certificates/
Last updated: 2026-11-10

公网可信 TLS 证书从 2029 年 3 月 15 日起最长只能用 47 天。CA/浏览器论坛 2025 年 4 月通过的 SC-081v3 投票定下了这个时间表：最长有效期 2026 年 3 月 15 日从 398 天降到 200 天，2027 年 3 月 15 日降到 100 天，2029 年降到 47 天；CA 可复用域名验证结果的期限则缩到只有 10 天。手工续期从此不现实，自动化实际上成了必选项。

## 时间表

限制按每张证书的签发日期计算，写在基线要求（Baseline Requirements）第 4.2.1 和 6.3.2 节。已签发的证书保持原有效期。

| 签发时间 | 最长有效期 | 域名/IP 验证（DCV）复用期 | 主体身份信息（SII）复用期 |
|---|---|---|---|
| 2026-03-15 之前 | 398 天 | 398 天 | 825 天 |
| 2026-03-15 至 2027-03-14 | 200 天 | 200 天 | 398 天 |
| 2027-03-15 至 2029-03-14 | 100 天 | 100 天 | 398 天 |
| 2029-03-15 起 | 47 天 | 10 天 | 398 天 |

基线要求还在每档上限下面加了一条“SHOULD NOT”（不应超过 397、199、99、46 天），给 CA 留出时钟和取整误差的余量。2026 年同一轮修改还把“短期订户证书”的定义收紧为 7 天以内。

SC-081v3 的投票结果是：证书颁发方 25 票赞成、0 票反对、5 票弃权；参与投票的四家证书使用方（Apple、Google、Microsoft、Mozilla）全部赞成。投票于 2025 年 4 月 11 日结束。

```text
最长有效期（天）
398 |████████████████████████████████████████|  2026-03-15 之前
200 |████████████████████                    |  2026-03-15 起
100 |██████████                              |  2027-03-15 起
 47 |█████                                   |  2029-03-15 起
```

更长的历史（从五年期证书到今天）见[证书有效期时间线](https://ssl.sh/zh/timeline/certificate-validity/)；输入签发日期即可算出允许的最长有效期，可用[有效期计算器](https://ssl.sh/zh/tools/validity-calculator/)。

## 为什么要缩短

缩短有效期，一是弥补一直不好用的吊销机制，二是迫使整个行业具备快速更换证书的能力。

- **吊销不可靠。** 浏览器不会因为 OCSP 查不到而拦截，CRL 又很大，Let's Encrypt 也在 2025 年关停了 OCSP 服务。被盗或误签的证书实际上会一直可用到过期，有效期越短，损害上限越低。参见 [OCSP 与 CRL](https://ssl.sh/zh/learn/ocsp-and-crl/)。
- **域名会易主。** 域名卖掉或过期后，旧证书可能还有好几个月有效。验证复用期 10 天、证书 47 天，过时的控制权证明很快就会失效。
- **私钥泄露窗口。** 从服务器上被拷走的私钥，只在对应证书有效期内对攻击者有用。
- **密码算法敏捷性。** 迁移到新算法（包括[后量子算法](https://ssl.sh/zh/learn/post-quantum-tls/)），或者替换一家被取消信任的 CA，在全网证书几周就更新一轮时要容易得多。
- **自动化成为常态。** 根证书计划希望证书管理无需人工。Chrome 根证书计划政策写明，除 OV、EV 证书的身份核验外，常规签发和续期不应需要人工介入。

## 谁受影响、影响多大

影响大小和你现在证书管理的“手工程度”成正比。

| 情况 | 影响 | 应对 |
|---|---|---|
| 已用 Let's Encrypt 或其他支持 ACME 的 CA 自动续期 | 很小，本来就约 60 天续一次 | 确认续期周期不是写死的，开启 ARI |
| 在阿里云、腾讯云或代理商处买付费 DV 证书，手动下载上传 | 大：到 2029 年每年要换约 8 次以上 | 换用支持 ACME 的 CA，或用云厂商的证书托管、自动部署功能 |
| OV、EV 证书 | 组织信息每年核验一次（SII 复用 398 天），域名几乎每次签发都要验证 | 保持企业信息准确，DCV 自动化 |
| 负载均衡、CDN、硬件设备手动上传证书 | 大：每次续期都要登录控制台 | 用厂商内置的 ACME，或通过 API 自动部署 |
| 证书被固定（pinning）在 App 或物联网固件里 | 很大：固定叶子证书，每次续期都会断 | 改为固定自己掌控的 CA 或公钥，或使用私有 CA |
| 内网服务使用私有 CA | 不受基线要求约束 | 有效期自定，但仍建议自动化 |

国内云厂商提供的免费 DV 证书近年已普遍缩短为 3 个月左右，在控制台手动申请、下载、上传的流程本来就越来越累。基线要求只管公网可信证书，私有 CA 不在范围内；这也是应该把内网服务、设备身份和客户端证书挪到私有 CA 的又一个理由（参见 [mTLS](https://ssl.sh/zh/learn/mtls/)）。

## 订阅期和证书有效期是两回事

向商业 CA 买的是“订阅”，不是一张证书，两者的差距一年比一年大。付费期内可以随时免费重签，只是每张证书的最长寿命变短了。

下面是三个不同时间开始的一年期订阅，假设每张证书用到约三分之二寿命时续期：

| 订阅开始时间 | 单张证书上限 | 每年大约签发几张 |
|---|---|---|
| 2025 年 11 月 | 398 天 | 1 张 |
| 2026 年 11 月 | 200 天 | 2 到 3 张 |
| 2027 年 11 月 | 100 天 | 5 到 6 张 |
| 2029 年 11 月 | 47 天 | 11 到 12 张 |

多年期套餐同理。购买时看清条款：重签是否不限次数、是否支持 ACME。一年签发十一二次时，真正的成本在“安装”这一步。

## Let's Encrypt 走得更快

Let's Encrypt 比基线要求的时间表更早，并通过 ACME 配置（profile）让用户提前选择。它 2025 年 12 月公布的时间点如下：

| 日期 | 变化 |
|---|---|
| 2025-06-04 | 停发到期提醒邮件，监控要自己做 |
| 2026-05-13 | 可选的 `tlsserver` 配置改为签发 45 天证书 |
| 2027-02-10 | 默认 `classic` 配置从 90 天改为 64 天；授权复用期从 30 天缩到 10 天 |
| 2028-02-16 | `classic` 配置改为 45 天；授权复用期缩到 7 小时 |

另有可选的 `shortlived` 配置，证书有效期约 6 天。Let's Encrypt 建议客户端用 ACME 续期信息（ARI，RFC 9773）决定何时续期，不支持 ARI 的就在证书寿命约三分之二时续期，并明确提醒“写死 60 天续一次”今后不够用。它还在推动一种新的验证方式 DNS-PERSIST-01：DNS TXT 记录在每次续期时不需要变化，ACME 客户端也就不必拥有 DNS 写权限。截至 2026 年 11 月，使用前请以 Let's Encrypt 官方文档为准确认其状态。

宝塔面板自带的 Let's Encrypt 申请和续期、云服务器上的 certbot 或 acme.sh 定时任务，都要检查是否还是“按固定天数续期”的老逻辑。

## 10 天验证复用期意味着什么

真正打破手工流程的是 10 天的 DCV 复用期，影响甚至比 47 天有效期更大。现在很多人只验证一次（加一条 DNS TXT 记录或上传一个文件），之后几个月里重签都不必再验证。2029 年 3 月 15 日起，CA 只能在 10 天内复用这份证明，几乎每次签发都要重新完成一次挑战。

```text
2026 年：验证 ─────────────── 200 天复用窗口 ───────────────▶
         签发     签发（复用验证结果）    签发（复用）

2029 年：验证 ─10 天▶   验证 ─10 天▶   验证 ─10 天▶
         签发            签发            签发
         （每张 47 天证书基本都要单独验证一次）
```

HTTP-01 只要 ACME 客户端跑在 Web 服务器上就很容易。DNS-01（通配符证书必须用它）则需要客户端能调用 DNS 服务商的 API，例如阿里云云解析或 DNSPod 的 API，建议创建只能修改 `_acme-challenge` 记录的子账号密钥。挑战的工作原理见 [ACME 协议](https://ssl.sh/zh/learn/acme-protocol/)。

## 常见误解

已签发的证书不会在各个截止日失效，投票也只管公网可信的 TLS 服务器证书。

- **“我那张一年期证书 2026 年 3 月 15 日就失效了。”** 不会。限制只针对各节点之后签发的证书。2026 年 3 月 14 日签发的 398 天证书，照常用到 2027 年它自己的到期日。
- **“第 47 天再续。”** 47 天证书应在第 30 天左右续期，留出两周多时间发现并处理续期失败。100 天、200 天证书同样按三分之二规则。
- **“所有证书都受影响。”** SC-081v3 只修改 TLS 基线要求，代码签名、S/MIME 和私有 CA 证书各有各的规则。
- **“证书换得勤反而不安全。”** 自动化的轮换本身不是风险，风险在于容易被遗忘的手工流程。短有效期缩短了泄露私钥或误签证书的可用时间。
- **“验证复用期就是证书有效期。”** 两个限制是分开的。2029 年证书可以用 47 天，但签发时背后的域名证明最多只能是 10 天前的。
- **“用通配符证书就能躲过去。”** 通配符证书同样最多 47 天，而且必须用 DNS-01 验证，对 DNS 自动化的依赖反而更强。

## 准备清单

现在就开始：200 天证书已经生效，100 天证书 2027 年 3 月就到。

1. **盘点所有公网证书。** 用 [CT 证书查询](https://ssl.sh/zh/tools/ct-search/)搜索自己的域名，常能找出没人记得的主机。
2. **签发和安装自动化。** 能用 ACME 就用 ACME，包括支持 ACME 的商业 CA；云产品和硬件设备用厂商 API 写脚本部署。具体做法见[自动化证书续期](https://ssl.sh/zh/learn/automate-certificate-renewal/)。
3. **域名验证自动化。** 给 ACME 客户端配置只限 `_acme-challenge` 记录的 DNS API 权限，或者让 HTTP-01 直接在主机上完成。
4. **按信号续期，而不是按固定日期。** 客户端支持就开启 [ARI](https://ssl.sh/zh/glossary/ari/)，否则在寿命三分之二处续期。
5. **独立监控。** 检查服务器实际返回的证书，而不只是相信 ACME 客户端“已续期”的日志；剩余寿命约三分之一时告警。
6. **取消叶子证书固定。** 固定了证书的 App 和设备会在每次续期时出故障。
7. **非 Web 用途迁到私有 CA。** 客户端证书、设备身份、内网服务都不需要公网信任。

规则制定背景见[基线要求](https://ssl.sh/zh/glossary/baseline-requirements/)和[CA/浏览器论坛](https://ssl.sh/zh/glossary/ca-browser-forum/)。