证书九十天有效，自动续期该配在哪一步

HTTPS 证书只有九十天有效期，这个周期不算长，但也不至于短到可以忽略。官方建议的续期节奏是每六十天跑一次续期任务，验证通过后的缓存授权最长保留三十天。按这个口径，自动续期应当作为部署流程里的固定步骤存在，位置在「证书签发完成之后、站点服务重载之前」，由计划任务定时触发，而不是等浏览器提示证书将要过期时再手工处理。判断它是否真的续上，依据是线上证书的实际到期日期，不是任务日志里有没有报错。

为什么证书只给九十天

短有效期是用时间换安全：密钥泄露的影响面被压缩到几十天内，误签发的存续时间也短。代价是站点必须把续期当成常规运维动作。对内容管理系统来说，这属于部署环节的一部分，和选服务器、配域名是同一层事情。AnQiCMS 的几种部署方式都落在这一层：宝塔面板与 aaPanel 一键部署、LNMP 命令部署、Docker 镜像部署，应用默认监听 8001 端口，证书与跳转通常由前置的 Nginx 负责，续期任务也就跟着装在宿主机的计划任务里。

提前多久开始续，多久跑一次

按公开口径把节奏定成：六十天触发一次，到期前三十天视为安全余量。任务本身要幂等——证书还早就直接退出，快到期才发起签发。两条细节容易忽略：一是验证记录有缓存保留期，短期内重复申请不一定每次都走完整域名校验；二是续期成功不等于生效，新文件必须被服务进程加载，否则线上仍在用旧证书。

续期任务放在哪一层

三个常见位置，按可控程度排序：

面板层最省事。宝塔面板与 aaPanel 的证书管理自带自动续期开关，勾选后由面板的计划任务执行，续期与重载都由面板完成，适合单站点、目录结构标准的场景。

宿主层最可控。用命令部署或 LNMP 环境时，把续期脚本写进 root 用户的 crontab，一天触发一次，脚本内部判断剩余天数；重载放在同一脚本的末尾，并保证重载失败时返回非零，便于外部监控捕获。

容器层最容易踩坑。Docker 部署时证书文件在镜像或挂载卷里，续期任务若跑在容器内，容器重建就丢失任务与结果。把任务留在宿主机、证书目录用卷挂载共享、重载通过宿主层的代理服务完成，是更稳的组合。

换证之后要检查的跳转

证书换了，旧地址还在。检查三处：

• http 到 https 的跳转必须按规则统一收口。AnQiCMS 后台有 301 跳转管理，可以设置 URL 重定向规则，把带协议与裸域的组合统一导向规范地址，避免同一内容出现四个入口。
• 页面里的绝对地址。历史文章或模板里写死的旧协议地址会造成混合内容，浏览器会拦掉不安全资源，表现为样式错乱或图片不显示。全站替换工具适合做这类批量替换，替换前先限定范围，改导航与单页里的硬编码地址时格外小心。
• robots 与站点地图里登记的地址协议。协议还写着旧的一边，抓取到的就是需要跳转的一边。

怎么确认真的续上了

三步，从上到下依次是：

第一步看线上证书。在浏览器打开站点查看证书详情，或在服务器上用命令查询对端证书的到期日期，确认日期已经推后。第二步看任务历史。计划任务的执行记录要保留成功与失败两种结果，连续多次失败要能被发现，AnQiCMS 支持邮件提醒，可以把这类通知发给维护者。第三步看回退能力。换证属于会影响全站访问的操作，操作前留一份备份，AnQiCMS 的备份与恢复覆盖数据与静态文件，出问题时可以按备份回退，而不是临时找证书文件。

常见问题

证书没到期就跑续期会不会有问题？ 任务应写成幂等：剩余天数充足时直接跳过。频繁无谓申请可能触发速率限制，把判断放在申请之前。

自动续期失败一次就要紧张吗？ 看余量。六十天节奏下有三十年安全窗口，单次失败有时间补救，但连续失败且无人知情才是风险，所以通知链路要独立验证一次。

只换证书不配跳转行不行？ 短期能访问，但旧协议地址仍然可达，搜索结果里会同时存在两个版本，后续统一收口时改动面更大。

Docker 部署要不要在容器里装续期任务？ 不建议。容器是可随时重建的一次性环境，续期任务与执行状态应当留在宿主机层，证书目录通过挂载卷共享。