有多少人正真知道 amce challenge 的区别?

http 服务器在 http://<YOUR_DOMAIN>/.well-known/acme-challenge 路径返回 challenge token 。

@holulu http （ HTTP-01)可以直接复用端口，但是 https 呢？

一般用这个 HTTP-01 去做，就是一楼说的那样
有些基于 acme 做的，是先检查 DNS-01 ，如果不行再检查 HTTP-01 ，正式环境都有错误限制，最好在测试环境的上做

DNS-01 是一种，直接修改 DNS 的 TXT 记录，且支持 CNAME ，比较适合一个证书里面多个域名进行批量申请
HTTP-01 和 TLS-ALPN-01 是同一种，需要通过域名的解析记录进行实际访问，分别对应 80 端口和 443 端口

比如需要预申请证书，就得用 DNS-01
如果是已经在运行的服务器需要申请证书，可以用 HTTP-01 和 TLS-ALPN-01 申请正在运行的服务端的证书

只有 DNS-01 支持通配符

@DejavuMoe 是的，这个概念很重要。如果深入思考的话，只有 DNS-01 支持是必然的。IP 证书，或者 http-01 ，tls-alpn-01 都只能确定单个 hostname 。

@diudiuu ‘有些基于 acme 做的’这个表述说明你还不是很清楚这个问题，需要继续思考。

@jianglibo
github.com/go-acme/lego/v4/lego

这个，用的 HTTP-01 去做的申请，但是每次都会先检查 DNS-01 这个，具体没有细究。
我觉得你的问题点就是后面已经申请证书的怎么去更新维护，到底是走 http 还是 https ，目前我是两个端口 80 443 都保留，虽然不是很优雅.

不是咱挑刺啊，是 acme 不是 amce……

@qwx sorry,typo. 我改一下。

DNS 验证不用说你应该都知道了吧，至于 HTTP-01 其实和 TLS-ALPN-01 差不多的，只是一个是文件验证，一个是 TLS 握手阶段进行协商密钥签名验证，为此我在前两年就用 go 语言专门写过对应的服务端(实现自动化)和客户端验证(提交 ACME 前自己先预检一次)。

AD: 欢迎使用我的网站 草啦 SSL （ https://cao.la ）进行手动申请免费证书。

nginx 只支持不停机 HTTP-01 ，用 TLS-ALPN-01 必须停机一段时间将 443 端口用 stream 转发到 acme 客户端。

另外一个新的 challenge 预计今年内可以上线 DNS-PERSIST-01 ，手动在 DNS 记录配置一个公钥可以无限次续签通配符证书，从而使 acme 不需要去修改 dns 记录。

@diudiuu 为了便于你理解，我简化描述一下流程。你：请给 xxx.xx.com 签发证书，acme server: 给你一个它支持的 challenges 列表，比如 http-01,dns-01...。 你：请使用 http-01 验证，acme server: 好的，我就用 http-01 验证，它不会去遍历所有的 candicates 。

@cccer 不用停机，你可以做到，给你一个提示 steam ，你访问我提到的网站，我保证你可以成功不停机自动更新 nginx 和 haproxy ，我自己的网站就是这么做的啊。

@cccer 又是一个 typo ，stream.
stream {
map $ssl_preread_alpn_protocols $stream_backend {
~*acme-tls/1 127.0.0.1:9443;
default 127.0.0.1:8443;
}

server {
listen 443;
listen [::]:443;
proxy_pass $stream_backend;
ssl_preread on;
}
}

@jianglibo acme 只会访问 80 端口，如果你的服务器跳转 443 ，acme 应该会 follow ，并且忽略证书验证，只检查 http body 里的 challenge token

@holulu 你在说什么呀，至少先问问 AI 再发表这种外行的言论.

@jianglibo 你把我弄蒙了，我看你啥都知道么。

@jianglibo 学到了，原来可以用 ssl_preread_alpn_protocols 区分 ssl 流量

@caola 我尝试了一下：
域名:
_acme-challenge.www.cao.la
验证值:
oX2rQVj7mBB4dXND2MglxPlGNSLlyucOsN7JlPPMpj0
说明只支持 CNAME 验证,无法申请 IP 证书, 如何自动更新也是个问题，除非有 agent 。有 agent 的话，就可以在验证开始时自动 spin up 一个监听器，结束后解除监听。可以完成所有的自动化过程，比如将证书合并,haproxy 需要将 pem 和 key 合并到一个文件。

DNS-01 是设置 DNS 记录来证明域名所有权。
HTTP-01 是在特定的 URL path 下返回指定的内容来证明域名所有权。
TLS-ALPN-01 是通过 TLS 握手的时候，在 ALPN 里携带 acme-tls/1 （区别于一般的请求携带的可能只有 h2 和 http/1.1 ），并且携带 SNI 表示具体域名，然后服务端拿到 Client Hello 后需要临时构造一个自签名证书来响应，证书报告特定的扩展字段（具体查文档吧，不记得了），以此来证明域名的所有权。

HTTP 只需要特定路径返回，TLS 可以在 Client Hello 阶段分流（类似于一个网站针对不同域名使用不同证书），所以都是可以基于现有的服务来扩展实现的，复用端口。
Let’s Encrypt 最新支持的 IP 地址证书也只支持 HTTP-01 和 TLS-ALPN-01

@jinliming2 HTTP 只需要特定路径返回，TLS 可以在 Client Hello 阶段分流（类似于一个网站针对不同域名使用不同证书），所以都是可以基于现有的服务来扩展实现的，复用端口，不停机实现证书更新的。但具体需不需要停机取决于对应软件实现。

@jinliming2 理解完全正确，再想象一下有一个 agent 运行在服务器上，通过 websocket 和签发服务 connect 。服务中兴发现证书过期时间临近，发起新的证书申请，在告诉 acme （ let's
encrypt ）验证方式之前，先通过 websocket 指挥 agent 启动监听。是不是完全的自动化？

@jianglibo #20 IP 证书是你的 ACME 客户端支不支传入 profile: shortlived 参数的问题，验证 IP 证书其实和域名是一样的。

你用 nginx 之类可能要安装第三方模块，或者自己写一个 nginx lua 的模块来实现这个验证过程。
我现在是把 ACME 验证值放到 redis 中，在 TLS 握手的时候去查询 redis 的值来完成验证。

@jianglibo 一个疑问，逻辑清晰，协议、规则可控，长期来看不存在太大的变动，为什么还要用大模型 Agent ？用扩展性较好的程序实现，成本应该更低，甚至于，稳定性更高

@wintersun 误会，此 Agent 是指一个运行在服务器端的小程序，好多运维系统都需要安装一个 agent 。我的 agent 是一个 c++实现，开源[cert-ctrl]( https://github.com/coderealm-atlas/cert-ctrl). 和大模型无关。

https://github.com/adiudiuu/tools/tree/main/go_acme

这个是我一个项目里面抽出来的用 go 改写的，根据真实业务来申请证书的。希望能帮到你，类似就是用户自己托管域名，只需要把域名解析到我服务器 ip 上，后面的证书都是我这边服务器去申请。

@caola 如果我自己用 acme 还要用你的 cao.la 做什么？我是指你的站点提供的服务看起来好像很难自动化这个过程（没有任何技术层面的评判），仅仅指功能的实现。

@diudiuu 非常感谢。有机会学习一下，我们是用 c++实现的。这是客户端的实现： https://github.com/coderealm-atlas/cert-ctrl

全自动化 https://ssl.dnsjia.com

@jianglibo 不是这样是怎么样？麻烦回一下？如果你的服务器在访问 80 时重定向到 443 ，ACEM 应该怎么反应？

ACME HTTP-01 if server redirect to 443
Thinking
Searching
Yes,
ACME HTTP-01 challenges support redirects from port 80 to port 443 (HTTPS). This is a standard practice that allows you to maintain a secure-by-default configuration whilestill automating certificate renewals.
Key Rules for Redirects

Initial Request: The validation server (e.g., Let's Encrypt) must always start its request on port 80 using HTTP. You cannot skip port 80 and start on 443 for an HTTP-01 challenge.
Supported Ports: The challenge follows redirects only to port 80 or 443. Redirecting to a custom port like 8443 or 10000 will cause the challenge to fail.
Redirect Depth: Most ACME implementations, including Let’s Encrypt, will follow up to 10 redirects deep.
Certificate Validation: When the challenge is redirected to HTTPS (port 443), the CA does not validate the target's SSL certificate. This allows the challenge to succeed even if your current certificate is expired, self-signed, or missing.

服务器不影应 TLS-ALPN-01 ，只返回 HTTP-01 的 challenge 就是外行？？？你那么内行为啥还要问这个问题？显得自己很内行？

@holulu 不要激动，之前已经说的这么清楚了，acme server 会给你一个选择列表，你选择一个比如 http-01 ，那么 acme server 就会用 http-01 来挑战，如果你没准备好 http-01 挑战，端口不通，文件不存在，重定向什么的，那就验证失败啊。 这不是预料中的结果吗？
不懂没关系，但不要这么冲。技术上每个人都有不懂，曲解，这很正常，我们也是在开发这个系统的时候深入了解和阅读 RFC 。如果你是 C++程序员，看 RFC 几乎是习惯，我们的 http 应用服务和 http client 都是按照 RFC 自己写的，当然基于几乎成品的 Boost beast 。RFC 几乎就是 single source of truth.

@caola 我的网站也是有自动化的，就是通过 API 接口，但我这个网站的自动化仅支持 DNS + CNAME ，一次设置 DNS 解析长期有效，不用重复设置。当然如果下半年 DNS-PERSIST-01 验证方式正式推出之后，就推荐你使用 DNS-PERSIST-01 方式验证

以为是个讨论帖，看完发现是个推广贴