如果您按照您提供的第一个 Wikipedia 链接中的链接进行操作，您会发现Let's Encrypt 将使用的ACME 协议规范。它说的是：

因为有许多不同的方法可以验证拥有不同类型的标识符，服务器将从一组可扩展的挑战中进行选择，这些挑战适合于被声明的标识符。例如，如果客户端请求一个域名，服务器可能会要求客户端以该名称在 DNS 中提供一个记录，或者在该名称下通过 A 或 AAAA 记录在 Web 服务器上提供一个文件引用。

正如 Mike Scott 所说，Let's Encrypt 描述了他们将如何验证证书。

请记住：SSL 颁发实践完全由 CAB 论坛标准化。Let's Encrypt 遵循所有其他 CA 必须遵循的相同规则。他们只是通过命令行进行操作。他们将颁发的证书与其他 CA 提供的“域验证”（DV）证书的颁发实践相匹配。

我认为这个问题存在根本性的误解。HTTPS 不提供可靠的真实性。CA 使用域验证有助于确保证书与域相对应，但是如果您在访问 citti.com 时访问 citti.com，请注意！AFAIK，涉及虚假证书的 MITM 攻击的风险仅限于理论领域，但已经证明了漏洞利用。

为此，创建了扩展价值证书。这个想法是 CA 所有者执行更深入的验证，以确保证书请求来自域的适当授权方。原则上，这提供了特定证书值得信赖的更高保证。当浏览器看到 EV 证书时，它会在地址栏中添加一个带有公司名称的绿色字段。用户应该学会期待这一点，没有它就不会继续。我不相信这已经充分地传达给公众，所以很多潜在的价值没有实现。

必须认识到，EV 证书本质上不是技术控制。它们依赖于用户的知识和行动。从这个意义上说，即使有 EV 证书，HTTPS 也不是可靠的真实性来源，IMO。尽管如此，它具有巨大的价值，并且确实寻找 EV 证书并更喜欢使用它们的网站的用户确实获得了可观的价值。

目前大多数 CA 实践的 TLS 证书问题的真实性非常薄弱。这不是让加密独有的问题。

一些快速的术语

客户端：想要访问网站的用户，其服务器：运行网站或其他服务的机器。

大多数当前的 CA 只要求您能够在与域关联的管理地址接收电子邮件。通常，它们会让您在 whois 的联系地址之一或域中的多个“管理”用户名之一之间进行选择。靠近客户端的 MITM 会对此感到沮丧，但靠近服务器的 MITM（假设 Web 和邮件通常托管在一起）可以简单地 MITM SMTP 会话并为自己获取证书。

Lets encrypt 建议采取稍微不同的方法，lets encrypt 服务器将要求客户端完成“挑战”，要么将特定文件放在服务器的文档根目录中，要么创建特定的 DNS 记录。同样，这将使靠近客户端的 MITM 受挫，但靠近服务器的 MITM 将能够拦截这些请求并获得证书。

到目前为止，这与大多数当前 CA 的（不）安全级别大致相同。

但是根据https://community.letsencrypt.org/t/will-you-allow-overlapping-certificate-requests/135/8。如果存在域的现有证书，用户将被要求证明对它的控制，则将有一个额外的要求。因此（与大多数当前的 CA 不同）靠近服务器的 MITM 可以获得主机名的第一个证书，但他们无法获得已经拥有的域的证书。