好家伙。昨天的帖子激怒了人们。他们中的很多人不喜欢我所说的 ACME 协议。我的印象是其中一些人没有从不同的角度看待需要解决的问题。
我们现在试一试怎么样？让我们先完成让安全网站运行的步骤，暂时忽略协议的细节。
首先，基本假设：有一把钥匙。有一个引用该密钥的证书签名请求。然后是带有签名的证书本身，该签名将其附加到大多数客户广泛接受的“信任网络”（呃……）。好的？
1. 您生成一个密钥。它最终需要安装在网络服务器的某个地方。它只是一团垃圾，用 ASCII 编码，两端都是 — BEGIN/END blah blah — 东西。您可能应该使用特定的算法和特定的复杂性（即位数）来生成它。
2. 您生成 CSR。它需要从该密钥中读取以获取其身份，但 CSR 本身不包含敏感的密钥材料。 CSR 有一堆几乎没人用的字段：国家、组织名称和单位名称、电子邮件地址等等。其中一些曾经在不同的时代意味着什么，但您可能会发现 CA 会忽略所有这些并在生成的证书中完全生成其他内容。恰当的例子：我网站的证书有 CN = rachelbythebay.com，仅此而已。
3. 您通过向 CA 发送 CSR 告诉他们您想要证书。
4. CA 说“好吧，证明你拥有这个域，朋克”，并给你一个或两个 URL，你可以用一些神奇的字符串填充它，以便准确地做到这一点。或者，它会为您提供该域的一些 DNS 条目，您可以使用魔术字符串创建这些条目——可能与 URL 的字符串相同，也可能不是。
5. 你用神奇的数据建立神奇的 URL，或者用神奇的数据放入一个 DNS 条目。
6. 你要么戳 CA 说“好的，去看看”，要么（更有可能）你只是坐在那里感觉很愚蠢，直到他们碰巧重试并注意到。他们通常不会提供太多能够触发这种按需的方式，所以这会给这个过程增加一堆延迟。
7. CA 最终在正确的地方看到了正确的东西，然后说“好吧，这不可能是偶然的，所以他们必须实际控制文档根目录和/或 DNS 或其他任何东西”，这对他们来说就足够了。他们为该密钥和域名颁发证书。 （在过去，他们会开始查看 DUNS 数字和类似的东西，而不是作为验证。）
8. 您回来查看并发现它实际上是可用的。如果它以某种方式戳到你就好了，但很有可能，他们不会，或者至少，他们不会比你检查它的速度更快。您下载的证书是另一个 — BEGIN — … — END — … 一团垃圾。
9. 您在 Web 服务器上安装密钥和证书，然后摆动配置以引用它。
10. 你以任何需要的方式启动网络服务器，让它开始使用新的密钥/证书并停止使用旧的——重新加载、重新启动、重新配置，等等。
11. 您加载站点并验证它是否确实有效，并且它使用的是新证书而不是旧证书。
现在，当您与 CA 交谈时，他们很可能希望您对自己进行身份验证。但是请注意，我从来没有说过你现在应该放弃并开始做你自己的加密（*咳嗽* JWT），以便为某些“声明”生成某种“证据”，让他们相信你实际上是你说你是谁。
您知道，您可以向他们传递一个他们在您登录时发给您的不透明令牌……就像人们多年来一直在使用网络一样。从程序内部调用过 Stripe 吗？您将获得一个 API 密钥。波前怎么样？另一个 API 密钥。甘地？ API 密钥。它在标题中设置。现在他们知道你是谁了。完毕。
当您使用这些术语时，问题就是以他们想要的格式构建请求。它可能是一个 POST，因为理智的人不会只用一个 GET 来创建东西。因此，您向他们发送一些包含 CSR 的表单数据，或者您可能向他们发送一团 JSON，并将您的身份验证令牌粘贴在标头中。这通过 https 传递给他们，因此它与您将使用这些东西做的任何其他事情一样安全。
看看这有多方便？看看滚动自己的加密货币有多邪恶？
这是邪恶的。非常邪恶。不要启用他们愚蠢的身份验证方案，也不要推出自己的加密货币。
不，真的。
自上次 alg=none JWT 漏洞以来多久了？我写这篇文章已经14 天了，现在是 2023 年 1 月。2023 年！
顺便说一句，对于那些说这些协议是“……一个尽可能多地引入‘标准’的机会……”的人来说？你成功了。这就是我在原帖中所说的“web kool-aid”的意思。