SSL 证书的有效期即将减半。为 60% 的所有网站证书提供支持的 Let's Encrypt 正在从最长 90 天调整为最长 45 天。Google 的 CA/Browser 论坛提案也朝着同样的方向迈进。整个证书行业正将缩短有效期作为安全标准推进，而时间表不再是理论上的设想。
对于需要在数百或数千个域名上管理重定向基础设施的团队来说，这不是一个小幅调整——而是运营层面的倍增效应。原本每个域名每年需要 4 次续期的工作，很快将变为 8 次。在 90 天有效期下勉强还能运转的手工流程，在 45 天有效期下将彻底失效。
本清单旨在帮助基础设施团队从六个关键领域评估自身的就绪程度：自动化、监控、续期时机、告警、通配符策略以及灾难恢复。每个部分都包含一个自评问题和目标状态。到最后，你将清楚地知道你的基础设施处于什么水平——以及在 45 天时代到来之前需要做哪些改变。
1. 自动化：零触达证书生命周期#
你就绪性评估中最重要的一个问题：签发和续期的每一张证书，是否都在没有人工介入的情况下完成？
如果答案不是一个毫无保留的“是”，那你就有问题。在 45 天有效期下，手工证书运维在相当小的规模下就会变得不可持续。仅一个包含 50 个域名的证书组合，每年就需要 400 次证书操作——平均每天不止一次，而且还包括周末和节假日。
当前状态自评：你们团队今天是如何进行证书签发/配置的？如果答案涉及日历提醒、电子表格、手工生成 CSR，或“通常由某个人来处理”，那你们属于手工层级。即使你已经把流程脚本化，也要追问：脚本是否覆盖每一个域名、处理每一种边界情况，并且在每一次失败时都能自行恢复，而不需要人工升级。
目标状态：在重定向基础设施中，配置 DNS 后，重定向基础设施里的每个主机名都会通过 ACME 自动完成 SSL 证书的签发。证书的签发、安装和续期都无需任何人工操作。系统会在新增域名时自动检测，通过 DNS-01 挑战验证所有权，发起证书请求，将证书安装到边缘节点，并在主机名添加后的数秒内安排下一次续期。
一种按主机名管理 SSL 的重定向平台——而不是要求你按服务器去管理证书——可以彻底消除自动化缺口。当 DNS 被委派给平台后，SSL 就成为基础设施的属性，而不是某个人待办事项中的一项任务。
2. 监控：在它出问题之前就知道#
问问自己：你是否在所有域名上都启用了有效的证书到期监控？
监控是自动化之下的安全网。即使使用基于 ACME 的续期，也可能出问题：DNS 记录被更改、触发了速率限制、某个 CA 遭遇故障。没有监控，你发现过期证书的方式就和你的用户一样——通过浏览器警告。
但监控不仅仅是检查到期日期。对重定向基础设施而言，有效的监控意味着来自多个全球位置的健康检查。因为从你办公室看起来有效的证书，可能会在用户位置失败——原因可能是边缘传播延迟或 CDN 缓存。
当前状态自我评估：你是否有一个仪表盘或告警系统，能显示每个域名的证书到期日期？证书在续期后是否会在实时更新？你能否一眼看出哪些域名正在临近到期，哪些已经失败？
目标状态：来自多个全球边缘位置的持续证书健康监控。系统会执行主动的 TLS 握手检查——不仅仅是到期日期查询——以验证每个证书都有效、受信任且正在正确提供服务。仪表盘会在所有域名上显示实时状态。监控是自动的：当添加新的主机名时，无需配置即可开始监控。
3. 续期时机：缓冲区#
问题是：续期是否足够早，能够在持续数天的故障中幸存？
对于 90 天有效期的证书，在到期前 7-14 天进行续期能提供一个舒适的缓冲区。对于 45 天有效期的证书，相同的缓冲区会消耗证书总可用寿命的 15-30%。这迫使你在两者之间做权衡：续期太早，你就会不断更换证书；续期太晚，临时的 CA 故障就会变成生产事故。
Let’s Encrypt 的速率限制还增加了另一个维度。“重复证书（Duplicate Certificate）”限制允许同一组主机名每周最多 5 个证书；“每个已注册域名（Certificates per Registered Domain）”限制则将每周最多限制为 50 个证书。在 45 天的续期周期下，大型域名组合可能比预期更快触及这些限制——尤其是当你还在为新域名同时签发证书时。
当前状态自我评估：你的续期窗口是什么？如果你的团队手动续期证书，续期是否至少在到期前 15 天开始？如果发生 5 天的 CA 故障，你是否能确保没有任何证书过期？你是否测试过当一次续期尝试失败时会发生什么——系统会自动重试吗，还是会等待人工介入？
目标状态：自动续期在到期前30天开始，并采用指数退避的重试逻辑。如果第一次尝试失败，系统会在逐渐增加的间隔进行重试——1小时、4小时、12小时、24小时——直到续期成功。速率限制会被自动跟踪并遵守。系统能够承受数天的CA故障，而不会导致任何域名在到期日当天失效，因为续期启动得足够早，始终至少有15天的缓冲期。
4. 告警：在之前，而不是在之后#
问题是：正确的人是否会在证书到期之前收到通知——而不是到期之后？
告警的作用在于区分“非事件”和“事故”。当证书续期失败时，需要发生两件事：系统会自动重试（见第3节），并且正确的人知道这件事。如果你的监控在未告警任何人的情况下发现了已过期的证书，你仍然存在漏洞——只是你更快地发现了它。
告警应按严重程度和受众分级。一次续期失败但在30分钟后成功重试的不需要凌晨2点的紧急通知——但它应该出现在每日摘要中。证书在最终72小时内仍未成功续期，这是需要立即通知值班工程师的关键告警。
当前状态自查：当证书即将到期时，谁会被通知？是否有分级告警系统，包含不同的严重程度？告警是否会根据紧急程度发送到正确的渠道（Slack、邮件、PagerDuty）？如果主要值班人员不可用，告警是否会升级？
目标状态：三层告警：信息（已发起续期、每日摘要），警告（续期失败、7天窗口、Slack/邮件），严重（续期反复失败、72小时窗口、PagerDuty/值班升级）。告警包含域名、证书到期日期、上次续期尝试时间以及失败原因。投资组合中的每个域名都覆盖——没有例外，没有“我们会手动监控那个”。
5. 通配符证书：便利性 vs 风险#
问题是：通配符证书是否被正确处理，还是在制造单点故障？
通配符证书很诱人：一张证书（*.example.com）覆盖所有子域名。一次续期。一个到期日期。一个需要管理的东西。可“那个需要管理的东西”也是一个可能失败的东西——一旦它失败，所有子域名会同时陷入黑暗状态。
仅针对重定向基础设施而言，通配符会带来另一个问题：DNS-01 挑战用于通配符证书时，需要访问根域（apex domain）的 DNS 区域。如果你的重定向域名分布在多个注册商和 DNS 提供商——在大型资产组合中很常见——那么为单个通配符管理 DNS-01 挑战会比为每个主机名分别管理证书复杂得多。
当前状态自评：你是否在重定向域名中使用通配符证书？如果通配符证书无法续期，会影响多少个域名？你是否有经过验证的回滚方案？通配符由与管理每域证书相同的团队负责，还是由不同团队以不同流程管理？
目标状态：按主机名（每个域）签发证书是默认做法。每个域名都有自己的证书，独立进行签发与续期。这带来隔离性：某个域名的续期失败不会影响任何其他域名。通配符仅在明确需要时使用（例如：共享子域背后的内部服务），并配套独立的监控与告警——同时提供已记录且经过测试的恢复流程。
6. 灾难恢复：当 CA 宕机时#
问题是：如果你的证书颁发机构（CA）在 5 天内不可用，你的证书还能继续工作吗？
Let's Encrypt 过去曾发生过持续数小时的停机。在 90 天的证书有效期下，2-3 天的停机是可承受的——证书仍有足够的剩余有效期来“熬过去”。但在 45 天的有效期下，同样的停机可能会把证书推到续期窗口之外，然后 CA 才重新上线。
SSL 的灾难恢复不只是关于 CA。还涉及 DNS——如果你的 DNS 提供商在 DNS-01 挑战窗口期间发生故障，挑战就会失败，续期会被阻止。还涉及边缘传播——如果续期后的证书在旧证书过期前未传播到所有边缘节点，部分用户会看到错误。还涉及续期流水线本身——如果你的自动化平台发生故障，续期会排队等待还是会被丢弃？
当前状态自评：你是否模拟过 CA 连续 5 天宕机期间会发生什么？你在整个资产组合中最短的证书有效期窗口是多少？你是否配置了备用 CA，还是所有证书都绑定在同一个提供商上？你的 DNS 基础设施能否在挑战窗口期间的宕机中继续工作？
目标状态：续期足够早，确保每个域名至少保留 15 天的缓冲期——足以应对现实中的 CA 宕机。续期流水线具备韧性：如果因 CA 不可用导致续期失败，当 CA 恢复后系统会自动重试。监控覆盖整个依赖链（DNS、CA、边缘传播），而不仅仅是证书到期日期。关键域名已配置备用 CA，并且团队有已记录且经过测试的操作手册（runbook），可在 CA 长时间宕机期间手动签发证书。
自评：为你的就绪程度打分#
根据下面六个领域为你的基础设施打分。要诚实——低分并不是失败，它是一份路线图。
评分规则：1 = 手动 / 无能力，2 = 部分自动化 / 存在缺口，3 = 大部分自动化 / 缺口较小，4 = 完全自动化 / 无缺口，5 = 完全自动化 + 已测试 / 具备韧性
| Domain | 你的分数（1-5） | Priority if < 4 | 第一步 |
|---|---|---|---|
| ① Automation | __ | Critical | 审计当前的手动步骤——选择一个领域并将其完全自动化 |
| ② Monitoring | __ | High | 为所有领域实施到期监控，并设置提前30天的预警阈值 |
| ③ 续订时机 | __ | Critical | 将所有续订设置为在到期最短期限前30天触发 |
| ④ Alerts | __ | High | 至少配置两级告警：警告（7天）和严重（72小时） |
| ⑤ Wildcards | __ | Medium | 盘点所有通配符证书，并为每张证书记录其影响范围（爆炸半径） |
| ⑥ 灾难恢复 | __ | Medium | 模拟为期5天的CA中断场景，并记录生存差距 |
解读你的总分：
24-30：你已准备就绪。你的基础设施已实现自动化、可监控且具备韧性。保持这一状态，并定期测试你的恢复流程。
18-23：你有扎实的基础，但仍存在差距。优先处理“关键”领域——自动化和续期时机是最高投资回报率（ROI）的改进方向。45天的时间线会对你当前设置造成压力。
12-17：你的基础设施无法应对45天有效期的证书。那些在90天条件下可行的手动流程，在45天时就会失效。先从自动化开始（域①）——如果你只能修复一件事，就把证书的自动签发与续期做成自动化。
6-11：你面临高风险。你投资组合中的每个域名都可能因一次错过的日历提醒或CA中断而暴露风险。考虑迁移到一个重定向平台：把SSL自动化作为基础设施来处理——而不是当作一项任务——以便快速弥补差距。
差距只会越来越大#
“45天证书”时代并不是未来的可能性——它是一个具有明确时间表的行业发展路径。为超过3.6亿个域名签发证书的 Let’s Encrypt 正在引领这一转变。Google 的 CA/Browser Forum 提案也指向同样的方向。标准正在变化，而随着证书有效期不断缩短，自动化与手动基础设施之间的差距只会进一步拉大。
现在就开始自动化的团队不会感受到这种变化。他们会看到自己的仪表盘按时完成续期——每个域名都提前30天、每一次都如此——而其他团队则手忙脚乱地更新表格。上面的清单不仅仅是评估工具。它是一份路线图，指向随时准备好应对行业最终采用的任何证书有效期的基础设施——45天、30天或更短。
为你的基础设施打分。修补漏洞。45天证书时代即将到来——你应该最不用担心的就是重定向域名。
常见问题
Let's Encrypt已宣布计划将最大证书生命周期从90天缩短至45天，预计将在2026年开始过渡。谷歌的CA/浏览器论坛正在推进一项平行提案，表明更短的生命周期将成为行业标准——不仅仅是Let's Encrypt的政策。
在45天的证书生命周期下，每个域名每年需要大约8次续订周期——而90天证书则为4次。对于管理500个重定向域名的团队来说，这意味着每年需要进行4,000次证书操作，而不是2,000次。
最可靠的方法是基于ACME的自动化，您的重定向基础设施可以自动完成DNS-01挑战、配置证书并安排续订。处理每个主机名的SSL的重定向平台——而不是每个服务器——消除了在各个域名之间手动管理证书的需要。
当重定向域名的证书过期时，浏览器会在加载页面之前显示安全警告插页。这会完全阻止重定向——访客无法到达目标。对于营销活动，这意味着失去点击、跟踪中断和信任降低。恢复可能需要几个小时到几天，具体取决于CA传播速度。
通配符证书简化了对单个顶级域名下子域名的管理，但会造成单点故障——如果通配符过期，所有子域名都会受到影响。每个域名的证书提供更好的隔离，但需要更多的管理开销。对于大型投资组合，自动通过ACME为每个主机名配置证书的重定向平台提供了两者的最佳选择：隔离而不增加管理负担。
最佳实践是在过期前至少15天开始续订——对于关键基础设施则为30天。这个缓冲时间考虑了DNS传播延迟、CA故障（可能持续多天）和重试逻辑。对于45天的证书，30天的预续订意味着您几乎在证书发布后立即进行续订——这使得自动化成为不可谈判的要求。
ACME（自动证书管理环境）是一种自动化整个证书生命周期的协议：域名验证、证书颁发、安装和续订。它使用DNS-01或HTTP-01挑战来验证域名所有权，然后自动处理与证书颁发机构的加密交换。ACME是支持Let's Encrypt并使零接触SSL自动化成为可能的协议。
是的。RedirHub通过Let's Encrypt为添加到平台的每个主机名自动配置SSL证书。当DNS指向RedirHub的边缘时，系统会检测主机名，完成ACME DNS-01挑战，颁发证书并安排自动续订——所有这些都无需人工干预。续订将在过期前30天开始，带有自动重试逻辑和故障警报。
Linh handles the backend systems that keep RedirHub fast and reliable. Her work revolves around performance, scalability, and making sure redirects happen instantly, no matter where users are. She likes solving complex problems quietly.
