OpenVPN 证书续期：交付证书，而不是定时器

两套续期设计在设计评审中看起来完全相同，到了一月却表现得截然不同。第一套跑一个定时器，重新签发证书，把文件丢进共享文件夹。第二套把续期当作交付问题：谁提出请求、什么能证明资格、材料如何到达设备、又是什么让客户端真正用上它。只有第二套能在离线笔记本、已退役资产和一次悄无声息的交付失败中存活。

在两套设计真正不同之处进行比较

定时器型设计优化的是服务器一侧。计划任务调用 CA，新证书出现，运维人员就认为大功告成。签发之后发生的一切都成了别人的问题，直到某台设备连不上，而到期日期解释了原因。

工作流型设计优化的是最后一公里。它假定签发只是链条中的一环，后续每一步都可能独立失败。这样构建成本更高，运营成本却低得多，因为故障会以被跟踪的状态出现，而不是以过期客户端的形式出现。

把差异保持在视野中的有用办法，是每套设计都必须明确点名的顺序。

detect window -> authenticate request -> authorize -> issue
-> deliver and stage -> activate -> verify fresh auth -> retire old material

从证书本身检测窗口

有效期要读客户端实际出示的证书，而不是读复制来的文件名里嵌入的日期。文件名会漂移，写着 2026 的文件可能装着三月就过期的凭据。

在窗口里为慢速情形留出余量：离线数周的设备、需要真人处理的审批，以及会先失败一次才走通的交付路径。一个报告成功的定时器只能证明定时器跑过，仅此而已。

在签发任何东西之前先授权请求

现有证书可以是合法续期机制的一部分，但它的主体文本并不是授权决定。要回答的问题是：这个账户和这台设备是否仍有权在设备群中拥有身份，而这个答案存在于你的资产记录里，不在证书里。

计划任务仍在运行的退役笔记本，不应获得新的权利。 RFC 7030 这里值得一读，因为它把经认证的重新注册与服务端授权和策略分开；这是可以借鉴的模型，而不是声称 OpenVPN 或 EasyRSA 提供该协议。

交付、暂存与激活作为独立步骤

签发保留了身份、用途和签发关系，而用新密钥对生成的替代品，如果配对的私钥不随之同行就毫无用处。密钥对要通过背后有访问控制设计的渠道交付，因为无法猜测的 URL 是隐蔽，不是控制。

暂存正是大多数自动化悄然断裂的地方。导入的配置文件可能停在一个位置，管理员却在另一个位置更新文件，客户端会一直出示旧证书，直到有人发现。写清客户端读取的路径、允许写入的账户，以及触发重新加载的事件。然后确认替代品确实是正在使用的文件，而不是放在旁边的一份副本。

验证意味着用新材料做一次全新的认证，并检查用户真正需要的应用。已经建立的隧道可能仍反映旧的凭据，所以一条打开的连接并不是续期成功的证据。

先设计错过窗口后的恢复

当笔记本只能通过 VPN 访问注册服务时，到期会形成一个循环：设备需要证书才能进入隧道，而隧道又需要证书才能取回。在第一项计划任务上线之前就定好带外安排，无论那是单独认证的注册端点，还是管理员协助的重新注册。

无论选哪种，它都必须验证请求者和当前权利。把服务器配置成接受任何请求者的过期证书，不是恢复路径，而是对你用设计其余部分守护的那道检查的永久削弱。

最后，把续期和失陷放在不同的流程里。泄露的密钥需要吊销并对活跃会话作出响应，而延长到期日期并不包含这些。把离线设备、失败的交付和退役资产纳入验收测试，计划就可以启用了。