NGINX 推出对 ACME 协议的原生支持
我们非常高兴地宣布 NGINX 对 ACME 的支持 的预览版本发布。该实现引入了一个新的模块 ngx_http_acme_module，该模块提供了内置指令，可直接从 NGINX 配置中请求、安装和续订证书。ACME 支持基于我们的 NGINX-Rust SDK 实现，并以 Rust 语言开发的动态模块形式提供，适用于 NGINX 开源用户以及使用 NGINX Plus 的企业版 NGINX One 客户。
NGINX 对 ACME 的原生支持带来了多种好处，简化并提升了整体 SSL/TLS 证书管理流程。通过 直接使用 NGINX 指令配置 ACME，可以大幅减少手动错误并消除传统上与管理 SSL/TLS 证书相关的持续开销。它还减少了对外部工具如 Certbot 的依赖，创建了一个更安全、更流畅的工作流程，具有更少的漏洞和更小的攻击面。此外，与现有外部工具可能存在的平台特定限制不同，原生实现确保了更大的可移植性和平台独立性，使其成为现代、不断发展的网络基础设施的灵活可靠的解决方案。
什么是 ACME？
ACME 协议(自动化证书管理环境)是一种通信协议，主要用于自动化数字安全证书(如 SSL/TLS 证书)的签发、验证、续期和撤销过程。它允许客户端在无需人工干预的情况下与证书颁发机构(CA)进行交互，从而简化了部署安全网站及其他依赖HTTPS服务的流程。
ACME协议最初由互联网安全研究组(ISRG)作为Let’s Encrypt计划的一部分于2015年底开发，旨在提供免费、自动化的SSL/TLS证书。在 ACME 出现之前，获取 TLS 证书通常是一个手动、昂贵且容易出错的过程。ACME 通过提供开源、自动化的证书管理工作流程，彻底改变了这一状况。
ACMEv2 是原始 ACME 协议的更新版本。它新增了对新挑战的支持、扩展了认证方法、支持通配符证书以及其他增强功能，以提升灵活性和安全性。
NGINX ACME 工作流
NGINX 中的 ACME 工作流可分为 4 个步骤：
- 配置 ACME 服务器
- 分配共享内存
- 配置挑战
- 证书签发与续期
配置 ACME 服务器
要启用 ACME 功能，第一步(也是唯一必填步骤)是指定 ACME 服务器的目录 URL。
此外，还可以提供有关在证书相关问题时如何联系客户端或模块数据存储位置的额外信息，如示例所示。
acme_issuer letsencrypt {
uri https://acme-v02.api.letsencrypt.org/directory;
# contact admin@example.test;
state_path /var/cache/nginx/acme-letsencrypt;
accept_terms_of_service;
}
分配共享内存
该实现还提供了一个可选指令 acme_shared_zone，用于存储所有配置的证书颁发机构的证书、私钥和挑战数据。该区域的默认大小为 256K，可根据需要增加。
acme_shared_zone zone=acme_shared:1M;
配置挑战
当前预览实现支持HTTP-01挑战以验证客户端的域名所有权。这需要在Nginx配置中定义一个监听器，用于处理ACME HTTP-01挑战：
server {
# 监听器端口80用于处理ACME HTTP-01挑战
listen 80;
location / {
# 在监听挑战时返回基本 404 响应
return 404;
}
}
对其他挑战(TLS-ALPN、DNS-01)的支持计划在 未来 实现。
证书签发与续期
在 NGINX 配置文件的相应服务器块中使用 acme_certificate 指令，可实现 TLS 证书的自动签发/续期。该指令需要指定需要动态签发证书的标识符(域名)列表。标识符列表可通过 server_name 指令进行定义。
下面的代码片段演示了如何配置服务器块，使用之前定义的 letsencrypt ACME 证书颁发机构为 “.example.domain” 域名签发/续期 SSL 证书。
服务器 {
监听 443 端口并启用 SSL；
服务器名称为 .example.com；
使用 Let's Encrypt 证书；
SSL 证书文件为 $acme_certificate；
SSL 证书密钥文件为 $acme_certificate_key；
SSL 证书缓存最大值为 2；
}
请注意，[server_name](https://nginx.org/en/docs/http/server_names.html) 指令接受的并非所有值都是有效的标识符。当前实现不支持通配符。正则表达式也不被支持。
在模块中使用 $acme_certificate 和 $acme_certificate_key 变量传递与域名关联的 SSL 证书和密钥信息。
为什么这一切都重要？
全球范围内 HTTPS 的快速普及主要得益于 ACME 协议，使得安全网页连接成为标准期望。ACME 通过自动化整个流程，消除了手动操作并降低了证书生命周期管理相关的成本，从而现代化了 TLS/SSL 证书的签发、续期和管理方式。除了网页之外，物联网设备和边缘计算的增长使 ACME 能够在自动化 API、设备和边缘计算基础设施的安全性方面发挥关键作用。
NGINX对ACME的原生支持凸显了该协议在未来网络安全、自动化和可扩展性方面的关键地位。预计ACME将在可预见的未来继续成为互联网及更广泛领域证书自动化的核心支柱。随着安全成为网络标准的基本要求，我们将持续看到对部署模型和安全需求演进的诉求，这将推动ACME的进一步优化。
展望未来，我们致力于不断完善我们的实现方案，以满足用户和客户的需求，既满足他们当前的需求，也为他们未来的发展方向构建能力。
如何开始
立即使用 NGINX 中的原生 ACME 实现开始使用。开始使用。如果您是开源用户，预构建包可在此获取此处。如果您是使用NGINX Plus的企业级NGINX One客户，预编译包可作为F5支持的动态模块获取。有关该模块的更多信息，请参阅NGINX 文档。
社区反馈
一如既往，您的反馈对塑造 NGINX 的未来发展至关重要。如果您有建议、遇到问题或希望请求新增功能，请通过 GitHub Issues 提交。我们迫不及待地期待您尝试使用。
> 当前的预览实现支持使用HTTP-01挑战来验证客户端的域名所有权。
DNS-01 可能是对非公开部署的 Nginx 用户(例如通过 Nginx Proxy Manager)影响最大的方案。我真的很希望 DNS-01 能尽快落地！我一直觉得它也是最简洁的方案，因为它只需更新一些记录，无需直接与所托管的内容绑定。
DNS-01 的问题在于每次只能使用一个委托。我的意思是，如果你在 Google 中配置了一个通配符证书，使用 _acme-challenge.example.com，你就不能在 Cloudflare 中使用它，因为它使用了一个单一的 DNS 授权标签(子域名)。
该解决方案在过去几年中不断演进，目前最新的 IETF 草案是 https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account…
新提案引入了dns-account-01挑战，将ACME账户URL整合到DNS验证记录名称中。
无需等待：https://en.angie.software/angie/docs/configuration/modules/h…
(Angie 是由原 Nginx 开发者离开 F5 后主导的 Nginx 分支)
Angie 和 freenginX.org 之间的主要区别是什么？
但您必须加载 DNS API 密钥，而许多 DNS 提供商不允许按区域设置 API 密钥。我喜欢它，但妥协可能会很糟糕。
你可以将 _acme-challenge.domain.tld 的 NS 记录指向你控制的另一台服务器，这样你就无需通过 DNS 托管商更新区域。该服务器只需能够解析查询挑战的请求。
如何操作？
CNAME记录。我对所有情况都采用此方法。示例：
2. 您在专用账户中使用DNS API的临时域名是example.net，由提供商B管理，且在ACME客户端中拥有DNS API令牌。
3. 您创建_acme-challenge.important.example.com，但不通过API以TXT记录形式创建，而是以永久CNAME记录形式指向_acme-challenge.example.net或_acme-challenge.important.example.com.example.net。
acme.sh 支持此功能(参见 https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo…)，此方法也适用于通配符，如该文档所述，大多数 ACME 客户端均支持。
我还编写了一个支持此功能的 acme.sh Ansible 角色：https://github.com/foundata/ansible-collection-acmesh/tree/m…。示例值：
这让我大开眼界。自Cloudflare顽固地拒绝允许非企业账户为每个区域设置独立密钥以来，这一直是令人沮丧的根源。请求该功能的帖子堪称被动攻击的典范：
https://community.cloudflare.com/t/restrict-scope-api-tokens…
在设置API密钥时，请使用“选择要包含或排除的区域”部分。免费账户上使用正常。
我应该澄清一下，非企业账户无法对子域名进行设置。
你能详细说明每个区域单独使用密钥的问题吗？可以创建仅访问特定区域的不同 API 密钥，而我是非企业用户。
这允许你限制到一个域名(例如example.com)，但不包括该域名的子域名。
啊，我明白了，感谢你的澄清！
感谢你清晰的解释。
我使用了 acme-dns 服务器(https://github.com/joohoi/acme-dns)来实现这一点。它基本上是一个基于SQLite的迷你DNS服务器，配备了非常基础的API。我所有的acme.sh实例都通过它发布TXT记录，并接受来自互联网对这些TXT记录的查询。
存在一个NS记录，使得*.acme-dns.example.com将请求转发至该服务器。因此，每个需要证书的主机都拥有一个公共CNAME记录，例如_acme-challenge.http://www.example.com，其CNAME指向asdfasf.acme-dns.example.com，该记录又回指至acme-dns服务器。
在设置新主机名/证书时，会向 acme-dns 发送一个 REST 请求以注册新用户名/密码/子域名，这些信息会被传递给 acme.sh。每次 acme.sh 需要签发/续签证书时，它都会将 TXT 信息发送给内部的 acme-dns 服务器，该服务器随后将其公开给互联网。
通常只需进行 CNAME 设置。
您可以将 _acme-challenge.foo.com CNAME 到 foo.bar.com。
现在，当您进行 DNS 挑战时，在 foo.bar.com 上创建包含挑战响应的 TXT 记录，通过 CNAME 重定向，该 TXT 记录会被视为直接位于 _acme-challenge.foo.com 上。现在你可以为 foo.com 的任何内容签发通配符证书。
我计划今年晚些时候构建一个自动化解决方案，以处理数百个独立域名的此类需求，并将生成的证书存储在 AWS 密钥管理器中。
我还将尝试构建一个 ACME 代理，以便内部客户端向我进行身份验证，但他们无法控制 DNS，因此我将代表他们发起请求。我们需要为 ACME 的全面部署做好准备。2026 年 5 月起，证书有效期将缩短至 200 天，此后只会进一步缩短。
在我的场景中，我有一个非常小的名称服务器 ns.example.com。因此，我将 _acme-challenge.example.com 的 NS 记录设置为 ns.example.com。
对 ns.example.com 的 A 记录查询解析为我的服务器 IP 地址。
该服务器监听 53 端口。这是一个使用 `dnslib` 的自定义小型 Python 服务器，同时监听 8053 端口以接收 HTTPS 连接。
在 certbot 中，我有一个自定义处理程序，当它收到域验证挑战时，会通过 HTTPS 将挑战信息发送至 ns.example.com:8053/certbot/cache。该小型 DNS 服务器随后存储该信息，并等待 53 端口上的 DNS 查询请求该挑战，若收到请求，则返回该挑战的 TXT 记录。
Certbot 钩子代码如下
该名称服务器实例和钩子可用于任何域名和证书，因此不仅限于 example.com 域名，还可处理如 *.testing.other-example.com 通配符证书的验证挑战。
由于它本身就是一个名称服务器，如果已将 testing.other-example.com 的 NS 记录设置为 ns.example.com，它也可以提供 dev1.testing.other-example.com 的 A 记录。
https://cert-manager.io/docs/configuration/acme/dns01/#deleg…
是时候让 DNS 提供商开始支持 TSIG + 密钥管理了。这是操作 DNS 记录的标准化方式，并且具有非常细粒度的访问控制列表 (ACL)。
我们不需要数百个自定义 API。
https://en.m.wikipedia.org/wiki/TSIG
整个重点是将这些细节从用户视图中抽象出来，让他们不知道这其实是一个巨大的平面文件。以每行$29.99的价格出售。(我开玩笑的，显然)
Digital Ocean DNS是免费的(这是我拥有该账户的唯一原因)
听起来像是 DNS 提供商的问题。为什么 Nginx 需要因为某个第三方实现细节而妥协？
因为用户会选择满足他们需求的替代方案，当他们没有能力或权限更改 DNS 提供商时。必须在用户有选择时满足他们的需求。
虽然有点麻烦，但实际上你可以自己发布DNS记录。不过显然他们正在退出市场，因为我认为证书有效期只有30天左右。
我将此用于家中的Jellyfin服务器，这样任何人都可以直接输入blah.foo，无论其设备是否支持mDNS，因为一半的设备声称支持但实际上并不正确。
我的公司DNS提供商甚至没有API，所以我将域名委托给一个子域名，将其托管在PowerDNS上，并使用Lego自动化ACME流程。
每个区域拥有一个密钥是否值得付费？这在我为PTRDNS计划实现的功能列表中，因为它符合我的使用场景，但我不知道是否有足够的兴趣让它跃居列表顶部。
一般说明：你的 DNS 提供商可以与你的注册商不同，尽管大多数注册商也是提供商，你也可以成为自己的 DNS 提供商。注册商是负责将域名置于你控制之下的一方，而提供商是负责托管包含你 DNS 记录的名称服务器的一方。
是的，你可以仅在挑战方面成为自己的 DNS 提供商，其他部分可以继续使用原有的 DNS 提供商。
不需要，您只需在任何地方运行 https://github.com/joohoi/acme-dns，然后将 _acme_challenge 设置为 CNAME 记录。将realdomain.com解析到aklsfdld239072109387219038712.acme-dns.anywhere.com。然后你的ACME客户端只需与ACME DNS API通信，除了处理该长随机域名的挑战外，它无需执行任何其他操作。
您可以通过 NS 记录实现，即 _acme_challenge.realdomain.com 指向可编程提供挑战响应的 DNS 服务器。无需创建 CNAME 记录或引入中间域名。
是的，但同样可以使用 http-01 协议，且所需 effort 相当。
不，因为 DNS 支持通配符证书，而 HTTP 不支持。
DNS-01 对于私有网络上的服务也很好用。
啊，好点子。
还有一个SaaS版本，如果你不想自己托管的话。
https://docs.certifytheweb.com/docs/dns/providers/certifydns…
我已经希望在Traefik上实现ACME挑战委托功能多年了。文档中说它支持该功能，但每次尝试都失败。
如果你对这个工具在Docker Swarm集群上的工作原理有任何想法，我很乐意听取。
如果你自己托管一个隐藏的主服务器，就可以轻松实现。
许多 DNS 提供商也不支持使用外部主服务器。
Hurricane Electric 作为其免费 DNS 名称服务器服务的一部分支持隐藏主服务器(你真的想暴露你的主服务器，而让其他人处理流量吗？)
https://dns.he.net
没错，但初始化时有点麻烦，因为他们要求你已经将域名委托给他们，但某些顶级域名要求所有名称服务器在委托前必须同步并能响应该域名……
大多数域名允许添加NS记录吗？
如果不允许，你可以考虑切换到Cloudflare进行DNS托管。
试试 DNSMadeEasy 或 RcodeZero
这让我非常担心，所以我使用 AWS Route53 进行 DNS 托管，并使用一个 IAM 策略，仅允许密钥从特定 IP 地址访问，且仅限于创建和删除特定记录集的 TXT 记录。我喜欢能够精确创建所需权限的感觉。
AWS IAM 虽然可能令人头疼，但也能解决许多问题。
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p…
https://repost.aws/questions/QU-HJgT3V0TzSlizZ7rVT4mQ/how-do…
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/sp…
即使PowerDNS也不支持它 🙁
对于API而言确实如此，但你可以进行DynDNS更新(RFC 2136)，并以TSIG认证方式按区域进行控制。[1]
甚至可以通过基于 Lua 的更新策略进行精细控制，例如仅限制为 ACME TXT 记录。[2]
[1] https://doc.powerdns.com/authoritative/dnsupdate.html
[2] https://github.com/PowerDNS/pdns/wiki/Lua-Examples-(Authorit…
Traefik 在使用 ACME 时的一个缺点是，每个 DNS 提供商只能使用一个 API 密钥。如果想要将 API 密钥限制在某个域名下，或者使用属于两个不同账户的域名，这就会成为问题。我希望 Nginx 不会有同样的限制。
这是Caddy停止使用Lego作为ACME验证服务的主要原因之一，因此我们自行开发了ACME验证堆栈。
您可以使用 CNAME 来处理多个 DNS 挑战提供商。https://doc.traefik.io/traefik/reference/install-configurati…
我在家庭实验室中使用 dns01 配合 step-ca 和 Caddy。使用起来非常愉快
+1 支持 Caddy。Nginx 已经过时了。
Caddy 主要面向希望发布/测试自己编写代码的开发者。对于高级用户或基础设施管理员，Nginx 仍具有更高价值。虽然我在家庭实验室中使用 Caddy 且体验不错，但其灵活性远不及 Nginx。
Caddy 正在生产环境中使用，每小时处理 1400 万次请求。
如果可以的话，能告诉我具体在哪里吗？
相信我，你不想知道。只需知道——它运行得非常出色，感谢你。GovCloud 真是个麻烦。
我们在生产环境中使用 Caddy 支持数百个应用程序，每天处理数千万次请求。
哦。你能告诉我更多关于这个吗？
当然。大学/政府部门。我知道该领域有不少大学/项目切换到 Caddy，因为巨大的 IP 范围和深度子域，涉及不同类别的利益相关者，需要特定的 PKI 要求，而 Caddy 使使用 ACME 变得简单。我们部署了一个自助工具，用户可以为自己拥有的子域生成EAB-ID和HMAC密钥。
复杂的根域路由和动态重写逻辑由Apache/Nginx/HaProxy处理，许多应用程序通过容器架构部署，使用Caddy实现证书自动续期，无需依赖复杂的Certbot架构。因此，我们并不依赖单个实例处理大量流量。此外，我们的大部分流量来自机器人。比人们想象的要多。
基本配置非常简洁，这使其成为开发运维能力参差不齐的团队的理想选择。作为开发运维工程师，我喜欢与 Tailscale 的轻松集成。
感谢您，这是非常有价值的反馈/信息。是的，我们也认为 Tailscale 集成非常棒！
如果有人好奇，这是 Caddy 的作者。
他想知道它在家庭实验室和小型商店之外的其他地方是如何被使用的。Matt，这是款出色的软件，随着 Go 语言的进步，它只会变得更好。
我曾将其用于跨多个云的 Kubernetes 入站代理设置——用于政府项目(前任管理员，现任管理员取消了该项目)。我无法透露更多细节。除了它的工作流程是：WWW -> ALB -> Caddy 集群 * 其他云 -> K8s 路由器 -> K8s pod -> Fiber Golang 服务。:chefs kiss:
当 pod 注册到 K8s 路由器时，我们会向 Caddy 集群发送请求以注册路由。咔嚓，我们有了流量，有了 TLS，有了魔法。没有停机时间。
我差点忘了。Matt。我们在 Caddy 群集上添加了一点糖。Hashicorp 的 memberlist。这样我们可以同步记录。效果很好。遗憾的是，我无法分享它，但实现起来相当简单。
精彩的信息和反馈——非常感谢。很高兴它对你有用！
那么，一个工具的价值是否应与其年龄成反比？
工具的价值因人而异。当 Nginx 决定更改许可证、转为私有股权、不适应编排需求、忽视 HTTP 标准，并在十年内未发布有意义的更新时，它对我来说就不再有价值了。
> 当他们决定更改许可证时，
https://github.com/nginx/nginx/blob/master/LICENSE 看起来像是一个不错的宽松许可协议。我不在乎是否有付费版本，只要我想要的所有功能都在开源版本中。
私募股权？要么是我漏掉了什么故事，要么是你误解了F5的私募股权性质。
查查Angie、freenginx以及整个Rambler/F5丑闻。莫斯科联邦机构涉入并强迫利用以谋取利润。
也许与生态系统围绕它的活动程度成反比。
只有当他们将K8s入口从WIP阶段移出时；我迫不及待地想摆脱其他系统中出现的证书管理器和入口的麻烦。
没错。我迫不及待地想有一天能关闭我的caddy8s服务。
Caddy 最棒的地方在于，你可以重新加载配置、添加站点和路由，而无需关闭服务。编写一个服务来保持你的编排平台和入口同步是件麻烦事。K8s 有事件，DNS 服务有 src mesh 记录，你只需要一种方式告诉 Caddy 将它们发送到你的后端。
该功能很快就会完成，但他们需要确保它在所有 K8s 版本中都能正常工作。
只需向 Nginx 发送 sighup 信号，它就会重新加载所有配置——几乎不需要重启的设置非常少
当然可以，从容器中操作吗？还是从它所在的主机？Caddy 通过 API 暴露了这一功能。
我认为 Nginx 也可以做到，但 SWAG 包装器出于某种原因不鼓励这样做
Traefik 对我们来说似乎没问题
DNS-01 的实际问题是，每个 DNS 提供商创建所需 TXT 记录的 API 都不同。Certbot为不同提供商提供了十多个插件，且列表仍在增长。Nginx不应承担跟踪所有这些第三方API的责任。
要求所有人将域名迁移到AWS和Cloudflare等少数几家巨头(它们已掌控互联网的大部分资源)以获取DNS-01证书，这也不合理。我更倾向于让DNS保持一定程度的去中心化。
这是事实，而且令人烦恼。他们本应直接支持 RFC 2136 标准，而非自行开发 API。Lego 支持该标准，且几乎所有 DNS 服务器均已实现。至少我可以使用自己的 DNS 服务器……
https://datatracker.ietf.org/doc/html/rfc2136
这是一个非常好的观点。
我好奇解决这个问题的好方法是什么？理论上，Nginx可以调用另一个处理与DNS提供商通信的应用程序，这样用户可以根据自己的需求进行定制。(用户可以使用Python、Go或其他语言编写。)不过我不确定这种方案的健壮性如何。
是的，请使用ACME-DNS – https://github.com/joohoi/acme-dns
Lego支持该功能。
切换到Angie吧。它对DNS-01的支持非常出色。
NGINX在其中扮演什么角色呢？
我在VPS上使用一个Bash脚本获取通配符证书，然后通过SCP将证书传输到其他反向代理服务器。其中部分使用NGINX，部分使用Caddy或Traefik
撰写了一篇关于如何设置的文章 https://blog.haschek.at/2023/letsencrypt-wildcard-cert.html
我甚至不明白为什么有人会不使用DNS验证，除非他们别无选择。我发现它既烦人又脆弱，也许现在有了原生Web服务器支持会好一些。而且你无法获得通配符证书。
我的工作主要是运行无法从外部互联网访问的内部服务。DNS是唯一的选择。
你可以通过DNS获得通配符。如果你想要*.foo.com，你只需要能够设置_acme-challenge.foo.com，就可以获得通配符。
Spivak认为DNS方法更优(即你同意——我也同意)。
我能想到的HTTP-01/TLS-ALPN-01的一个原因是按需签发，即在收到请求时签发证书。这可能看起来很疯狂(确实有点疯狂)，但对于某些疯狂的网页迁移项目来说可能很有用。如果你有一个庞大、层次深、几乎从未使用的域名结构，但出于某种原因需要它在线，这将非常方便。
(另一个原因，很快就会实现，是HTTP-01将能够为IP地址签发证书：https://letsencrypt.org/2025/07/01/issuing-our-first-ip-addr…)
哦，我完全误读了这条评论。
算了，我同意！
这条评论的措辞很奇怪，我也得读了几遍才明白他们的意思。
> DNS 是唯一的选择
DNS 和通配符并不是唯一的选择。我曾通过一些烦人的技巧为内部服务获取 HTTPS 证书，而无需使用上述方法。
但它们是唯一合理的选项。
通配符的一个问题是，任何使用 *.foo.com 的服务都可以冒充其他服务。如果使用双向 TLS 认证并希望信任服务器的证书，这将是一个问题。
如果LE能够签发受特定域名约束的中间证书(https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1….)，那将非常理想。
HTTP验证的优势在于其简单性。无需处理DNS或API密钥。只需启动服务器软件并告知其主机名，其余操作将自动在后台完成。
若该域名由两台或更多服务器提供服务，则无法实现
这与 DNS 的区别具体在哪里？无论采用哪种方法，密钥和生成的证书仍需在服务器之间进行分发。
使用 dns-01 时，多个服务器可以独立地为同一组主机名获取证书。不过不确定这是否是个好主意。
其实不是，只需将 .well-known/acme-challenge/* 请求转发到单一服务器，或确保所有实例均能提供挑战响应。
如果你通过低端域名代理商购买域名且未支付优质 DNS 服务费用，你就没有其他选择。
此外，设置API密钥需要时间，而且大多数情况下你根本不需要通配符。
你不需要访问DNS的API权限，只需能够将ACME挑战记录委托给自己的服务器即可。
我不知道如何让我的服务器登录到我的DNS，而且我也不特别想学习如何做。映射.well-known只需一行配置。
通配符是唯一的诱惑。
就像你可以将.well-known/acme-challenge/指向一个可写目录一样，你也可以将相关的DNS密钥委托给一个你可以更轻松更新的名称服务器。
现在你让我租用或安装至少两个名称服务器，然后配置它们，然后教我的Web服务器如何向它们发送规则？
这比我第一个评论中的任何一个选项都要麻烦得多。别名一个目录大约需要一分钟。
> 我发现这很烦人且不稳定
为什么？它只是在提供静态文件。
DNS-01是否支持通过HTTPS向已注册的域名服务器发送DNS请求？如果支持，那么扩展Nginx以支持DNS声明应非常简单；如果不支持，或许DNS-01需要改进。
下单时，你会从ACME提供商获得一个奇怪的文本字符串。你需要创建一个包含此值的TXT记录。_如何_创建TXT记录取决于你和你的DNS服务器——ACME提供商并不关心。
我认为 DNS-over-HTTPS 在此情境下不相关。据我所知，它用于客户端查询 DNS 服务器，而非用于运营商创建 DNS 记录。(如有错误请指正。)
ACME 提供商向 DNS 服务器发起查询以验证记录存在且包含正确的“特殊字符串”。父问题的核心是该查询是否可通过 DoH 方式进行。
或许我缺乏想象力，但我不明白这为何重要？
因为 Nginx 作为 HTTP 服务器，可以响应该查询？
你打算在 Nginx 中集成 DNS 服务器，以便能够响应托管在该 Nginx 服务器上的域名的 DoH 查询？
让我们忽略 DoH 是一个客户端导向的协议，且无法仅运行 DoH 服务器而无需底层 DNS 服务器的事实。您计划如何获取第一个证书，以确保对 DoH 服务器的查询不会因证书无效而被拒绝？
到那时，您不妨使用 HTTP-01 挑战。我认为 DNS-01 的整个用途在于，如果您不想将 HTTP 服务器暴露在互联网上，就可以使用它。
不，这只是其中一个用例。此外：
– 通配符证书。在此场景下，DNS-01是严格要求。- 针对由多个服务器(如负载均衡器)终止TLS连接的服务的证书。在此场景下，DNS-01是实际要求，因为在HTTP或ALPN挑战过程中，仅有一台终止服务器能够响应。
> DNS-01 在这里是一个实际要求，因为在 HTTP 或 ALPN 挑战期间，只有其中一个终止服务器能够响应。
将 .well-known/acme-challenge/ 的请求反向代理或转发到单个服务器应该与 DNS-01 一样容易设置。
但随后您需要将证书从该单一服务器重新分发到所有其他服务器。虽然这可以实现，但您必须自行编写该胶水代码。更重要的是，您现在选择了一台特殊的服务器，证书续期依赖于它。
换句话说，不，这并不像设置 DNS-01 那样简单。不同的操作特性，以及对定制胶水代码的需求。
> 但随后你必须将证书从该单一服务器重新分发到所有其他服务器。
难道你不需要这样做吗？还是说每个服务器都应该为自己请求并续期一个单独的证书？这听起来似乎在DNS-01挑战过程中，如果出现两个或更多服务器同时想要续期证书的情况，就需要注意避免服务器之间相互干扰。
没错。有一个RFC草稿专门解决了这个难题。
https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account…
据我所知，这仅在尝试将负载分配给多个客户端时才会成为问题。但根据我的经验，与多个客户端的常规操作完全正常(进行多区域负载均衡)。我认为会创建多个TXT记录(这是我随口说的)。
啊！我收回刚才的话。
我想要快速核对一下我(尽管有限)的经验与文档是否一致。RFC[0]暗示了这种可能性(前提是使用一个行为良好的ACME客户端，不会覆盖其他TXT记录)：
而 certbot 文档[2] 展示了它作为一个行为良好的客户端，不会覆盖来自并发实例的 TXT 记录：
> 同一名称下可以存在多个 TXT 记录。例如，当同时验证通配符证书和非通配符证书的挑战时可能会出现这种情况。然而，您应确保清理旧的 TXT 记录，因为如果响应大小过大，Let’s Encrypt 将开始拒绝它。 > … > 即使有多个 Web 服务器，它也能正常工作。
关于“多个 Web 服务器”的表述稍显模糊，但前文已明确说明了整个流程的运作方式。
[0] https://datatracker.ietf.org/doc/html/rfc8555#section-8.4
[1] https://letsencrypt.org/docs/challenge-types/#dns-01-challen…
啊，这样就说得通了。谢谢！
为什么 Nginx 需要支持 DNS-01 挑战类型？因为 Nginx 在整个进程生命周期中始终运行着一个 HTTP 服务器，因此它始终可以访问
.well-known，所以你永远不需要使用更低级别的 DV 验证方式。而且这似乎违反了最小权限原则，因为现在你需要在服务器上使用一个敏感的 API 令牌。因为虽然 Nginx 始终可以访问 .well-known，但验证方可能无法访问。我使用 DNS 挑战来为解析到我覆盖网络中 IP 的域名签发证书。
问题是，支持 DNS-01 只是支持 DNS-01，它提供了一个与实现 DNS-01 的不同提供商交互的通用接口。
dns-01 只是一个挑战；那么 Nginx 应该支持哪个 API 或 DNS 更新系统？是某个 API、AFXR 还是 UPDATE？
我认为这正是 OP 的观点，Nginx 是一个 HTTP 服务器，为什么它要涉及 DNS？已经有许多其他 ACME 客户端可以轻松完成这项任务
我的意思是，你只是重复了我之前解释的为什么在 Nginx 中支持 DNS-01 并不像 HTTP-01 那样直截了当。我已经解释过为什么 DNS-01 挑战仍然有用，并且可能对某些用户是必要的。
我误读了你的第一段，更多是在回应第二段，我认为那是支持在回复 OP 时添加 DNS 实现的。
它可能仍对部分用户必要，但我认为这对 Nginx 来说没有意义
如果运行 Nginx 的服务器无法从互联网访问，就无法使用 HTTP-01。DNS-01 适用于这种情况。
通配符证书可能是最重要的答案：它们无法通过 HTTP 挑战获取。
因为你可能有多个服务器在为这个域名提供服务
使用 HTTP 挑战颁发新证书基本上需要允许 15 分钟的停机时间。这真的不适合任何有 SLA 的客户 facing 端点。
听起来你操作有误。我不确定原生支持的情况，但如果它比旧方法更差，我会非常惊讶。旧方法只需让 Certbot 将文件放置在 NGINX 已经服务的目录(webroot 方法)中，然后在新证书生成后触发 NGINX 重新加载配置。这样应该不会有任何停机时间。
Certbot有一个“独立模式”，它占用80端口并自行提供/.well-known/服务。
任何在非紧急情况下推荐使用该模式的人都应该被狠狠踢一脚。
Certbot还有一种模式，会篡改你的Apache或NGINX配置文件，试图将证书与虚拟主机绑定。编写 Nginx 集成的人也需要一记耳光，那简直糟糕透顶。我曾帮助许多人修复 Certbot 破坏配置文件后导致的服务器故障。仅仅因为你致力于加密网络，并不意味着你有权修改其他程序的配置文件，这不符合 Unix 的工作原理！
此外，那些决定服务提供商不再有权自主决定自身基础设施证书有效期的决策者也该被狠狠教训一番。
他们本就可以选择(购买)如此短的证书有效期。
这是专制主义的极致表现。
Certbot 还通过修改配置文件来记住命令行选项，以应对与 Andible 等工具的自动化和配置冲突，以便在紧急情况下手动操作时使用。
这是一款糟糕的软件。我使用的是Dehydrated，它对自动化支持要友好得多。
这些选择以及Certbot强烈推荐使用Snap安装，足以让我切换到https://go-acme.github.io/lego/，自此我对它非常满意。它非常稳定，感觉像是由真正运营服务器的人开发的。
停机时间是从哪里来的？如果你需要停机时间来提供新的静态文件，那么你的配置真的非常糟糕。
只有当你让Certbot关闭正常的Nginx并以独立模式占用80端口时才会发生。但实际上，如果正常的Nginx能独立完成任务，Certbot并不需要这样做。
当我需要使用HTTP验证时，我总是提前配置好Web服务器，使其从特定目录提供/.well-known/，并通过
certbot certonly --webroot-path指向该目录。无需关闭常规网页服务器。支持平滑重载。零停机时间。适用于任何网页服务器。这相当重要。Caddy 早已支持此功能，但并非所有人都愿意使用 Caddy。这可能会侵蚀 Traefik 等软件的用户份额。
我喜欢 Caddy 的地方在于其更优雅的语法。我目前使用 Nginx(通过 Nginx 代理管理器)和 Traefik，但最近在一个项目中尝试了 Caddy，发现它非常出色。未来我可能会抽空将自托管环境迁移到 Caddy，但可能更倾向于选择类似 Pangolin [1] 的方案，因为它也提供了 Cloudflare 隧道之外的替代方案。
[1] https://github.com/fosrl/pangolin
我同意。此外，其默认设置几乎总是非常适合我。以下是启用 TLS 的 HTTP/{1.1,2,3} 静态服务器的完整配置：
这就是全部内容。以下是包含上述配置、PHP 以及压缩功能的 WordPress 站点设置：
当然，您还可以调整和优化其他数以万计的选项，但对于大多数常见用例而言，您并不需要这样做。它比我曾经负责过的任何其他复杂服务器都更“开箱即用”。
我发现如果想要做一些超出基本功能且不符合官方建议的操作，文档对语法的说明有些不足。例如，我希望为内部服务使用通配符证书以隐藏服务名称在证书透明度日志中的记录，但无法让语法正常工作。ChatGPT 和 Gemini 也无法解决。
这就是实现方式，即为 secret.domain.com 的子域名设置通配符 DNS 记录。
{ acme_dns cloudflare oWN-HR__kxRoDhrixaQbI6M0uwS4bfXub4g4xia2 debug }
*.secret.domain.com {
谢谢，我今天晚些时候会尝试一下。
对于通配符，你需要一个包含特定提供商 DNS 插件的 Caddy 构建版本。有一个名为 xcaddy 的工具可以帮助实现这一点。虽然现在你需要自行管理二进制文件，但当我使用 Hetzner 时，它运行良好。
以防对其他人有帮助，这是我的操作步骤：
然后通过 Docker Compose 进行构建和运行
此集成不支持 DNS-01 挑战。因此，通配符证书目前无法使用。
附言：哦，这个子线程是关于 Caddy 的，不是 Nginx。那我的评论就不用理了！
Caddy 确实有一些奇怪的限制，我遇到过，特别是当它写入文件时，日志的权限不同，因此其他进程如 promtail 可以读取日志。使用 Caddy 时无法更改这些权限，它总是以非常严格的权限写入文件。
我发现他们的文档也非常难以理解，尝试在 Caddy 上实现一些在 Nginx 上非常简单的事情可能会非常困难，如果这些内容超出了“常规范围”
另一件我非常不喜欢的事情是，如果你通过包管理器安装以获取自动更新，你就无法获得任何插件。如果你想要插件，你必须自己构建它或使用他们的构建服务，而且你无法获得自动更新。
实际上，现在可以设置日志文件的权限了。参见https://caddyserver.com/docs/caddyfile/directives/log#file
哦，这很好知道！
你知道 Caddy 是否可以自动更新，或者有没有其他更简单的方法？手动更新以获取 Cloudflare 插件真的很麻烦。
不，你需要使用插件来构建 Caddy。我们提供了 xcaddy 来简化这一过程。在 GitHub 上订阅发布通知，然后编写一个简单的 Bash 脚本，使用 xcaddy 构建二进制文件并重启服务。你也可以尝试通过apt在Caddy的deb包版本变更时触发脚本，不过具体实现方式由你自行决定。
我想知道你为什么说“不”关于自动更新的事情。
https://caddyserver.com/docs/command-line#caddy-upgrade
因为这并非自动化流程，而是手动命令，且使用 caddyserver.com 的资源(相对低配的云虚拟机)，且无可用性保证。它不应用于自动化场景，仅适用于快速手动个人使用场景。
您可以让二进制文件通过当前包含的插件进行自我更新。我认为命令行帮助中提到这是测试版，但对我来说一直运行良好。
我来试试！
我使用 Caddy 作为主要反向代理，通过 CloudFlare 基于 DNS 的 Let’s Encrypt 进行容器访问。其语法直观且运行稳定。我过去曾使用 Traefik 与 Kubernetes 配合，尽管功能强大，但其配置和理解难度有明显更陡峭的学习曲线。
不仅如此，Nginx 将配置拆分为多个独立模块的结构带来了额外复杂性，而 Caddy 通过统一的配置方式避免了这一点。
我最近也尝试过 Pangolin，但后来意识到我已经拥有 Authentik，且其内置的 Go 语言代理已能满足需求，因此无需 Pangolin。
我最近切换到了 Caddy。Nginx 对 HTTP 1 异步问题缺乏明确说明让我决定更换。我不想等待愚蠢的事情发生，也不想让审计员提出 Nginx 无法解答的问题。
Caddy 比 Nginx 简单得多。首先，我现在有涵盖主要服务及其测试服务，以及为教育机构运行的特殊服务的模板。日志记录更好。证书处理完美(至少对我来说是这样)。而且它有更好的指标。
现在我必须弄清楚插件，因为Caddy没有速率限制，而PowerBI中的某个愚蠢的错误导致单个用户每天访问某些图像300,000次。这算是个缺点。
我通过谷歌搜索了同步问题，找到了这篇文章：https://my.f5.com/manage/s/article/K30341203
这种问题超出了我的专业领域。您希望看到关于该问题的哪些信息？什么会有所帮助？
nginx维护者的一份简单声明，说明如何配置以使脱同步攻击失败。这将非常有帮助。尤其是因为发起脱同步攻击的人声称nginx并非不可攻破。
我不知道F5是谁。他们看起来很正规，但那页在我的DDG搜索中没有显示。但现在已经太晚了。覆水难收。
肯定的。我在家里用Traefik做一些事情，现在可能会换掉它。
我通过在服务本身定义几个Docker标签来配置Traefik。我绝不会回到使用那个可怕的巨大Nginx配置文件。
Traefik速度更慢且占用更多资源。
它自2018年起就已集成到Apache中
这确实很早。我之前并不知道Apache有这个功能。看来现在很少有人讨论Apache了。
我也有同感，但去年切换到 Caddy 作为反向代理后，体验非常不错。
坦白说，这是因为尝试使用 nginx-unit 的经历总体上很糟糕，但 ¯_(ツ)_/¯
说实话，在Docker中配置Nginx和Certbot简直是史上最头疼的事。你需要证书来启动Nginx服务器，但又需要Nginx服务器来签发证书？看出问题了吗？更糟糕的是，网上有大量解决方案和博客文章，但我尝试过的没有一个能正常工作。如果有人能详细记录 Docker Compose 的相关操作，我将不胜感激。我不想使用像 nginx-proxy 这样的库，因为自定义该库本身就是另一个噩梦。
我必须说，这正是 NixOS 优势的体现。
这就是启动 Nginx 服务所需的全部内容。添加此块后，一切都能完美启动，使用正确的 systemd 沙箱，证书已配置，并带有 systemd 定时器用于自动续签证书。删除该块后，服务器仿佛从未存在过，所有内容都会被干净地拆除。
我最近想为我们的婚礼网站创建一个快捷域名，重定向到 SaaS 婚礼服务提供商。上述配置让这项工作只需 1 分钟即可完成。
> 非常感谢有人能详细记录 Docker Compose 的相关配置
在主机上运行 `certbot certonly` 一次以获取初始证书，并选择运行临时服务器而非使用 Nginx。然后在 `compose.yml` 中将主机的证书映射到 Nginx 容器。这样，在设置新服务器时无需修改 Nginx 配置。
你可以使用 Certbot 容器来处理证书续期。
例如：
在您的 nginx.conf 文件中，您有
以及
用于证书续期。
这就是我为什么在Docker之外运行Nginx的主要原因，我在这篇文章中详细讨论过：https://nickjanetakis.com/blog/why-i-prefer-running-nginx-on…
我在配置的服务器上将这些内容分开处理：
这种配置方式允许服务器通过HTTPS运行所有Nginx配置，而PKI相关部分可根据需求使用自签名证书或Certbot配合DNS验证。这避免了各种“鸡生蛋还是蛋生鸡”的依赖问题，并大幅简化了配置复杂性。
在自签名证书、Let's Encrypt 或第三方证书之间切换只需更新一个符号链接，因为 Nginx 已配置为读取目标路径。这使得测试变得简单，并增加了灾难恢复/可靠性，让我能安心入睡。
自这些工具可用以来，该组合一直运行良好。在 Let's Encrypt 推出前，我采用相同方案，只是使用了第三方证书。
nginx-proxy 存在什么问题？我们多年来一直使用它来处理 CI 将多个 Docker Compose 应用部署到同一服务器 [1] 的场景，且未出现问题，详细说明请见 [2]。
这在我们迁移到使用 Kamal [3] 之前一直服务良好，因为 Kamal 提供了改进的远程管理功能。
[1] https://docs.servicestack.net/ssh-docker-compose-deploment
[2] https://servicestack.net/posts/kubernetes_not_required
[3] https://docs.servicestack.net/kamal-deploy
我可以在原始 Nginx 配置中轻松编写一个简单的速率限制块，但使用 Nginx 代理时会看到这种混乱 https://github.com/nginx-proxy/nginx-proxy/discussions/2524
nginx代理的问题在于我无法控制nginx脚本 https://github.com/nginx-proxy/nginx-proxy/discussions/2523
通常的解决方法是，要么在获得证书之前不要添加 SSL，要么使用自签名/临时证书来启动 Nginx。
我个人在所有地方都使用DNS。我有一台中央服务器每天晚上运行dehydrated和DNS挑战，然后通过rsync同步到所有服务器(我打算用Vault替换它)。我喜欢有一个地方可以检查证书
我个人直接在Nginx上终止TLS，将Nginx直接部署在物理服务器上，所有服务都以容器形式运行在其后端。如果我使用Nginx代理到远程节点，我可能会直接使用内部PKI来处理。
> 启动Nginx服务器需要证书，但又需要Nginx服务器来签发证书？
我只是预先填充一个自签名证书来启动，不过我需要检查在 Docker 中如何实现这一点。
完全正确！听起来很简单，除非你想在 Docker 中运行东西，那时就会发现文档和资源严重不足
好的，如果使用Compose，现在似乎可以实现：https://stackoverflow.com/questions/70322031/does-docker-com… 因此，你可以创建一个初始化容器，运行类似于 `test -f /certs/whatever.crt || openssl 命令生成证书` 的操作，并告诉 Compose 在实际的 Web 服务器容器运行之前先运行该容器。
这很棒。我维护的 Dokku 对此有一个权宜之计，通过我们的 Let's Encrypt 插件实现，但这给用户带来了大量随机问题。Nginx 有时会卡在重新加载过程中，然后无法找到端点。变量越少越好。
不过，要让这个功能进入 Ubuntu 和 Debian 的稳定仓库还需要相当长的时间，而且它目前(至少)不支持 DNS 挑战(即不支持通配符)，因此我认为短期内对 Dokku 来说可能没什么用。
嘿！很高兴在这里见到你。
我尝试过 Dokku(并且仍在使用！)，但初始化过程非常困难。
作为参考，- 我成功使用了Coolify，它要求我创建一个GitHub应用程序，以便在推送到主分支时部署我的应用程序- 我编写了GitHub Actions来构建和部署容器到大型云平台
如果我想实现相同的目标，这就是我看到的内容，它完全采用了一本参考书的风格——我觉得自己在读百科全书。https://dokku.com/docs/deployment/methods/git/#initializing-…
与之对比的是这个，它立即可用且能帮助我快速部署应用：https://coolify.io/docs/knowledge-base/git/github/integratio…
我希望Dokku能提供热门开源应用的教程，以及以设定目标、快速完成为导向的入门指南。我非常希望看到一篇从裸金属服务器到反向代理加几个热门应用的完整指南。因为价值不在于使用Dokku本身，而在于通过Dokku达到那个状态。
我正在尝试使用Dokku搭建家庭服务器。
理想情况下，我希望有一种无痛、快速的方式，从“嘿，这里有一个我喜欢的仓库”到“在我的机器上部署完成”，全程使用Dokku。然后一旦成功，再深入了解其底层实现。
大型开源公司的问题在于，它们总是非常迟缓地理解和实现最基本的创新。
Caddy 和 Traefik 早在半年前就实现了这一点，而经过半年的时间，我们终于也看到了 Nginx 对它的支持。不过这是一个不错的举措，终于不用手动运行 Certbot 了 :pray:
Caddy早在近十年前就实现了这一功能。据我所记得，早在2016年它就具备某种形式的自动Let’s Encrypt HTTPS功能。
因此Nginx几乎晚了9到10年。哈哈
事实上是2015年。十年前。
开源项目的妙处在于，如果有人觉得将某功能内置到服务器中至关重要，他们本可以在多年前就实现这一点。
考虑到 Caddy 的历史中包含过“如果无法联系到 Let’s Encrypt 而磁盘上存在有效证书时拒绝启动”这样的选择，我更倾向于将证书签发与 Web 服务器分离。
我本来就需要一个工具来为其他服务颁发证书，我不明白为什么人们会希望将它嵌入到他们的Web服务器中。
我记得你。你只是因为没有首先想到这个想法而感到不快。;)
正如我们每次讨论时所强调的，这已经是8年前的事了，当时项目尚处于起步阶段，项目作者正忙于考试，此后情况已不再如此。Caddy自那时起已从头重写，与旧版本进行比较是不公平的。
问题不在于存在相同的代码，甚至不在于它有奇怪的意外行为。
作者未能理解为何其荒谬至极的“预期行为”从一开始就是糟糕的设计。
难道你一生从未犯过错误？你认为如果孩子在学校考试中只得了B，他们就无可救药了吗？这种观点真是荒谬至极。
看到这个很好。对于那些不知道的人，有一个低成本的解决方案，结合https://github.com/dehydrated-io/dehydrated和你在vhost配置中添加的几行简单代码：
Dehydrated已经存在一段时间了，是http-01续期自动化的一个低开销的优秀选择。
相同的配置也适用于 Certbot。我已经使用它多年了。
这真的很酷，但我认为那些有成千上万人依赖的项目不发布稳定版本是非常令人不快的。
编辑：尽管你们可以随意给我点赞，但这就是现实。如果不发布 v1.0.0，你们使用的接口可能会在不知不觉中发生变化。
不要使用主要版本为 0 的软件，它终将反噬你们。说服你们的维护者发布稳定版本，如果他们已经使用主要版本 0 数年。这只是滥用语义版本控制的懒惰和不成熟做法。维护者可以学习和成长。这是正常的。
Dehydrated已经保持主要版本0长达7年，可能已经过期了。
参见React、LÖVE和其他从0.n.x跳转到n.x.x的项目。(https://0ver.org)
CalVer：“如果你和你不认识的人都认真使用你的项目，那么就使用一个认真的版本。”
SemVer：“如果你的软件正在生产环境中使用，它很可能已经达到 1.0.0 版本。”
https://0ver.org/about.html
谁觉得这令人不快？依赖它的人？当然不是……提供免费软件的人？当然不是……
也许不是特定的人觉得不快，而是命运使然，或是激励机制不匹配的信号？
> 令人反感的是谁，是依赖它的人吗？当然不是……
为什么不是？
这就是开源的伟大之处。如果你对免费劳动力实现你想要的功能的速度不满意，你可以自己动手！
没错，绝对可以！我可能会选择一个版本进行分支，将其设为 v1.0.0 用于组织的生产环境，这样你就知道行为不会改变。
然后你可以从上游合并更新。
通常处理破坏性变更更容易，因为编写代码比理解变更更快，而外部 API 的破坏性变更通常比内部变更有更好的文档记录。
顺便说一下，我已经使用并依赖 Dehydrated 来处理 LetsEncrypt 自动化大约 10 年了。我认为在这段时间内只有一次生产环境破坏性变更，据我所知，这并非Dehydrated特有的问题，而是ACME协议的变更。我记得解决该问题的过程非常简单，只需更新Dehydrated客户端并修改配置文件即可。
它一直是我基础设施中最可靠的部分之一，我几乎不需要去想它，以至于我不得不从自动化仓库中查找链接。
你从2015年12月Dehydrated的首次提交开始就一直在使用它吗？
我确信这是让我了解它的帖子：https://news.ycombinator.com/item?id=10681851
遗憾的是，web.archive.org 并未在该时期抓取我主站点的 HTTPS 版本。我当前收藏中最早的服务器构建脚本中确实包含以下注释：
…因此我当时使用的是 lukas2511 账户下的版本。然而，这些技术笔记是从一个早已停用的Phabricator安装中恢复的，因此我不再拥有它们的更改历史记录，除非我回去尝试恢复其数据库，我认为我仍然在其中一个冷存储驱动器中保留着它…
但没错，大约在2015年至2016年左右应该差不多。我从…天啊，2009年就开始为客户托管服务了。因此，LetsEncrypt是我很早就想采用的工具，因为当时证书续期既麻烦又常常需要付费，但我也不想使用当时流行的ACME客户端。后来这篇帖子出现了，正是我一直在寻找的解决方案，我很快便开始使用它。
编辑：我的Linode账户自2009年10月以来一直处于活跃状态，尽管现在上面只运行着几个小型遗留服务。我当初创建这个账户的目的是专门为当时的客户提供邮件和网络服务。所以，是的，我的记忆应该还算准确。
欢迎提供并支持符合您标准的“稳定”分支/分叉。
成为您希望看到的改变！
编辑以评论编辑：
> 编辑：随你喜欢给我点赞
我通常不会点赞，但如果我要点赞，我无需你的许可 🙂
> 这就是现实，朋友们，如果你不发布 v1.0.0，你使用的接口可能会在你不知情的情况下发生变化。
我假设你那里指的是“当前版本”而不是“使用”？
无论如何，1.0.0 只是一个数字。没有相关承诺、记录或合同作为支撑，破坏性更改的可能性与任何其他版本号一样高。一个被广泛使用和审查的开源项目的“0.x.x版本”比一个刚刚贴上1.0.0标签的版本更可靠和值得信赖。
在更多父级编辑后编辑：或者选择其他许多版本控制方案之一。也许ItIsFunToWindUpEntitledDicksVer会说：“永远使用0.x版本，去吧，你知道你想要的！”
另一个人认为Semver是一种神秘的法律魔法，这很好地说明了Semver为何从一开始就是一个错误。
为了安抚 semver 的拥趸，将版本号段永久设为零前缀是最实用的方法，毕竟他们数量众多，且试图依赖 semver 所谓的“神秘法则”在工具中实现依赖关系。这有点像浏览器用户代理中的“Mozilla”； 我希望我们能止步于牺牲一位数字，而不是像用户代理那样发展下去。
换句话说，0ver，毫不夸张。但愿我们不需要0.0ver。
这次发布有一个小错误：他们为许多Linux发行版打包了ngx_http_acme_module，但“忘记”了Debian稳定版。Oldstable和oldoldstable在https://nginx.org/en/linux_packages.html(今日构建的包)中列出，但4天前发布的Debian 13 Trixie并未包含在内。
我目前正在努力将 Trixie 包上传。本周内会完成。
正如你所说，Debian 13 发布于 4 天前——为新操作系统搭建基础设施需要时间(且我们正忙于其他任务，如发布 nginx-acme 和 1.29.1)。
(我供职于F5)
这大概是Debian的问题吧
这是怎么回事？这些是供应商包
IT领域的过山车，两则反应：
> Nginx引入对Acme协议的原生支持
IT：“该死，终于来了！”
> 当前预览实现支持HTTP-01挑战以验证客户端的域名所有权。
IT：“该死。好吧，域名注册商，给我一个新的通配符证书吧，领先的网络基础设施提供商在2025年仍然无法完成基本的LE DNS-01拉取。”
说真的。IT 中的 PKI 是个麻烦事，我希望有人能 解决它，而无需依赖 AD CA 或又一个超特定设备(YAHA)。如果你的负载均衡器、代理服务器、Web 服务器或路由器设备无法通过 DNS-01 挑战为我生成一个基本的 Acme 证书，那么你正式不行了，我一有机会就会把你的产品扔掉，改用 Caddy 之类的。
顺便说一下，我们能否允许 DNS-01 证书用于中间证书颁发机构，从而使内部签名的证书通过该中间机构生效？这将解决任何组织中 99% 的 PKI 需求，永远有效。
如果你需要支持通配符域名的DNS挑战类型，你可以切换到Angie分支：
https://en.angie.software/angie/docs/configuration/modules/h…
DNS 挑战的复杂性在于每个注册商都有自己的 API。HTTP 对 Nginx 来说更简单，因为它是一个单一流程，而且 Nginx 本身已经支持 HTTP。
我确信 Nginx 将来会支持 DNS，但它何时会支持你的特定注册商，或者是否会支持，仍然是一个开放的问题。
> DNS 挑战的复杂性在于每个注册商都有自己的 API
您可以通过将 ACME 密钥委托给自己的名称服务器来绕过这一问题。
> 允许通过该中间机构验证内部签名的证书
按设计，任何实体都不得委托签名权限，因为一旦委托的权限被泄露，所有被委托的内容将立即面临安全风险。由于只有证书颁发机构(CA)能够签发证书，且CA必须通过基本的安全审查，因此客户端可以确信，签发证书的实体是从可信的权威机构获得该证书的。如果你想要一个不可信的权威机构……那就使用自定义CA。这样做是故意设计成困难的。
> 如果你的负载均衡器、代理服务器、Web服务器或路由器设备无法通过DNS-01挑战为我生成一个基本的Acme证书，那么你正式失败了，我会在第一时间用Caddy之类的产品取代你的产品。
我的意思是，这是一个合理的要求。一旦某个流行的企业产品包含这一功能，它就会变得更加普遍，然后所有竞争对手都会采用它，以免错失商机。要让第一个采用它，你需要成为一个大客户，大声要求它，然后等待18个月。
> 如果你想要一个不可信的权威机构……那就选择一个自定义的CA。这样做是故意设置障碍的。
这就是让我感到恼火的地方。
在IT领域，_一切_都需要一个有效的证书。打印机、服务器、hypervisor、负载均衡器、WAP的UI，一切都需要。不过，_大多数东西_并不需要一个_公开有效的_证书。
也许“中间CA”并不是我想要的准确表述。理想情况下，它应该是一个能够对非通配符证书进行公开的DNS-01验证的设备，从而赋予其合法性。然后，它会为_仅内部设备_生成证书，这些证书将通过根CA获得信任，但无需这些设备连接到互联网或使用通配符证书。换句话说，某种标记或指纹表明“这是有效的，因为我信任根CA并且我可以验证内部中间CA。如果我无法看到中间CA，则该证书无效。”
这种思路是，这将允许内部更轻松地签发更多证书，而无需像完全定制的内部CA那样涉及额外的管理层级。这样是否同样安全？不，但它对中小企业更友好，并有助于改善整体安全卫生，而不是让所有设备使用带有自签名证书警告的HTTPS，或让每个设备都通过互联网进行HTTP-01挑战。
如果我能让PKI与内部技术栈的其他部分一样简化，且无需支付大量费用购买Microsoft服务器许可证和CAL，我将是一个非常开心的“恐龙”，对跟踪众多自定义证书续期和部署的担忧将大大减少。
你可以使用管理员终端和脚本通过DNS-01请求1000个不同名称的证书。将证书复制到需要它们的设备上。现在的大问题是，由于LE的决定非常烦人，你需要在约5天内不断重新复制新证书并重启设备。如果你想少点烦人……那就付费购买证书。
安装自定义CA证书其实并不难，只要你弄清楚如何为每个应用程序操作。我不得不为IT团队编写所有相关文档，针对每个应用程序进行说明，因为他们太懒得自己动手。一开始很痛苦，但之后就容易了。为了避免以后更多麻烦，让证书在2036年过期，并在过期前退役。
我持续遇到的问题是，将此任务委托给同事或其他团队时，不可避免地有人认为自己很聪明，绕过部分或全部流程，例如生成通配符证书并将其私钥组件分享给任何要求证书的人，而不是通过批准的流程。在PriorBigCo，我们有一个专门负责全球内部PKI的团队，尽管有72小时的处理时间，我们仍然有人绕过流程。这导致了证书撤销，进而导致更多时间用于处理“紧急”续签，这简直令人头疼。
自动化是目标，而目前内部PKI远未像面向公众的证书那样实现自动化。借助ACME，我可以对不处理敏感数据或不需要高级证书的公共服务实现设置后无需维护，但内部环境似乎唯一可行的解决方案仍是ADCA。
通过使用CNAME与_acme-challenge，结合具有精细授权的API密钥，你可以管理每个同事或团队可以签发证书的范围。例如，你可以禁止他们签发通配符证书 🙂
中间证书并非严格意义上的委托机制。它们是通往根证书信任链的途径。
信任始终存在于根证书本身。
这并非类似于活动目录/LDAP/树结构的机制，您无法指定“我信任此节点级别及以下的内容”。
但它们本可以且我认为应该成为委托机制。名称约束扩展已存在。
问题在于，约束机制超出了固有的信任链逻辑范围，而是通过应用层逻辑进行验证。
因此，您必须修改所有潜在客户端以强制执行此约束。因此，它实际上毫无价值，因为无法以任何有意义的方式进行部署。
感谢您的澄清！我的异议仍然成立，但至少我以后可以更清楚地表达它。
> 设计上，不允许任何实体委托签名权限，因为一旦委托的权限被入侵，所有被委托的内容都会立即受到威胁。
或者因为这会暴露Web PKI的荒谬本质。让某个位于偏远地区的可疑公司拥有为.gov.uk域名或甚至你个人网站签发证书的权限，简直是荒谬至极。证书颁发机构的权限本应像域名服务器权限一样被委托。
哪家拥有足够基础设施来管理一个_IT部门_的公司，却只在Web服务器上使用证书，从而没有一个标准工具来为所有需要证书的服务颁发、续期和部署证书？
发现 Caddy 后，我不再使用 Nginx。开发体验明显更好。
我从未认为 Nginx 仅提供网页内容而让 Certbot 处理证书续期是问题。专注做好一件事并使其可组合难道不好吗？试图包揽一切的臃肿工具必然会在某些关键环节表现糟糕。
这个可选模块让简单场景变得更简单。
内容服务和证书管理使用独立工具并非问题，且此处无需任何改动。此外，该模块无法覆盖所有需求。
顺便说一句，与其他 ACME 工具(如 Lego)相比，Certbot 更像是一个“臃肿工具”。我过去曾因 Certbot 试图自动处理太多任务而遇到过糟糕的体验，且难以诊断问题——尽管我认为 Certbot 后来已被重写，因为它不再依赖于 Python Zope。
使用 Nginx 和 certbot 进行配置非常麻烦，尤其是 HTTP 挑战。主要是因为存在循环依赖关系。你需要 Nginx 来清除挑战，一旦 Verboten 获得证书，就需要重新加载 Nginx。
我切换到 Lego，因为它对我的域名注册商有开箱即用的支持，因此我可以使用 DNS 而不是 HTTP 挑战。它也是一个单一的可执行文件，安装起来比 certbot 简单得多。
由于 HTTP 挑战使用未加密的 80 端口而非 HTTPS，因此不存在循环依赖关系。证书更新后重新加载 Nginx 配置也不是问题，因为 Nginx 可在不造成停机的情况下完成此操作。
nginx 配置中存在依赖关系。你必须指定证书的位置。因此，你必须在启动 nginx 之前拥有一个可用的配置，然后获取证书并修改配置以包含证书/密钥位置，之后才能对 nginx 进行 HUP 操作。这非常脆弱，尤其是在新服务器或需要定期启动干净节点的环境中，因为此时可能会发生各种意外情况。当你已经拥有证书和有效的配置文件，只需续签证书时，系统会稳定得多，但并非所有环境都如此。我甚至无法肯定地说大多数环境都是这样。
配置起来有点麻烦。据我所知，Certbot 曾经可以尝试自动配置，但除非你的环境是默认配置，否则它不会生效。让 Nginx 处理所有配置似乎是更好的解决方案。
Certbot 同样可以与 Nginx 配置的目录配合使用，只需将 Nginx 指向 .well-known/acme-challenge/ 目录即可。无需自动配置魔法。
我也想知道同样的问题。我得出结论，这很大程度上是由管理层对 DevOps 的理想定义驱动的：开发人员最终在没有足够知识或经验的情况下承担运维工作。
哦，这太令人兴奋了！Caddy 的支持非常方便，而且它开箱即用就能做很多其他事情，这太棒了。
阻止我切换到 Caddy 的一个原因是 Nginx 的速率限制和地理模块。
似乎 HAProxy 也在最近的 haproxy-3.3-dev6 中添加了 ACME/DNS-01 挑战支持。https://www.mail-archive.com/haproxy@formilux.org/msg46035.h…
它在3.2版本中添加了ACME，DNS挑战即将推出：https://www.haproxy.com/blog/announcing-haproxy-3-2#acme-pro…
证书管理仍在不断演进的事实让我意识到，在整个互联网发展历程中，网页技术仍然处于初级阶段。
> 未来计划支持其他挑战机制(TLS-ALPN、DNS -01)。
对此充满期待。HTTP-01 配合 Certbot 已经能满足我的需求(我本就需要 Certbot 用于其他服务，且它能让我更好地控制多个域名在同一证书中的管理)，但对于通配符证书，目前可选的优质解决方案并不多。
基本上，我选择安装 Caddy 而不是 Nginx 作为反向代理的唯一原因是，Caddy 只需一行命令即可配置 TLS 和 ACME。也许这会改变现状？不确定。
只是想确认一下，这意味着我们可以使用 Nginx 配置中的几行代码作为替代方案，无需安装和运行 Certbot，对吧？
此外，这是否会让使用 Let's Encrypt 的替代方案更容易实现？
是的，配置中添加几行代码后，就无需再使用 Certbot。
你可以指定任何 ACME API 基础 URL。它不仅限于 Let’s Encrypt。
有关于续期的部分，但没有描述它是如何工作的。是否有后台线程/进程？还是基于请求驱动？如果是基于请求驱动，那么对于某个主机名(以某种方式)在 >90 天内没有流量的情况，该如何处理？
有人知道这在多个 Nginx 后端或故障转移服务器上如何工作吗？我假设只能为在线服务器自动获取证书。是否预期需要使用 SCP 或类似工具将证书从在线服务器复制到故障转移/新服务器？
故障转移并不需要完全相同的证书。只需一个有效的证书即可。甚至不需要为负载均衡器中的每个条目使用相同的证书。客户端在解析后会选择一个IP地址，然后连接到该地址，并在整个会话中持续使用该TLS连接。
但你需要Let's Encrypt(或你使用的任何ACME提供商)连接到你正在尝试设置证书的同一服务器。而且他们会故意从多个地理位置不同的地点获取挑战响应。
一旦 Nginx 支持 DNS-01，是否意味着我们可以使用 Let's Encrypt 进行 SSL 通配符证书？
这是一个良好的开端。减少了一个复杂环节。他们应该在功能上与 Caddy 保持一致，并添加 DNS-01 挑战。
我最近不使用 Nginx 就是因为这个原因。
我们已经使用 Caddy 多年了。选择它只是因为它支持自动证书颁发。Caddy 确实是一个更简单的替代方案，开箱即用且安全。
何时会进入主流发行版(不包括PPAs等)？鉴于Debian最近发布了新稳定版本，我估计Debian会在2027年8月，而Ubuntu可能在2026年4月？
在这条帖子中，有人抱怨Certbot使用Snap进行分发。想象一下发布新功能后，用户需要等待1-2年才能在广泛范围内获得更新。
Nginx维护自己的仓库，你可以从中在Ubuntu/Debian系统上安装Nginx。
我查看了Arch，发现他们落后了一个版本，这让我感到惊讶。看来这不是一个维护得很好的Arch包。
Nginx 有稳定版本和主线版本，分别在 Arch 中打包为 `nginx` 和 `nginx-mainline`。两者看起来都比较新。
我猜他们抱怨的是 Snap 与 Flatpak 的对比，而不是与发行版包仓库的对比。
实际上这就是我开始使用 Caddy 的原因，而且配置也更简单！
看到这一点很好，我没想到这种情况没有立即发生在几乎所有事情上。
我以为要么 Let's Encrypt 无法正常工作，要么大家会在 2-3 年内将 ACME 集成进去。2025年，你可以购买带有TLS加密的软件，但它却要求你自己去处理证书。这就像汽车必须定期去一个专门的建筑物加油，而这个建筑物除了充电外没有任何其他用途，就像手机一样……嗯，我明白你的意思了。你们这些人真奇怪。
对于一组边缘服务，如何在不同区域进行负载均衡，但所有服务共享一个证书？每个Nginx实例是否都需要经过相同的协议/配置步骤？
使用Let's Encrypt会受到严格的速率限制，但如果你自行搭建ACME服务器，可以采用这种方式。
如果你想使用 LE，你可以通过某种“传统”的证书续期流程在外部完成，然后通过你设计的协调机制分发生成的密钥/证书(并重启 Nginx 实例)
它们不需要共享同一个证书。对于同一个地址(或地址集)，可以且可能需要签发多个证书。这意味着，如果一个前端服务器被攻破，不会暴露所有连接到更大服务器的通道。
缺点显然是证书维护工作量增加，但ACME自动化了其中绝大多数工作。
这是一个开端。也许这可以作为一个概念验证，证明这是可行的，然后其他协议也可以实现。
和这里许多人一样，我非常希望看到Cloudflare DNS支持。
Certbot 提供了一个 Nginx 插件，所以我不知道为什么人们认为在 Nginx 上使用 Let's Encrypt 很难。
也许现在情况有所改善，但即使作为一名经验丰富的系统管理员，我发现 Certbot 在实际使用中令人极其烦躁。他们试图让它对初学者来说易于使用且通用，但他们使用了大量“魔法”来对你的主机和服务器配置进行奇怪的操作。如果你在一个环境中，只需通过 tarball 安装东西，用 Nano 编辑配置文件，然后很少再触碰整个设置，那么它可能工作得很好。
但如果你需要对主机配置进行严格控制(通过Ansible等工具管理)，因为需要符合安全标准，或者需要整个系统配置可重复部署以应对灾难恢复等场景，那么像acme.sh或LEGO这样的解决方案会小巧得多，配置同样简单，而且通常不会给你带来意外。
Certbot 就像一把万能瑞士军刀，可以中等水平地完成所有任务，如果你不介意通过代码配置加密基础设施的话。但它通常不是一个干净的解决方案。
(话说回来，我对这个实现并不太满意。续订和撤销是如何处理的，以及如何调试这些过程？我希望文档能尽快更新。)
Certbot 对我来说一直工作正常。它几乎可以自动检测和处理所有事情，除非你手动指示它做什么(例如重复使用特定的 CSR)，然后它会按照你的指示行事。
它并非严格意义上的 Ansible/Kubernetes 兼容解决方案，但如果你使用这些工具，你已经知道有一个工具可以解决你的问题。
从看似一致的意见来看，我原本担心在 Nginx 上配置 Let's Encrypt，直到我实际操作后发现……完全直观且毫无痛点。
也许如果你偏离了标准流程，事情会变得复杂，但我发现默认的Certbot流程非常简单。
从快速查看来看，这似乎是一个用于重新配置Nginx的命令？而且这与证书的自动续期是分开的，对吧？
也许不算难，但Caddy似乎更简单。
我想我应该将它与这个新的 Nginx 功能进行比较，而不是 Caddy。这个功能的好处似乎在于你不需要运行一个工具，而是需要配置一个设置。因此，如果你更换服务器，重新部署会更容易，而且你不需要担心 Certbot 是否在进行续期。
在Docker Compose中让这个功能正常工作简直是一场噩梦。目前还没有人文档化一个可行的解决方案。太多奇怪的细节和第三方工具，比如GitHub上的nginx-proxy-manager或nginx-proxy/nginx-proxy，让情况更加糟糕。
Certbot 是一个只能通过 snap 安装的工具。这种垃圾不会出现在我们的服务器上，而且许多人持相同观点。
因此，这一改动非常受欢迎。
这听起来不对劲。它已经在 Debian 和 Ubuntu 中存在一段时间了：
* https://packages.debian.org/bullseye/certbot
* https://packages.ubuntu.com/jammy/certbot
上次我关注时，情况是这样的：
https://github.com/certbot/certbot/issues/8345#issuecomment-…
不过这已经过去三年了。EFF/Certbot团队因此事让我对他们失去了很多好感，我不会再回去使用了。
这是一个可以通过pip安装的Python包，我从未通过Snap安装过它
但它能为内部网络使用生成自签名证书吗？在内部网络中，通常希望加密流量以防止使用Wireshark进行随意监听。
说实话，感觉有点多余……
自动化 Web 根目录配置非常简单，我更倾向于使用外部 Rust 工具来处理，而不是 Nginx 的模块。如果你的网站只需要证书，那这个工具可能有帮助，但我还有很多其他用途需要证书，所以无论如何都需要外部工具。
而且目前还不支持 DNS-01。
不错，这会很有用。目前我只使用 Certbot，它做得相当不错。我只需设置 HTTP:80 配置，Certbot 就会将其迁移到 HTTPS:443 并处理证书等事宜。目前，我可能会继续使用它，直到这个功能成熟。
是否有一种方法可以在续签成功后通知其他服务？我的XMPP服务器也需要使用该证书。
我已经迁移到Caddy了 😉
这个功能在Angie分支中很久以前就已引入，并且支持得更好。
以下是Angie版本的http_acme模块的文档：
https://en.angie.software/angie/docs/configuration/modules/h…
Angie ACME 的原始公告：
Angie，Nginx 的分支，支持 ACME – https://news.ycombinator.com/item?id=39838228 – 2024 年 3 月 27 日(1 条评论)
如上所述，ACME支持似乎已随Angie 1.5.0于2024年3月27日发布。
顺便说一下，如果你不关心ACME，想要原版的Nginx，那么还有Freenginx分支：
Freenginx：核心 Nginx 开发者宣布分支 – https://news.ycombinator.com/item?id=39373327 – (1131 分) – 2024 年 2 月 14 日 (475 条评论)
正是这件事让我从 Nginx 转向了 Caddy。
但我不会回头。Nginx 的配置实在令人头疼，充满了各种谜题、意外和陷阱。
看起来这在基础 Nginx 中并未默认包含，需要作为独立模块进行安装。还是我搞错了？
https://github.com/nginx/nginx-acme
Nginx本身主要是一系列模块的集合，具体包含哪些模块由构建/打包Nginx发行版的开发者决定。默认情况下，Nginx 甚至不会编译 SSL 或 Gzip 模块(不过幸运的是，它会默认编译 HTTP 模块)。历史上，Nginx 只支持静态模块，这些模块需要在编译时启用或禁用，但现在它支持动态模块，这些模块可以单独编译并在运行时加载。一些较旧的静态模块现在可以选择编译为动态模块，而新模块通常会以动态模块的形式编写。发行版可以选择将新动态模块打包到基础 Nginx 包中、作为单独包，或完全不打包。
在典型发行版中，通常会提供一个或多个虚拟包，代表不同配置文件(如最小、标准、完整等)，这些配置文件依赖于一个提供 Nginx 二进制文件的包，该二进制文件默认启用了所有合理的静态模块，并附加了若干单独打包的动态模块。
是的，这是正确的。
我们大约有 100 个域名需要重定向到新位置。我之前的职位持有者使用 GoDaddy 域名和重定向设置了所有内容。我对所需的努力程度感到震惊，当浏览器首先切换到 HTTPS 时，设置是如何严重损坏的。
这时我发现了“golang.org/x/crypto/acme/autocert”，并用它构建了一个自定义重定向服务器。它实现了TLS-ALPN-01，与Let's Encrypt配合得非常出色。
现在，我们只需将域名添加到Web配置中，设置其目标和重定向方式，然后将配置推送到提供公共服务的EC2实例。当第一个客户端发起请求时，它会被暂时“挂起”，而服务器会在后台安排证书的签发。一旦证书签发并安装到服务器上，服务器就会继续处理原始客户端的请求。
这简直轻松至极，让我彻底厌恶回到使用DNS-01或HTTP-01挑战的时代。
天啊，仅仅为了这个就引入对Rust的依赖吗？
目前我将继续使用现有的方案(nginx + certbot)，但会尝试这个方法。有人试过吗？
Caddy听起来也很有趣，但我担心切换后现有方案会出问题。:/
我从 Apache 起步，最终成为其配置、众多选项和故障模式的专家。后来我对 nginx 感到半熟练，因为它比 Apache 简单，但如果你运行奇怪的遗留 PHP 应用程序，你仍然可以配置相当复杂的设置。
当我第一次尝试用 Caddy 处理严肃任务时，我以为自己漏掉了什么。我心想，这些文档一定不完整，一定还有更多内容，它怎么知道根据Y来做X，这根本行不通……
但它确实行得通。它几乎不需要任何配置。你只需设置最基本的配置，Caddy会自动处理剩下的部分并使用合理的默认值。文档非常出色，周围还有一个不错的社区。
如果我有什么不满的话，那就是插件系统有点古怪。
Caddy对我来说非常棒。如果你当前的设置已经正常工作，我认为没有必要切换，但在新项目中尝试一下也是值得的。
我喜欢它！！！我在Debian上使用Apache mod_md进行个人项目。目前运行正常，但每次搭建新站点时，不知为何需要重启Apache两次，这不太顺畅。
有趣的是 mod_md 如此鲜为人知：https://httpd.apache.org/docs/2.4/mod/mod_md.html
不过话说回来，现在主流的Web服务器都内置了ACME支持：Nginx、Caddy和Apache2！当然Caddy会是最完善的，因为这是其主要卖点之一。
终于！！！
Nginx 是否仍然将 Prometheus 指标和主动探测功能锁定在 $$$$$(字面意思是数十万美元)之后？忘了第三件最重要的事。我认为是重新解析上游服务器。
无论如何，祝你好运保持竞争力，哈哈。我认识的几乎所有人要么跳槽到更理性的平台，要么正在迁移过程中。
是的，我不想让我的Web服务器变成systemd并更改证书。这对于本应在其他地方处理并协调滚动证书更新的功能来说过于复杂。
如果在部署时将NGINX配置与这些更新一起提交，你可以减少一个进程，如果你正在做类似以下操作：
因此，遗憾的是，这种支持方式似乎比使用 certbot 更复杂，但至少减少了一个手动步骤。
示例来自 https://github.com/andrewmcwattersandco/bootstrap-express