为什么 Chrome 如此讨厌自签名证书？答案

【问题标题】：Why does Chrome hate self-signed certificates so much?为什么 Chrome 如此讨厌自签名证书？
【发布时间】：2015-10-07 21:55:06
【问题描述】：

我正在一个 EC2 实例上运行一个小型 Web 应用程序，我希望一些朋友能够使用它。我还想让它使用 HTTPS，只是为了基本的安全目的（尽可能防止数据包窥探）。当然我使用的是自签名证书，因为我对这个项目的预算是 0 美元。但是 Chrome 在尝试访问它时会弹出一个警告页面：

您的连接不是私密的

攻击者可能试图从 [...] 窃取您的信息（例如，密码、消息或信用卡）。 NET::ERR_CERT_AUTHORITY_INVALID

此服务器无法证明它是 [...]；您的计算机操作系统不信任其安全证书。这可能是由于配置错误或攻击者拦截了您的连接造成的。

“任何加密都比没有加密好”是不是真的？在未加密的 HTTP 上，我也可能试图窃取信息，并且不必证明任何关于我的服务器身份的信息，并且我的通信可以通过数据包嗅探以纯文本形式读取，但 Chrome 不会在那里抛出任何警告标志...

什么给了？为什么 Chrome 如此讨厌自签名证书？为什么它不在挂锁图标上放一个小红框，而不是给我一个双击警告页面？

2021 年 9 月编辑（自 2016 年起适用）：只需接受它并使用免费的密钥发行者之一。 Let's Encrypt 和 AWS ACM 将免费提供。

【问题讨论】：

为什么不在你和你朋友的机器上安装证书？
他无法验证您自行生成的证书是否有效。为了能够验证这一点，您的证书应该位于浏览器信任的信任库中。在其他方面，您的“加密”没有任何成本，因为浏览器无法检查此证书是否为原始证书，而不是被攻击者替换）。尝试阅读有关 MITM 攻击和谷歌的“为什么自签名证书是邪恶的”，以及 https 是如何工作的
见Public Key Infrastructure (Wikipedia)
@Reishin 未加密的 HTTP 连接是否也不容易受到 MITM 攻击...？我的问题不是关于自签名证书是否可以用于验证身份（显然，它们不能），而是它是否应该被认为在任何意义上都比未加密的 HTTP“更安全”。
@Justaskin_ 是的，就像带有自签名证书的 HTTPS。你完全不想听……我会告诉你更多，使用有效 SSL 证书配置不当的 Web 服务器将容易受到攻击，甚至比简单的 HTTP 更糟糕。

标签： amazon-web-services google-chrome security ssl https

【解决方案1】：

因为SSL/TLS试图一次性解决两个问题，而你却完全忽略了其中一个。

SSL 旨在提供加密（在两个端点之间）和身份验证（每个端点正是它所说的那个人） .后一种解决方案通常是通过称为Certificate Authorities (CAs) 的组织来解决的，他们应该在同意给你证书之前验证你的身份。尽管过去这种级别的信任发生了一些惊人的失败，但我们还没有更好的东西，因此浏览器仍然希望看到SSL/TLS 证书由其中一个Trusted authorities 颁发；如果不是，则无法知道您是否真的在与您想要的聚会交谈。

因此，虽然它可能是加密的，但与不应该参与对话的人进行加密对话实际上WORSE比与应该的人进行纯文本对话strong> 参与对话。

有一些免费的SSL 提供商，例如 Let's Encrypt，它们不会导致此警告，并且仍然适合您的 $0 预算。 p>

【讨论】：

> 因此，虽然它可能是加密的，但与不应该参与对话的人进行加密对话实际上比与应该参与对话的人进行明文对话更糟糕。
更新的答案是指 Let's Encrypt 而不是 StartSSL（上次我检查过，它不再是受信任的 CA）

【解决方案2】：

点击的原因是为了防止网络钓鱼攻击。

$0 的解决方法是创建一个证书颁发机构 verified by Justaskin_（这只是一个特殊文件）并让您的朋友安装 public 密钥从他们的计算机上衍生而来。
相反，使用 private 密钥签署您的 https 证书，他们的浏览器将接受它。 OpenSSL 是一种可以做到这一点的工具。

【讨论】：

【解决方案3】：

将chrome://flags/#allow-insecure-localhost 输入Chrome 地址栏，然后选择enabled 选项。

【讨论】：

欢迎来到 Stack Overflow。 Stack Overflow 上不鼓励仅使用代码的答案，因为它们没有解释它是如何解决问题的。请编辑您的答案以解释此命令的作用以及它如何回答问题，以便对其他有类似问题的用户有用。
我们使用ssh 隧道连接到我们拥有和管理的我们自己的 ec2 实例，并在其中运行各种服务。这个答案似乎是避免来自 chrome 的讨厌对话框对 localhost 不满意的最直接方法。

【解决方案4】：

此问题并非特定于 chrome。 Firefox 和可能其他浏览器的行为类似，并且在过去几年中，警告甚至变得更加严格。抱怨这些警告表明更多地缺乏对证书在 HTTPS 中的作用的理解。

使用 HTTPS，人们期望加密，即浏览器和服务器之间的私人通信，没有人嗅探或操纵传输的数据。加密开始时客户端和服务器交换加密密钥，这样一个可以加密数据，另一个可以解密数据。如果某个中间人设法以控制加密密钥的方式操纵密钥交换，那么连接仍然是加密的，但不是私有的。因此，密钥交换受到保护是必不可少的，并且这是通过证书完成的。只有正确检查证书，客户端才能验证它与服务器对话，而不是与中间人对话，因此可以保护关键的密钥交换。

证书通常由以下人员验证

检查信任链，即证书是否由浏览器或操作系统信任的证书机构 (CA) 直接或间接（通过即时证书）颁发。
验证是否为预期的主机名颁发了证书，即主题与主机名匹配。

对于自签名证书或由浏览器/操作系统未知的 CA 颁发的证书，此检查将失败。在这种情况下，不知道原始证书是否已由受信任的 CA 颁发，或者是否有一些中间人在操纵连接。成为中间人并不难，尤其是在公共热点等不受保护的网络中。

因为在这种情况下浏览器无法验证证书，它会抛出一个很大的警告，向用户显示出现严重错误。如果您的朋友知道您那里只有一些自签名证书，他们也应该知道这是浏览器在这种情况下的预期行为。您还应该向他们提供您的证书的指纹，以便他们可以确定这是预期的证书 - 因为没有其他方法可以检查此证书的有效性。请注意，此警告也会出现一次，因为浏览器会保存指纹，从那时起就知道您的站点与此证书相关联。但是如果你更改证书，它会再次抱怨。

如果您不喜欢教所有朋友如何正确验证您的证书的麻烦，那么请为自己申请一个公共 CA 的证书。它们不需要很昂贵，有些还颁发免费证书。

“任何加密都比没有加密好”是不是真的？

虽然糟糕的加密可能比不加密好，但通过加密但中间人连接传输敏感数据肯定比不加密传输非敏感数据更糟糕。与普通 HTTP 不同，您实际上可以使用 HTTPS 检测潜在的中间人攻击。您不能做的是找出这是否是潜在的中间人攻击，或者不可验证的证书是否实际上是预期的，因为浏览器不知道会发生什么。因此，如果浏览器预先知道该站点仅提供自签名证书，则自签名证书实际上并没有那么糟糕。如果传输的数据不敏感，它也可能不坏。但是浏览器应该如何知道需要什么样的数据和什么样的证书呢？

【讨论】：