5.0k Star 的 CertD：用 110+ 插件自动申请和部署证书

证书续期最麻烦的部分，往往不是重新申请，而是把新证书准确部署到每一个使用它的地方：Nginx、CDN、负载均衡、Kubernetes Secret、NAS 和面板服务都可能有各自的更新方式。只要其中一个目标漏掉，自动签发也无法避免过期事故。

CertD 试图把这条链路串起来：申请证书、部署到一个或多个目标、记录日志并发送通知，全部放进可定时执行的流水线中。它的重点不是替代 ACME 协议，而是把证书生命周期做成一个可视化、可追踪的自动化流程。

CertD 是什么

CertD 是一个可私有化部署的开源证书管理系统，采用 AGPL-3.0 许可证。项目名称中的字母 D 沿用了 Linux Daemon 的命名习惯，官方口号是”让你的网站证书永不过期”。更严谨地说，它通过定时重新申请、部署和告警，降低证书因人工遗漏而过期的概率。

与纯命令行 ACME 客户端相比，CertD 提供 Web UI，并把操作组织成流水线。一条流水线可以包含申请证书、部署到多个目标和发送通知等步骤；定时任务会在设定条件下重新签发，任何环节失败都能留下日志并触发告警。

项目目前宣称提供 110 多个部署插件，覆盖主机、阿里云、腾讯云、华为云、Cloudflare、Kubernetes、宝塔、1Panel、群晖、QNAP、Proxmox、Caddy、Traefik 等环境。对同时使用多家云服务的团队，这种现成适配比自己维护多套 SDK 脚本更省事。

核心能力

自动申请证书

CertD 支持通过 ACME CA 申请证书，域名验证方式包括 DNS-01、HTTP-01 和 CNAME 代理。DNS-01 可以申请通配符证书；配置 DNS 服务商凭证后，系统会创建 _acme-challenge TXT 记录，验证完成后再清理。

一张证书也可以包含多个域名，例如同时覆盖 example.com、www.example.com 和 api.example.com。这样能减少证书数量，但也会扩大单张证书和对应私钥的影响范围，是否合并仍要根据权限边界决定。

110+ 部署插件

部署插件是 CertD 最有辨识度的部分。它们把不同目标的更新动作封装成流水线步骤：

• 主机部署可以通过 SSH 上传证书，设置文件路径与权限，并在完成后执行服务重载命令。
• 云服务插件可以调用厂商 API，把新证书绑定到 CDN、负载均衡或其他托管资源。
• Kubernetes 插件可以更新 Secret，再由 Ingress 或工作负载引用。

每一步都会记录日志，便于区分 DNS 权限不足、SSH 连接失败、云凭证过期或目标配置错误。上线前仍应使用测试证书或预发布环境验证插件行为，尤其要确认失败重试不会留下半更新状态。

多种证书格式

CertD 支持 PEM、PFX、DER、JKS 和 P7B 等格式，可以让同一次签发结果适配 Nginx、IIS、Java 应用和其他系统。格式转换减少了重复申请，但私钥导出、密码保护和文件权限仍要单独设计。

通知与监控

项目支持邮件、Webhook、企业微信、钉钉、飞书、AnPush 等通知方式。成功通知可以帮助审计，失败通知则更重要：它应留出足够的人工处理窗口，而不是等到证书即将过期才提醒。

CertD 还提供站点证书监控和到期时间展示。实际使用时，建议把流水线执行失败和外部站点证书临近过期分成两类告警，因为”任务显示成功”并不一定代表公网服务已经加载了新证书。

私有化部署

CertD 可以运行在自己的服务器上，数据库支持 SQLite、PostgreSQL、MySQL 和 MariaDB。DNS API Key、SSH 凭证、证书私钥都属于高敏感数据，私有化部署能让存储位置由团队掌控，但并不自动等于安全。

官方文档建议使用 HTTPS 走访问，并做好主机防护、Web 防护和备份。生产环境还应限制管理端入口、启用 2FA、最小化云凭证权限，并定期演练数据库和证书数据恢复。

典型上手流程

Docker 是相对直接的部署方式。官方提供稳定版与预览版镜像，生产环境应优先选择稳定版并固定版本，而不是长期跟随 latest。

首次使用通常要完成几项配置：创建管理员账号、配置 ACME CA、添加域名验证所需的 DNS 凭证，然后建立流水线。一个典型流程是：

1. 选择 CA 和待签发域名。
2. 选择 DNS-01、HTTP-01 或 CNAME 代理等验证方式。
3. 添加一个或多个部署插件。
4. 配置成功与失败通知。
5. 设置定时策略，并先手动执行一次完整测试。

仪表盘可以集中查看证书到期时间、签发记录、部署历史和步骤日志。真正交给定时任务前，最好再确认目标服务已经加载了新证书，而不只是文件上传成功。

和 acme.sh、Certbot 的区别

acme.sh 和 Certbot 都是成熟的 ACME 客户端，也能通过部署钩子、安装器或插件完成自动更新。CertD 的差异不在于”只有它能部署”，而在于把申请、多个部署目标、日志、通知和多人管理放进一个 Web 流水线中。

如果只维护一台 Nginx，命令行客户端配合定时任务往往更轻，也更容易审计。若证书要同时分发到多家云资源、Kubernetes 和内部主机，CertD 的可视化编排与插件覆盖会更有价值。

Certbot 与 Web 服务器集成成熟，也支持扩展认证和安装插件；acme.sh 体积小、脚本化方便，并提供多种 DNS 与部署钩子。选型时应比较现有目标是否已有可靠适配，而不是只看插件总数。

适合什么团队

CertD 比较适合证书数量较多、部署目标分散，或者希望把证书管理交给统一平台的团队。对国内云厂商、面板服务和 NAS 用户而言，它的插件覆盖尤其有吸引力。

几个边界也需要提前看清：

• CertD 本身是一项需要长期维护的服务，要纳入备份、升级、监控和漏洞响应。
• 项目虽然使用 AGPL-3.0，但官方 README 还列出了免费版、专业版和商业版的功能与商用限制。公司使用、修改或对外运营前，应结合许可证文本和官方商业条款做合规确认。
• 部分通知、部署目标和团队能力可能属于付费版本，不能只根据”110+ 插件”推断免费版全部可用。
• 管理系统集中保存大量高权限凭证，一旦失陷，影响可能覆盖全部域名与服务器，因此凭证最小权限和管理端隔离非常关键。

CertD 的真正价值，是把证书从”到期前想起来再处理”变成一条持续运行、能够观察和告警的流水线。它不能保证证书绝不出问题，却能显著减少手工申请、分发和遗漏带来的风险。

项目地址：github.com/certd/certd
官方文档：certd.docmirror.cn