Back

开发者 SSL 证书指南

OpenReplay Team

Dec 4, 2025 · 2 min read

你已经部署了 API,本地一切正常,但生产环境却因证书错误而崩溃。也许证书在一夜之间过期了。也许证书链不完整。也许你接手了一个每年手动更新一次证书且没有任何文档的系统。

证书故障会导致真实的服务中断。Microsoft、Slack 和无数其他公司都曾公开经历过这种情况。对于部署启用 HTTPS 的站点或 API 的开发者来说,理解 SSL 证书不是可选的——而是基础性的。

本指南涵盖证书的实际含义、现代部署如何获取和更新证书,以及在行业推动缩短证书有效期的趋势下,哪些实践能让你的系统保持运行。

核心要点

TLS 证书将公钥绑定到域名身份,需要完整的信任链才能正常工作
DV、OV 和 EV 证书提供相同的加密——区别在于验证流程,而非安全强度
随着证书有效期到 2029 年缩短至 47 天,通过 ACME 自动更新现已成为强制要求
避免证书固定、手动更新流程和硬编码 CA 假设,以防止运维故障

证书的实际含义

TLS 证书将公钥绑定到身份(通常是域名)。当浏览器连接到你的服务器时,它会检查证书是否有效、未过期,并由受信任的证书颁发机构(CA)签名。

信任链的工作原理如下:你的证书由中间 CA 签名,中间 CA 由浏览器和操作系统已经信任的根 CA 签名。如果任何环节断裂——缺少中间证书、根证书过期、域名错误——连接就会失败。

证书包含一个主题备用名称(SAN)字段,列出其有效的域名或 IP 地址。旧的通用名称(CN)字段在验证用途上已被弃用。现代客户端要求使用 SAN。

DV、OV 和 EV:什么才真正重要

域名验证(DV)证书证明你控制某个域名。验证是自动化的,只需几秒钟。

组织验证(OV)和扩展验证(EV)涉及对你的法律实体进行人工检查。它们成本更高,耗时更长。

实际上重要的是:加密是相同的。EV 证书曾经会显示绿色地址栏,但浏览器已经移除了这种 UI 区别。对于大多数开发者来说,来自 Let’s Encrypt 的 DV 证书已经足够且免费。

不要基于 EV 视觉指示器构建假设——它们已经消失了。

TLS 证书生命周期和自动化

公共 TLS 证书的有效期很短且正在变得更短。Let’s Encrypt 签发 90 天有效期的证书。CA/浏览器论坛已经批准分阶段降低最大证书有效期,从 2026 年的 200 天上限开始,到 2029 年将缩短至 47 天。

这使得自动化证书签发和更新成为强制要求,而非可选项。手动更新流程将无法大规模运作。

标准方法使用 ACME 协议,它自动化整个生命周期:

你的 ACME 客户端请求证书
CA 要求你证明域名控制权(通过 HTTP 或 DNS)
你自动响应挑战
CA 签发已签名的证书
你的客户端安装证书并安排更新

Certbot 是最常见的 ACME 客户端,但每个技术栈都有替代方案:acme.sh 用于 shell 环境,Caddy 内置 ACME,以及用于 Node.js、Go 和 Python 的库。

ACME 和 Let’s Encrypt 最佳实践

将更新集成到部署流程中,而不是作为附加流程。证书应该自动更新,无需人工干预。

关键实践:

提前更新:在剩余 30 天以上时触发更新,而不是在过期时
监控过期:使用工具如 cert-manager (用于 Kubernetes)或基于 cron 的简单告警
测试更新:在 CI 中运行 certbot renew --dry-run 或等效命令
避免 CA 锁定:不要硬编码关于使用哪个 CA 的假设

安全存储私钥。永远不要将它们提交到代码仓库。使用适合你平台的密钥管理方案。

短期和 IP TLS 证书

短期证书(几小时到几天)在密钥被泄露时减少暴露窗口。一些组织签发有效期为 24 小时或更短的证书。

IP TLS 证书——用于 IP 地址而非域名的证书——在没有 DNS 可用的开发和 DevOps 场景中很重要。Let’s Encrypt 现在通过 ACME 支持短期 IP 证书,使其与更广泛的自动化、短期签发趋势保持一致。

对于本地开发,像 mkcert 这样的工具可以创建本地信任的证书,无需涉及公共 CA。

为后量子时代 TLS 做准备

量子计算机最终将破解当前的加密算法。大型服务提供商已经在生产环境中部署混合后量子 TLS,尽管这不是应用开发者需要手动配置的内容。

作为应用开发者,你不需要自己实现这个。保持 TLS 库更新,使用当前配置,避免使用已弃用的算法,如 SHA-1 或低于 2048 位的 RSA 密钥。

过渡将在库和基础设施层面发生。你的工作是不要用过时的依赖或硬编码的假设来阻碍它。

容易过时的假设

避免这些模式:

期望多年有效期的证书:最大有效期正在缩短
硬编码 CA 身份:CA 可能被取消信任,根证书会轮换
手动更新流程:它们无法扩展且会静默失败
证书固定:当证书更改时会造成运维噩梦
忽略证书清单:你无法更新你不跟踪的内容

结论

现代 TLS 证书管理需要自动化。行业正在向更短的有效期发展,这意味着 ACME 客户端、更新流程和监控是基本要求。

使用 Let’s Encrypt 或类似的自动化 CA。将更新集成到部署流程中。跟踪你的证书。保持库的更新。这些实践将使你的 HTTPS 部署在标准持续演进时保持可靠运行。

常见问题

当证书过期时,浏览器和客户端将拒绝与你的服务器建立安全连接。用户会看到警告消息,API 调用失败,自动化系统中断。大多数现代浏览器会完全阻止访问,而不是允许用户继续。这就是为什么带有提前触发的自动更新至关重要。

可以,通过主题备用名称(SAN)。单个证书可以在其 SAN 字段中列出多个域名或子域名。通配符证书覆盖单个级别的所有子域名,如 *.example.com。但是,通配符需要基于 DNS 的验证,并且不会自动覆盖根域名。

短有效期通过限制私钥被泄露时的暴露时间来提高安全性。它们还强制自动化,从而减少人为错误。CA/浏览器论坛正在推动将有效期进一步缩短,到 2029 年缩短至 47 天,这使得手动更新流程越来越不切实际。

通常不应该。证书固定将你的应用程序锁定到特定证书或公钥,这在证书轮换时会造成严重的运维问题。如果你进行了固定,然后需要意外更改证书,你的应用程序就会中断。现代替代方案如证书透明度日志可以提供安全优势,而不会带来运维风险。

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.