我最近整理了一个自己之前写的项目，叫 Certwarden。
它不是一个“再造轮子式”的玩具项目，而是一个我觉得在真实运维场景里真的能用得上的东西：
一个面向团队、平台和托管场景的多租户 SSL/TLS 证书监控系统。
如果你手上只有一两个域名，证书快过期了，自己记一下也能扛。
但只要数量一上来，事情就会立刻变味：
- 哪些域名的证书快过期了
- 哪些证书其实已经异常了
- 哪些域名属于哪个客户、哪个租户
- 谁该收到通知
- 有没有一个页面能直接给别人看当前状态
很多团队不是没有意识到证书重要，而是压根没有一套顺手的方式把这件事持续管起来。
所以我写 Certwarden，解决的就是这个问题。
Certwarden 到底是什么
先用一句人话概括：
Certwarden 是一个自托管的证书监控平台。
它会持续检测证书健康状态、记录历史结果、驱动通知告警，并且给每个租户生成独立的公开状态页。
注意这里有两个关键词：
- 自托管
- 多租户
这也是它和很多“自己写个定时脚本检测一下域名证书”的做法最不一样的地方。
它不是只服务你自己的单机脚本，而是从一开始就按“团队和平台使用”这个方向设计的。
我为什么会写这个项目
因为证书监控这件事，真的很容易处于一种很尴尬的状态：
- 你知道它重要
- 但平时又不会一直盯着它
- 一旦出事，影响通常不小
- 可真让你手工管，又很烦
尤其是托管类业务、SaaS、或者给别人维护一批站点时，证书这件事很容易变成“大家都知道该管，但没人持续在管”。
最常见的结果就是：
- 快到期了没人注意
- 某个客户的域名挂了几天才发现
- 告警只发到一个不常看的邮箱
- 证书状态根本没法对外展示
你会发现，问题从来不只是“有没有检测”，而是：
有没有一个能长期跑、能通知、能展示、还能分清是谁的数据的系统。
Certwarden 就是朝这个方向去做的。
它解决的不是一个点，而是一整条链
如果只说“证书监控”，很多人第一反应会觉得不就是定时连一下 443 吗。
问题在于，真实场景比这个复杂很多。
1. 你不只是想知道过不过期
Certwarden 不只是看证书有效期，它会把更完整的信息都拉回来：
- 生效时间
- 到期时间
- 颁发机构
- 主题
- CN
- SAN
- 序列号
- SHA-256 指纹
- 签名算法
也就是说，它不是只告诉你“还有多少天”，而是把证书本身的状态信息尽量完整地放到一个地方。
这在排查问题时会非常省事。
2. 你不只是想自己看，还想通知到人
Certwarden 支持：
- Telegram
- Webhook
而且不是那种只能配一个全局通知目标的粗糙模型。
它支持租户级和域名级的通知策略，也支持在界面里直接测试通知端点是不是通。
这一点我自己很看重。
因为很多所谓“支持通知”的系统，最大的问题就是你配完了，根本不知道它到底能不能真正打到目标。
3. 你不只是想内部看，还可能要对外展示
这也是 Certwarden 和很多单机证书监控工具差别很大的地方。
它支持给每个租户生成独立的公开状态页：
| |
而且还支持自定义标题和副标题。
这件事在真实业务里很重要。
因为你迟早会遇到这种需求：
- 我想把某一组域名状态给客户看
- 我想给某个团队一个只读状态页
- 我不想把管理员后台暴露出去
- 我只想把结果展示出去
很多时候，能不能对外展示，决定了这东西是不是能真正进入工作流。
它为什么是“多租户”，而不只是“多用户”
我觉得这是 Certwarden 最值得强调的地方之一。
很多项目在权限模型上做得很含糊：
- 有用户
- 也能登录
- 也能加数据
但只要你一旦想拿去给多个客户、多个团队、多个业务组用，问题就会冒出来。
Certwarden 从一开始就不是按“一个人自己玩”的模型去做，而是按 account-as-tenant 这个方向来设计。
它在共享数据库里通过 tenant_id 隔离数据。
这意味着：
- 不同租户的数据天然分开
- 租户各自有自己的域名列表
- 租户各自有自己的通知端点
- 租户各自有自己的公开状态页
这类系统如果一开始不考虑多租户，后面几乎一定要重构。
所以我觉得早点把这个边界想清楚，是值得的。
我在这个项目里比较坚持的几个设计点
用户名优先认证
很多系统习惯把邮箱作为主标识。
但在一些内部平台、托管系统、或者团队场景里，用户名优先其实更顺手。
所以 Certwarden 里注册只需要用户名和密码，邮箱是可选绑定信息。
这听起来像小事，但我一直觉得这类系统里，认证模型应该服务使用场景，而不是机械套模板。
默认 SQLite，但不是锁死 SQLite
我不喜欢那种一上来就逼用户先配完整数据库体系，才能体验项目的做法。
所以 Certwarden 默认就能直接用 SQLite 跑起来。
但它不是只能 SQLite，也支持：
- MySQL
- PostgreSQL
这条路我觉得比较现实：
- 先让你尽快跑起来
- 后面再按规模决定是否切数据库
Go 做调度和检测
调度器和检测执行这部分，我用的是 Go 的调度器和协程池。
原因也很朴素：
- 这种任务天然适合并发
- 证书检查本来就是网络 IO 型工作
- Go 在这种场景下写起来很顺手
前端不是摆设
Certwarden 不是那种“后端有了，前端凑合一下”的项目。
它有完整的 React 管理台，核心页面包括：
- 登录页
- 租户后台
- 公开状态页
- 管理后台
这点其实对推广和落地都很重要。
因为很多项目功能再全，一旦没有像样的界面，最后就只能停留在“开发者自己能用”。
它现在能做到什么程度
从 README 和当前版本来看，Certwarden 现在已经具备了比较完整的第一版形态。
仓库当前版本是：
| |
而且从最近几次提交也能看出来，这项目不是“堆个 demo 就不管了”，而是在持续补齐产品层面的东西，比如：
- 管理后台分页
- Telegram Bot 配置
- 通知端点测试
- README 和项目落地说明
- Docker / CI / 多架构构建
这说明它已经不是“只有作者自己知道怎么跑”的状态，而是在往真正可交付、可复用的方向走。
你可以怎么用它
如果你只是想先体验一下，最短路径其实很直接。
1. 克隆仓库
| |
2. 准备环境变量
| |
3. 直接启动
| |
默认情况下，它就能先用 SQLite 跑起来。
对我来说，这一点非常重要：
先跑起来，再慢慢配细节。
而不是一上来就被复杂部署卡死。
如果你喜欢 1Panel，这项目也能直接接
README 里已经明确写了，第一版就是按 Compose 兼容去做的，所以你可以直接把项目里的 docker-compose.yml 导入 1Panel。
推荐流程也很清晰：
- 导入
docker-compose.yml - 参考
.env.example填环境变量 - 设置
APP_BASE_URL、数据库和管理员账号 - 启动服务
这意味着它对面板用户也比较友好，而不是只照顾命令行派。
一些我觉得会打动真实用户的点
如果你要问我，Certwarden 最值得拿出来讲的卖点是什么，我会给这几个：
1. 它不是只做“提醒”，而是做“管理 + 展示 + 通知”整条链
很多工具只解决其中一个环节。
Certwarden 解决的是完整工作流。
2. 它一开始就考虑了多租户
这点对平台类场景特别重要。
3. 它默认部署门槛不高
SQLite + Compose 直接拉起来，这个很关键。
4. 它真的考虑了真实使用体验
比如：
- 用户名优先认证
- 通知端点测试
- 租户自定义 Telegram Bot
- 公开状态页
这些都不是“为了写 README 好看”的点，而是你真用起来会感受到差异的点。
这个项目适合谁关注
我觉得下面几类人会比较适合看 Certwarden：
- 手上有多域名、多证书的运维
- 做 SaaS 或托管平台的人
- 需要把证书状态对客户展示出去的人
- 想把 Email / Telegram / Webhook 告警统一起来的人
- 想找一个可自托管、又不是玩具的证书监控系统的人
最后
我一直觉得，证书监控这种东西很典型：
平时你不太会主动想起它，但一旦出问题，代价往往不小。
而且它最烦的地方不是技术难，而是数量一上来之后，靠人记和靠人盯根本不靠谱。
所以如果你已经不止在管一两个域名，不止在给自己一个人用，最好还是早点把这件事系统化。
Certwarden 就是我朝这个方向做出来的一个项目。
如果你感兴趣，可以直接看仓库：
| |
项目名就叫：
Certwarden
评论