这个服务器 支持标准的 ACME 协议吗

[Neilpang]

貌似并不是标准的ACME 协议. csrEager 是专属的.

目前只能和自己的 client 通信吗: https://github.com/digitalsign/acme-client

如果只能和自己的专属 client 通信, 又何必包 ACME 协议呢. 不如直接把官方的api 包一个 cli 就好了.

目前这样既包服务器 又包 client 岂不是增加了用户使用难度, 却无法利用 ACME 的好处?

[Neilpang]

理解, 如果你无法改变 ca 验证的流程, 那其实不必要包 ACME 协议. 完全可以包一个 api 的cli 就可以了啊.

[xiaohuilam]

理解, 如果你无法改变 ca 验证的流程, 那其实不必要包 ACME 协议. 完全可以包一个 api 的cli 就可以了啊.

刚刚前面那个回复在手机端不小心误删了. 此处赘述一遍:

因为 let's encrypt 是先下单, DCV 后再提交 csr: Why ACME requires domain auth first before CSR? 而大多数 CA 是不支持 csr last 的. 所以就加了 csrEager 属性

然后回复你第二条疑问

这个项目的本意是想 fork 一份 rfc8555, 增加 csrEager 支持(其实这个 fork 还是有意义的: 方便 CA 不用大改验证流程选择 csr first 或者 csr last 最适合自己的方案来提供 ACME 的接口), 后面在 pull request 回去. 现在好像 rfc8555 封版, 只可以在下一次 rfc 之前再 pr 了.

[Neilpang]

明白你的意思. rfc 已经完成了, 再做这种大修改已经不可能了. 不过 rfc 的 maillist 里面很多都是现在 CA 的成员. 他们当时没有反对.

而且我看论坛上的回复也很有道理. 要从认证过程一开始就缓存一个完整CSR 是很浪费资源的. CSR 本身可能很大, 高达几K 甚至10几k. 因为ACME 用户可能很多, 对于CA 的运维方面, 可能在多个数据中心同步巨大的 CSR 是一个不小的挑战. 所以我觉得他们说的有道理. 尽量减少CA 服务端的负担. 现在 Letencrypt 每天可能要处理百万级别以上的请求, 减少CA的负担很重要.

所以我觉得你这个 PR 能提交到下一次 rfc 比较困难.

不过也可能是另外一种选择.

如果现阶段从更有利于你们的推广方式, 我觉得更低成本的方法可能是包一个你们api 的 cli , 让人更容易上手. 相信会有利于你们的发展.

谢谢.