这比你想象的要严重，特别是对于像谷歌这样的公司，因为他们经常成为这类恶作剧的目标。但是有几层保障，随着时间的推移，我们的保护越来越好。

您的第一道防线是证书颁发机构。

他们不应该让证书被不当签名。每个 CA 都有自己的机制来验证您是否有权购买给定域的证书，但通常包括让您执行以下一项或多项操作：

• 验证域的 WHOIS 信息中列出的电子邮件地址的所有权。
• 验证遵循域上几种预定模式之一的电子邮件地址的所有权（例如“administrator@{domain}”）
• 在域上创建特定的 DNS 记录
• 对该域托管的网站进行特定更改

但是，随着我们拥有尽可能多的 CA，会发布数量惊人的不适当证书。这是一个“你实际上只有一份工作”的例子，但我们必须接受错误会发生。

创建证书透明度以帮助审核 CA

令人惊讶的是，CA 缺乏问责制和透明度，因此 Google 决定通过Certificate Transparency来解决这个问题。

这是 CA 签署的每个证书的公共日志；如果证书没有出现在日志中，那么它是无效的，并且日志是仅附加的；你不能回去擦洗你的历史。它仍然相对较新，但 Chrome 已经在某些 CA 上需要它，包括所有 EV CA。这个想法是您可以跟踪日志并查看您的域是否在不应该出现的时候出现。工具仍在不断发展以使其更简单，但它是一项非常有前途的技术。

您的最后一道防线是关键固定

更安全的浏览器将允许域所有者将一个或多个公钥“固定”到他们的域。这是整个 PKI 系统的终结，并将信任直接注入浏览器。域所有者可以通过 HTTP 标头告诉浏览器只允许具有特定公钥的证书，并且实际上可以发送预安装在浏览器本身上的断言。这可以防止使用未经授权的证书，即使它具有有效的 CA 签名。

DNSSEC 和 DANE 是这最终要去的地方

大概。使用 DNSSEC，您可以签署您的 DNS 记录，这意味着您可以将您的公钥签名直接放在 DNS 中。这意味着您不需要第三方证书颁发机构来签署您的密钥。这是一个非常优雅的解决方案，但 DNSSEC 仍然有一段路要走；您不能将它与许多操作系统一起使用，而且采用是非常缓慢的。

在有人为给定域名签署证书之前，您需要证明 DNS 所有权。

仅用 Google 的域创建 CSR 是不够的。

如果证书颁发机构实际上为您提供了一个您没有证明其所有权的域的有效证书，那么该 CA 将立即被人们不信任，并且他们的根证书将从信任存储中删除。

理论上，对于当前的证书颁发机构来说，这是可能的。但是有很多保障措施到位。但这已经得到了回答。

但是，对于letsencrypt 证书颁发机构，这是不可能的。因为它使用ACME 协议来证明域名所有权。

基本上，您运行letsencrypt 客户端，该客户端使用ACME 协议与letsencrypt 证书颁发机构的服务器对话，以证明您拥有您声称的域名。一旦证明这一点，您将获得免费且自动的新证书。

简短的回答；是的，它可以工作

鉴于证书的工作方式，如果你能找到一个足够糟糕的 CA，你最终可能会得到一个表明你的 Google.com 的证书。

问题是 CA 应该验证您的身份。这就是他们的全部目的。一个做得不好的人不会存在很长时间。

通常这些不太值得信任的 CA 在信任链中处于第 4 层和第 5 层，通常它们会被迅速识别并从信任链中删除。

也就是说，当只查看证书时，CA 是最后一道防线，所以如果你能找到一个可以证明你是 google.com 而没有经过适当研究的证书，那么你最终会得到一个证明你是 google 的证书.com。（可能又是很短的时间）

需要注意的是，这是一个严重的攻击媒介，对于大型服务器来说也是一个问题。如果您可以通过恶意代码向客户端添加根证书，这也是一种可能（但较少使用）的攻击媒介。

有一些“修复”在进行中，比如 DNSSEC，但在被广泛使用之前还需要一段时间。

今天最好的保护是确保您的客户根证书是健全的，而不是添加它们。