如果它是您与提供商集成的官方服务，为了安全起见，您确实应该安装有效的、公开签名的证书。

假设您需要使用自签名证书继续使用您的提供商，那么忽略证书和将其添加为受信任证书之间的最大区别在于以下情况。这将 DNS 中毒作为中间人攻击的一个例子。

举个例子：

• api.example.com有一个带有指纹 XXX 在 IP 上监听的自签名证书5.5.5.5。
• 将其添加到您的信任库会使您的系统在连接时期望指纹为 XXX
• 如果有人能够毒化您的 DNS -api.example.com解决问题6.6.6.6- 指纹将是 YYY。
• 通过将证书添加到您的商店，您的产品将拒绝连接到恶意站点。
• 通过完全禁用检查，您的产品将愉快地连接到恶意api.example.com的6.6.6.6.

通过导入一个已知良好的自签名证书，其中私钥是唯一的且未被泄露，连接与完整的全球 CA PKI 签名证书一样安全。毕竟，它们在某些时候也只是简单地存储和信任。

获得 PKI CA 签名证书的原因之一是实用性而非安全性；如果您必须在许多客户端上信任自签名证书，那可能需要做很多工作。并且进行密钥轮换几乎成倍地增加了这项工作。

如果您控制服务器和客户端，例如在开发过程中，并且您没有设置私有 CA 的技能或资源，那么将特定的自签名证书添加到信任库并不是那么糟糕。接受任何证书都是不好的，永远不要那样做。

如果您忽略证书检查，任何可以在您和其他系统之间获得中间人位置（具有修改流量的能力）的人都可以读取/修改纯文本流量。攻击者将通过使用他的自签名证书启动他自己的 TLS 服务器来破坏 TLS/SSL 隧道，将您的流量路由到它，解密它，并将其代理到真实服务器。有许多工具可以让这种攻击变得非常容易，例如用于 HTTPS的mitmproxy或用于 TLS/SSL 的一般stunnel。

攻击可以通过多种不同方式进入中间人位置。因此，很难完全排除，即使您是网络安全专家，攻击者也无法获得此职位。

如果无法将自签名证书替换为公开签名证书，您可以手动信任自签名证书，方法是将其添加到使用keytool并信任此存储的 Java 密钥库。这有时称为 证书或公钥固定

证书是签名者可以为签名者担保的方式。如果您信任签名者，那么您可以信任证书和签名的公钥。如果您信任签名者，则可以忽略证书。

在更现实的世界中：

示例 1：Cindy 证书颁发机构是众所周知的。每个人都知道辛迪。辛迪在将人们介绍给其他人之前验证他们的真实身份方面享有盛誉。有人自称是 Pablo Pubkey - 一位知名且值得信赖的推销员 - 想向您推销一些东西。Cindy 把你介绍给这个人，并说他是 Pablo。你信任 Cindy，所以你相信这个人就是 Pablo，所以你决定给 Pablo 你的信用卡号码并买东西。

示例 2：您从小就和 Freddy Friend 一起长大。你知道弗雷迪是谁——你在幼儿园遇到他，看到他和你一起长大成人。弗雷迪也是一名推销员。如果你想和弗雷迪谈谈，你就去找弗雷迪——你不需要任何人把你介绍给他。

在第一个示例中，您依靠您信任的证书颁发机构来告诉您谁拥有特定的公钥。在第二个示例中，您直接信任公钥，并且不需要第三方告诉您谁拥有它 - 例如，您的软件可能会向其用户发布公钥并将这些公钥关联到您的软件数据库中。当您拥有自签名证书和未签名证书时，第二个示例完全相同。