风险在于客户。SSL 服务器证书的重点是客户端使用它来了解服务器公钥，并在一定程度上保证该密钥确实属于预期的服务器。保证来自 CA：CA 应该在颁发证书之前对请求者身份进行广泛的验证。

当客户端（用户和他的 Web 浏览器）“接受”不是由客户端信任的 CA（Microsoft 嵌入到 Windows 中的 CA）之一颁发的证书时，风险是客户端是当前正在与假服务器交谈，即受到攻击。请注意，无论 CA 证书是否由主流 CA 颁发，SSL 都会阻止被动攻击（攻击者观察数据但不以任何方式更改数据）。

一般来说，您不希望训练您的用户忽略来自浏览器的可怕安全警告，因为这会使他们容易受到此类服务器模拟攻击（安装起来并不难，例如DNS 中毒）。另一方面，如果您可以通过其他方式确认该证书是真实的，那么浏览器将记住该证书，并且只要使用相同的自签名证书，就不会在后续访问时显示警告. 新提出的融合PKI 是这一原则的延伸。请注意，只要证书未更改，此“记住的证书”就有效，因此您确实希望将自签名证书的到期日期设置在遥远的将来（但如果您想避免互操作性问题，则不要超过 2038 年）。

需要注意的是，由于自签名证书不是由 CA“管理”的，因此不可能撤销。如果攻击者窃取了您的私钥，您将永久丢失，而 CA 颁发的证书仍然具有理论上的吊销安全网（CA 声明给定证书已失效的一种方式）。实际上，当前的 Web 浏览器无论如何都不检查吊销状态。

从接受的答案：

请注意，无论 CA 证书是否由主流 CA 颁发，SSL 都会阻止被动攻击（攻击者观察数据但不以任何方式更改数据）。

不对。

因为互联网的工作原理是将数据从路由器传递到路由器，直到您的数据到达目的地。中间的每个路由器都是该路由器上的恶意代码重写数据包的机会，除非您有某种方法来验证数据包是否来自受信任的服务器，否则您永远不会知道其中的区别。

如果您拥有正确的密钥，加密密钥可以为您验证数据未被篡改。然而，问题是，在您开始加密通信之前，您必须进行未加密的密钥交换，服务器会在其中为您提供它的加密密钥。这就是中间人有机会的地方。如果您的流量通过我的路由器，我可以拦截来自服务器的自签名密钥，并在其中生成一个具有相同服务器名称等的新自签名密钥，使其看起来像来自的自签名密钥你的服务器，但它允许我解密你和服务器之间的通信。然后我的路由器使用正确的建立与服务器的连接密钥，当数据在您和服务器之间传递时，我使用真实密钥解密数据，然后使用“假”密钥重新加密。所以，数据在我和服务器之间以及我和你之间是加密的，但在我的路由器中是未加密的，这让我有机会监视你的数据，或者如果我愿意的话甚至可以更改。

参考

所以基本上......使用自签名证书是完全不安全的，除非

• 你控制你和服务器之间的每一台机器
• 或者您检查证书中的密钥是否符合您的预期。