Nginx 配置没人敢动？老系统的 SSL 证书续期，真的不应该这么折腾

做运维久了，应该都遇到过这种服务器。

一台 Linux 服务器，上面跑着几十个网站，Nginx 配置文件堆了好几层目录。主配置文件里面 include 了一堆子配置，有些站点的配置甚至已经不知道是谁写的、为什么这么写。

有些是五六年前留下来的老系统，有些经过好几任运维交接，还有一些是业务部门自己改过的配置。

平时不出问题，大家都相安无事。

但每次碰到 SSL 证书续期，就开始头疼。

不是不会改，是不敢改

Nginx 的配置其实并不复杂，真正复杂的是那些跑了很多年的生产环境。

你可能会遇到：

• 一个 Nginx 实例托管几十个甚至上百个域名。

• 同一个站点配置拆分在多个文件中，通过 include 引入。

• 不同业务使用不同的证书路径。

• 反向代理、rewrite、特殊 location 配置相互交织。

• 有些配置早已没人维护，原来的开发人员也联系不上了。
  这时候，如果只是为了更新一个 SSL 证书，就需要修改 Nginx 配置、调整证书路径、重新加载服务。
  你敢保证不会影响其他业务吗？
  尤其是一些历史遗留系统，配置文件可能连当前运维人员都不完全了解。

• 最稳妥的办法往往是： 能不动，就尽量别动。
  但证书不会因为你不敢动 Nginx，就停止过期。

SSL 证书续期，本来不应该这么复杂

• 正常情况下，SSL 证书自动续期应该是一个非常简单的事情：

1. 检查证书有效期。

2. 提前申请新证书。

3. 验证域名所有权。

4. 更新证书文件。

5. 让 Nginx 加载新证书。

问题在于，很多工具只解决了前面几步，最后一步还是需要运维人员自己处理。

特别是 Nginx 配置比较复杂的环境，自动化脚本很难保证能够正确识别所有证书配置。

于是就出现了一个尴尬的情况：

证书申请成功了，但部署还得人工完成。

所谓的自动续期，最后还是没能真正自动化。

后来我们做了 httpsok

• httpsok 最初就是想解决一个问题：

  能不能不修改现有 Nginx 配置，就把 SSL 证书自动续期这件事做好？

  我们的思路比较直接：

  不重写你的 Nginx 配置，不要求你调整现有目录结构，也不要求你为了一个证书续期去改造整个服务器。

  尽可能识别现有 Nginx 配置，找到对应站点使用的证书，然后将新证书部署到正确的位置。

  对于已经运行多年的老系统，尽量保持原来的运行方式。

它能做什么？

• 自动发现 Nginx 配置：识别现有配置目录及站点证书配置，尽量适配已有环境。

• 自动申请证书：支持 Let’s Encrypt、ZeroSSL、Google 等 CA。

• 自动 DNS 验证：支持 DNS API 验证，包括泛域名证书。

• 自动部署证书：将新证书更新到对应位置，不需要手工复制、粘贴。

• 自动续期：证书到期前自动完成续期和部署。

• 多域名、多服务器管理：不需要每台服务器都单独维护一套复杂的续期脚本。

• 续期监控与通知：及时了解证书状态，避免证书过期了才发现。
  我们更关注的是生产环境能不能稳定运行，而不是让运维人员多学一套复杂的配置方式。

特别适合这些场景

1. 多年没有人敢动的历史遗留系统

Nginx 配置复杂，原开发人员已经离职，现有业务又不能停。只要能保持现有配置不变，就尽量不要增加额外风险。

2. 一个 Nginx 管理几十个网站

每个站点的证书路径可能不同，手动续期非常麻烦。自动识别、自动部署可以减少大量重复劳动。

3. 业务系统比较多，没有专职运维人员

很多中小企业并没有专门的运维团队，证书续期往往靠某个人记在日历上。自动化以后，就不用天天惦记着证书什么时候过期。

4. 不方便修改现有部署架构的服务器

不需要为了证书续期去重构 Nginx 配置，也不需要迁移现有网站。

最后说几句

• 做运维这些年，我越来越觉得：

  生产环境最重要的不是把所有东西都改成自己喜欢的样子，而是在保证业务稳定的前提下，把该自动化的事情自动化。

  尤其是历史遗留系统。

  能不动的配置，就不要为了一个小功能去动它。

  SSL 证书续期这种事情，本来就不应该成为运维人员的心理负担。

  如果你也有一台配置复杂、没人敢动的 Nginx 服务器，可以试试 httpsok。

  官网：https://httpsok.com

  一行命令，自动化 HTTPS。