证书管理 介绍与选型指南

目标：基于官方公开资料（各项目官方网站与 GitHub 官方仓库 Releases）梳理证书管理领域七款主流工具——certbot、acme.sh、lego、step-ca、OpenXPKI、EJBCA CE、Vault（PKI secrets engine）——的定位、版本基准、分类体系与选型口径，并按「ACME 客户端 / 私有 CA / 企业级证书生命周期」三个子域给出选型建议，协议基准线为 ACME（RFC 8555）。本文为认知类专题文档（无单一版本号，版本口径按工具分列），仅做官方资料溯源，不做本地安装与运行实测；全部版本号、日期与社区数据于 2026-10-19 联网实查。

一、信息基准

1.1 查询说明

• 查询日期：2026-10-19。
• 信息获取方式：纯官方资料溯源（各工具官方网站与 GitHub 官方仓库 Releases 页；社区数据取自 shields.io 徽章接口），本文不做本地安装与运行实测。
• 专题说明：本栏为组合专题列，标题不带单一版本号；本栏站内已有 Cert-Manager（Kubernetes 证书签发）与 Vault（凭据与密钥管理平台）部署专篇，本文定位是该领域的全景导览与选型入口。

1.2 版本依据表

补充：certbot 保持月度级发版（5.7.0 于 2026-07-21）；acme.sh 高频滚动（3.1.6 于 2026-09-20）；lego 周级高频（5.5.1 于 2026-09-17、5.5.2 于 2026-09-23）；step-ca 2026 年上半年推进 0.30.x（0.30.1 于 2026-03-19、0.30.2 于 2026-03-23）后节奏放缓；OpenXPKI 维护线与主线并行（3.32.16 于 2026-04-27、3.34.0 于 2026-07-06）；EJBCA CE 按季度推进（9.3 于 2025-12-16 → 9.6 于 2026-09-15）；Vault 处于月度级高频迭代（2.2.0 于 2026-10-15）。

1.3 官方来源清单

二、领域概述

证书管理的核心命题是「证书从签发、分发、续期到吊销的全生命周期自动化」。公网 TLS 证书因 Let's Encrypt 的普及已收敛到 ACME 协议（RFC 8555，2019-03）：客户端用 ACME 与 CA 交互完成域名验证（HTTP-01/DNS-01 等 challenge）与证书签发，90 天短有效期倒逼全自动续期。按服务对象与规模，领域可拆为三个子域：

1. ACME 客户端（公网 CA 自动化签发）：跑在 Web 服务器或任意主机上的轻量客户端，对接 Let's Encrypt/ZeroSSL 等公共 CA，自动完成验证、签发、部署与续期。代表工具为 certbot（EFF 官方推荐）、acme.sh（纯 Shell、零依赖）、lego（Go 单二进制、库形态可嵌入）。
2. 私有 CA（自建中小规模 PKI）：为内网服务、SSH、mTLS 场景自建根/中间 CA 并提供签发接口。代表工具为 step-ca（带 ACME 端点的现代私有 CA）与 Vault PKI（把证书当作一种「密钥引擎」随取随发，短证书思路）。
3. 企业级证书生命周期管理（ECLM）：面向组织级多 CA、多模板、审批流、SCEP/EST 设备发证与合规审计的平台。代表工具为 OpenXPKI（社区开源 PKI 平台）与 EJBCA CE（Java 企业 PKI 标杆，Keyfactor 商业版的上游）。

三个子域由协议与场景衔接：ACME 已从公共 CA 渗透到私有 CA（step-ca、EJBCA 均内置 ACME 服务端）；内网 mTLS 需要私有 CA；设备规模上千后需要 ECLM 平台统一管理。选型的第一步是明确「给谁发证、由谁审、有效期多长」，再在子域内挑工具。

三、工具生态分类体系

3.1 ACME 客户端

解读：三者都完整实现 RFC 8555，差异在实现形态与生态位——certbot 面向「Web 服务器开箱即用」（自动改配置）；acme.sh 面向「极简与多 CA」（默认 ZeroSSL、可切 Let's Encrypt，部署动作全靠 install-cert 挂钩）；lego 面向「工程化集成」（二进制分发、库调用、流水线友好）。三款均为活跃开源项目且无商业功能墙。

3.2 私有 CA

解读：step-ca 是「CA 即服务」的轻量路线（单二进制 + 策略文件，管理员与签发者分离，支持 ACME 客户端直连）；Vault PKI 是「平台化凭据体系」路线（证书与数据库动态凭据、KV、策略引擎同处一地，适合已用 Vault 的组织）。step-ca 为 Apache-2.0；Vault 自 2023 年起为 BUSL-1.1 许可，开源替代可关注其 MPL-2.0 分支 OpenBao（本栏另有专篇提及）。

3.3 企业级证书生命周期管理

解读：二者是「组织级平台」——OpenXPKI 的工作流（workflow）模型灵活、欧洲社区使用广泛，部署形态偏定制；EJBCA CE 的企业特性最完整（证书档案、发布器、校验器、与 HSM/目录服务集成），商业版由 Keyfactor 承接。平台类工具的选型重点从「能不能签」转为「流程、审计与集成面」。

四、关键工具与特性

4.1 certbot：EFF 官方 ACME 客户端

certbot 5.8.0（2026-09-01）以插件体系见长：--nginx/--apache 插件自动改写服务器配置并完成 HTTP-01 验证，certbot-dns-* 系列覆盖主流 DNS 服务商做 DNS-01 通配符签发；certbot renew 由定时任务驱动、续期成功后自动挂 reload 钩子（certbot.eff.org 官方文档）。Apache-2.0 许可，EFF 维护。

4.2 acme.sh：零依赖多 CA 客户端

acme.sh 3.1.6（2026-09-20）纯 Shell 实现、无运行时依赖；默认对接 ZeroSSL，--server letsencrypt 等参数可在 Let's Encrypt/ZeroSSL/Google Trust Services 等公共 CA 间切换；内置大量 DNS 服务商 API 与 --install-cert 部署挂钩，支持 ECC/RSA 双栈与 cron 自动续期（github.com/acmesh-official/acme.sh 官方 README）。GPL-3.0 许可。

4.3 lego：库形态的 Go 客户端

lego 5.5.2（2026-09-23）提供 CLI 与 Go 库双形态，100+ DNS 提供商内建于发行版；CLI 支持 run（签发）、renew（续期）、revoke（吊销）与 DNS 与 HTTP challenge 自由组合（go-acme.github.io/lego）。MIT 许可，作为库被大量 Go 项目内嵌，是流水线集成最顺手的 ACME 实现。

4.4 step-ca：现代私有 CA

step-ca 0.30.2（2026-03-23）单二进制提供完整 CA 能力：内建 ACME（RFC 8555）端点让 certbot/lego 直连私有 CA、JWK/OIDC/x509 委任等多样认证器、证书模板控制有效期与 SAN、SSH CA 一并覆盖；配套 step CLI 完成 step ca init 初始化与签发/续期（smallstep.com/docs）。Apache-2.0 许可。

4.5 OpenXPKI：工作流驱动的开源 PKI 平台

OpenXPKI 3.34.0（2026-07-06）以工作流引擎组织证书请求、审批与签发全流程，Web UI + RPC/SCEP/EST 接入端点，支持 realm（隔离域）与证书档案（profile）分层配置；官方提供社区 deb 仓库与配置向导（openxpki.org 官方文档）。Apache-2.0 许可，适合需要定制审批流的组织。

4.6 EJBCA CE：企业 PKI 标杆

EJBCA CE 9.6（2026-09-15）运行于 WildFly（Jakarta EE）环境，功能面覆盖多 CA 层级、证书档案与终端实体档案、RA Web 与 CLI、REST API、SCEP/EST/ACME 服务端、与 HSM 及目录服务集成（docs.keyfactor.com/ejbca）。LGPL-2.1 许可，商业版由 Keyfactor 提供支持；是国产与海外企业建 PKI 时最常见的开源底座。

4.7 Vault PKI：平台化短证书签发

Vault 2.2.0（2026-10-15）的 PKI secrets engine 以「短证书 + 按需签发」为设计哲学：启用 pki 引擎后创建根/中间 CA、配置角色（role）约束域名与有效期，随后通过 CLI/API 的 pki/issue 即时取证；续期靠应用侧高频重签而非文件轮换（developer.hashicorp.com/vault 官方文档）。BUSL-1.1 许可；证书吊销与 CRL/OCSP 能力内建。本栏站内另有 Vault 平台部署专篇。

五、快速上手

以下示例均转述自各工具官方文档/README（正文标注来源），本文不做本地实测。

5.1 certbot（certbot.eff.org 官方用法）

certbot certonly --standalone -d example.com          # 独立模式 HTTP-01 签发
certbot certonly --nginx -d example.com               # Nginx 插件自动配置
certbot renew                                         # 定时任务驱动批量续期

5.2 acme.sh（官方 README）

acme.sh --issue -d example.com --webroot /var/www/html        # webroot 验证签发
acme.sh --issue -d '*.example.com' --dns dns_cf              # DNS API 通配符
acme.sh --install-cert -d example.com --reloadcmd "nginx -s reload"  # 部署+重载挂钩

5.3 lego（官方文档）

lego --email you@example.com --dns cloudflare -d example.com run    # DNS challenge 签发
lego --email you@example.com --http --domains example.com renew --days 30

5.4 step-ca（smallstep 官方文档）

step ca init                          # 交互式初始化私有 CA
step ca certificate internal.local internal.crt internal.key --ca-url https://ca.internal --root root_ca.crt
step ca renew internal.crt internal.key --force    # 续期

5.5 Vault PKI（developer.hashicorp.com 官方教程转述）

vault secrets enable pki
vault write pki/root/generate/internal common_name=example.internal ttl=87600h
vault write pki/roles/webserver allowed_domains=example.internal max_ttl=72h
vault write pki/issue/webserver common_name=svc.example.internal ttl=24h

5.6 OpenXPKI 与 EJBCA（官方部署文档转述）

OpenXPKI 按官方文档（openxpki.org）经社区 deb 仓库安装后，核心动作是规划 realm 与证书档案、配置工作流，随后经 Web UI 或 SCEP/EST 端点接入请求方。EJBCA CE 按官方部署指南（docs.keyfactor.com）在 WildFly 上部署后，先经管理员 Web UI 建 CA 与证书档案，再以 RA Web/REST/SCEP/ACME 等接口接入发证。

本栏站内相关部署专篇：《Cert-Manager Kubernetes 证书签发与管理详解》、《Vault 凭据与加密密钥管理平台部署详解》。

六、适用场景与限制

6.1 各子域适用场景

• 公网网站 TLS 证书：certbot（Web 服务器自动配置）或 acme.sh（极简、多 CA）；通配符证书走 DNS-01。
• 流水线/程序化签发：lego（Go 库嵌入）或 acme.sh 脚本挂钩；CI 中用 lego 二进制最省事。
• 内网 mTLS/SSH 证书：step-ca（自带 ACME 端点 + SSH CA）；已用 Vault 的组织直接用 Vault PKI 与现有策略引擎整合。
• 组织级 PKI 平台：EJBCA CE（功能最全、Java 生态、商业支持可达）或 OpenXPKI（工作流灵活、Perl 栈）；设备类（路由器/IoT）接入看 SCEP/EST 支持面。
• Kubernetes 环境：cert-manager 自动签发（本栏站内专篇），可对接 ACME 与私有 CA（Vault/step-ca/EJBCA 均有 issuer 集成）。

6.2 限制与注意事项

• ACME 公共 CA 证书有效期 90 天内：续期自动化必须先于上线完成，监控覆盖到期时间，避免「签了没人续」。
• DNS-01 需要授权 DNS 服务商 API；ACME 客户端保存的 API 凭据与账户私钥按敏感数据管理。
• 私有 CA 的根私钥必须离线或 HSM 保护；中间 CA 在线签发时严格控制 API 认证与审计日志。
• Vault 为 BUSL-1.1 许可，随平台再分发需核对条款；开源替代可评估 OpenBao（MPL-2.0）。
• EJBCA/OpenXPKI 属重平台：需要 Java/Perl 栈运维能力与数据库、HSM 等配套，小团队评估运维成本后再上。
• 私有 CA 与公共 CA 的信任域不可混用：内网域名签公共证书会失败（CA/B 论坛约束），选型时按信任域分清边界。
• ACME 客户端三选一即可，多客户端并行会增加状态机与续期窗口的排障面。

七、同类选型对比

7.1 量化对比总表（2026-10-19 实查，按子域分组）

（stars 与贡献者数取自 shields.io 徽章接口、发布时间取自各项目 GitHub Releases 页与 RFC 8555 发布记录，2026-10-19 实查。）

7.2 兼容矩阵（按子域）

7.3 如何选

先分信任域，再按规模选型：公网证书无脑走 ACME 客户端——Web 服务器场景选 certbot、追求极简与多 CA 选 acme.sh、流水线与程序化选 lego；内网 mTLS 与 SSH 场景用 step-ca（轻量现代）或 Vault PKI（已用 Vault 则零边际成本，注意 BUSL 条款）；组织级多团队、设备批量接入与审计合规需求，上 EJBCA CE（功能最全、商业支持可达）或 OpenXPKI（工作流定制灵活）。Kubernetes 场景由 cert-manager 统一issuer，上游可接 ACME、step-ca、Vault 或 EJBCA。实践中常见组合是 certbot/acme.sh（公网站点）+ step-ca 或 Vault PKI（内网与集群）+ EJBCA CE（组织级 CA 中枢），三者覆盖的规模层级互不重叠。

八、参考链接

• ACME 协议 RFC 8555：https://www.rfc-editor.org/rfc/rfc8555
• Let's Encrypt 官网：https://letsencrypt.org/
• certbot 官方站：https://certbot.eff.org/
• certbot 仓库：https://github.com/certbot/certbot
• acme.sh 仓库与官网：https://github.com/acmesh-official/acme.sh / https://acme.sh/
• lego 官方文档与仓库：https://go-acme.github.io/lego/ / https://github.com/go-acme/lego
• step-ca 官方文档与仓库：https://smallstep.com/docs/step-ca/ / https://github.com/smallstep/certificates
• OpenXPKI 官网与仓库：https://www.openxpki.org/ / https://github.com/openxpki/openxpki
• EJBCA 官网与 CE 仓库：https://www.ejbca.org/ / https://github.com/Keyfactor/ejbca-ce
• EJBCA 官方文档：https://docs.keyfactor.com/ejbca
• Vault PKI 官方文档：https://developer.hashicorp.com/vault/docs/secrets/pki
• Vault 仓库：https://github.com/hashicorp/vault