从 SC-081 说说 SSL 证书的那些事

发布日期: 2025/05/18
更新日期: 2025/05/18
作者: 小谈谈
分类: 开发
标签: ssl, 运维, 证书, ca
阅读时间: 7 分钟
字数: 1947 字

2025 年 4 月 13 日。CA/Browser Forum 组织投票，正式通过 SC-081 提案。此后，SSL证书的有效期会逐步从现在的 398 天缩短到 47 天（2029 年 3 月 15 日起生效）。该提案最早由苹果公司在 2023 年秋季提出，一经提出，就受到了广大站长的强烈反对。但浏览器厂商和行业组织仍然坚定的给予了支持（29 赞成，5 弃权，0 反对）。

[图片: iShot2025-05-1800.22.17]
https://static.txisfine.cn/upload/iShot2025-05-1800.22.17.png/pkwatermark

提案详情

SC-081 主要在证书有效期、域名验证数据重用有效期两个方向做了进一步缩短：

| 时间节点 | 非 SAN 验证数据重用 | SAN 验证数据重用 | 证书最长有效期 | | --------------------------- | ------------------- | ---------------- | -------------- | | 2026年3月15日之前 | 825 天 | 398 天 | 398 天 | | 2026年3月15日–2027年3月15日 | 398 天 | 200 天 | 200 天 | | 2027年3月15日–2029年3月15日 | 398 天 | 100 天 | 100 天 | | 2029年3月15日之后 | 398 天 | 10 天 | 47 天 |

SAN 验证数据一般指的就是域名或者IP。非 SAN 验证数据一般就是企业信息数据。

对于证书来说，如果按照验证方式进行分类，一般分为 DV、OV、EV。OV 为企业型证书，EV 为增强型证书。DV 证书就是域名证书，只要验证了域名所有权就可以签发。OV、EV 证书除了要验证域名所有权之外，还要验证企业（组织）的真实性。按照规划，未来申请 OV、EV 证书，需要每398天对组织重新进行审核验证。申请DV证书，超过10天就需要重新验证域名所有权了。

缩短证书有效期有什么意义

降低私钥泄露带来的风险

根据 CA/B 论坛的要求，CA 在发现证书泄漏后应在 24 小时内吊销。然而，部分 CA 并未严格执行该规定，导致泄漏证书仍可能被滥用。通过缩短证书有效期，可以限制泄漏证书的可用时间，从而降低潜在风险。

弥补现有吊销机制的不足

当前的吊销手段（如 CRL 和 OCSP）存在效率低、响应慢等问题，尤其在紧急情况下难以及时生效。缩短证书有效期，即便吊销机制未能及时生效，证书也能在短时间内自然失效，提升整体安全性。 OCSP 存在单点故障的风险，当 OCSP 服务器出现故障时，客户端往往会忽略证书的吊销状态，仍然认为证书有效值得信任。

推动新加密算法的使用

随着计算能力提升，部分传统加密算法已不再安全。长期有效的证书会延缓新算法的推广。从实践上看用户往往都是在更新证书时候更新新的加密算法，通过减少证书有效期，促进证书更新，从而更快地采用更安全的加密技术。

强化证书所有权与域名控制权的一致性

数字证书签发需通过域名控制验证（DCV），而现行规则允许 DCV 结果最长复用 398 天，与证书最长有效期一致。这意味着在较长周期内，无需重新验证域名控制权，存在一定安全隐患。通过缩短证书和 DCV 的有效期，能更频繁地验证控制权，确保证书、域名及其所有者的一致性。

短有效期证书对我们的挑战

一年期，多年期证书破灭，CA 无法签发超过 47 天有效期的证书，虽然我们还可能订购到一年期和多年期证书，但他们往往都是几张证书凑出来的，仍然需要重新安装新证书。在新的证书政策下，以 47 天有效期计算，同一域名每年需要申请约 8 次证书。这种高频率的更新，显著增加了运维团队的工作负担，也带来了证书管理的碎片化问题。在实际环境中，企业往往采用分布式架构，不同的服务器、环境、服务节点可能各自使用不同版本的证书。如果缺乏统一的证书生命周期管理机制，极易出现个别节点的证书被遗忘更换，最终导致业务中断。世界是一个巨大的草台班子，推动缩短证书有效期的“始作俑者”苹果公司自己也曾“中招”。在 2024 年，苹果就因未及时续期数字证书，导致 Apple Music 出现短暂中断。这一事件再次说明，即便是全球最具自动化能力的科技巨头，也难以在高频证书更新中做到绝对可靠。

[图片: 20250518234128]
https://static.txisfine.cn/upload/20250518234128.png/pkwatermark

尽管短周期证书在提升安全性方面具备明确优势，但如果缺乏相应的自动化工具和集中化管理能力，它很容易让“保障安全”的初衷适得其反，反而成为新的风险源头。面对高频更新和生命周期碎片化等现实挑战，引入自动化工具来实现证书的全生命周期管理，已经不再是“可选项”，而是确保稳定运维的必然选择。从证书的申请、签发、验证，到部署、续期、替换，每一步都需要被纳入标准化、可控、可审计的流程之中。

浏览器和 SSL

不得不承认，SSL/TLS 加密已成为现代互联网的“标配”，不再只是金融、电商等敏感场景的“加分项”，而是几乎所有互联网服务的“起跑线”。这一趋势在浏览器、操作系统的推动下，正在加速普及。

HTTP/2、HTTP/3 协议要求加密

HTTP/2 虽然在协议上没有强制要求加密，但在实践中 HTTP/2 必须使用 TLS 加密。HTTP/3 则是强制要求使用 TLS 加密。这意味着不支持 SSL 的站点无法使用这些协议带来的性能优势。

现代浏览器在隐私模式下强制启用加密连接

现代浏览器（如 Chrome、Firefox、Safari）在无痕/隐私模式中默认使用 HTTPS 连接，以避免 ISP 跟踪用户。只要网站服务器支持 HTTPS，就优先使用 HTTPS 方式连接，而不是通过 HTTP 向 HTTPS 升级。当网站确实不支持加密连接时，会明确提示用户。

[图片: 20250519002532]
https://static.txisfine.cn/upload/20250519002532.png/pkwatermark

现代浏览器对 HTTP 页面被明确标记为“不安全”

现代浏览器地址栏中，所有 HTTP 网站都会被打上“不安全”标签，严重影响用户信任感，尤其在登录、支付等场景中尤为敏感。

[图片: 20250519002924]
https://static.txisfine.cn/upload/20250519002924.png/pkwatermark

现代浏览器过期或自签名证书被重点警示

对于过期、无效或自签名的证书，浏览器将弹出明显警告，甚至直接阻止访问，用户需“强制忽略风险”才能继续浏览。

结语

从 SC-081 的通过可以看出，SSL 证书行业正在迈向“更短生命周期、更强自动化、更高安全性”的新阶段。这既是技术发展的必然趋势，也是行业对现实挑战的主动应对。未来，证书将不再是“买一次管一年”的低频运维事项，而是一个需要纳入日常 DevOps 流程、持续监控与自动化处理的关键资产。面对愈发严苛的证书政策和愈加复杂的系统架构，我们要做的不是回避变化，而是用工具与流程将不确定性变为确定性，让安全真正“跑在业务前面”，而不是在事故发生后才追悔莫及。