“替代方案”取决于您是否想要在未来可以使用的东西，或者现在可以在现有浏览器中使用的东西。

目前，Web 浏览器期望服务器发送X.509 证书，然后根据集成在浏览器（或操作系统）中的一组根 CA 来验证它们。这意味着，如果您想要无需任何额外软件安装即可工作的东西，那么您所能做的就是更改根 CA（您的信任锚）集。你可以：

• 删除一些 CA（据说您可以删除其中的大部分而不会真正影响您的浏览体验，因为并非所有受信任的 CA 都同样活跃）。
• 添加新的信任锚。请注意，信任锚是“您先验地信任的名称和公钥”。信任锚通常被编码为证书（因为格式方便），并且传统上是自签名的（主要是因为在证书中，有一个不能留空的“签名”字段）。但是您可以信任非自签名的证书；您甚至可以信任最终实体证书（即您信任给定 SSL 服务器的特定证书：这称为直接信任）。通过直接信任，您可以以非常精细的粒度手动管理您信任的内容。请注意，通过直接信任，您将失去撤销的好处 （除非您手动干预，否则直接受信任的证书不能不受信任，而撤销是关于自动传播不信任信息）。

（可以注意到，直接信任模型正是 SSH 所遵循的，它在 SSH 的使用上下文中运行良好。）

将来，可能会有其他模型。有几个提议，其中一些得到现有软件附加组件的支持。据我所知，还没有一个达到“普遍可用”的水平。有，例如：

• DNSSEC 和 DANE：DNSSEC 是关于在 DNS 系统上映射PKI，主要是为了验证 DNS 本身返回的数据，但这可以用来分发 SSL 服务器密钥（DANE 是关于什么的）。这仍然是一个分层的 PKI，具有一组有限的信任锚；与现有根 CA 集的区别主要在于参与者的变化：新的看门人集会更小，并且仅与现有根 CA 部分重叠。此外，DNSSEC/DANE 将验证 Web 服务器的过程绑定到 DNS 基础设施和参与者，目前尚不清楚这是好是坏。

• 一个信任的网络状的OpenPGP一样。WoT 模型依赖于图的超连接性。为简单起见，在 WoT 中，每个人都是 CA，每个参与者都是自己独特的根 CA；为了应对易受骗或完全恶意的“CA”，WoT 用户（即 Web 浏览器）只有在他们可以通过许多经过不同 CA 的路径验证目标证书并且都同意设置目标服务器密钥的情况下才接受目标证书为有效。WoT 的去中心化性质在不信任政府和任何看起来像政府的事物的人中非常受欢迎。然而，WoT 的安全性非常依赖于临界质量：除非有足够多的人合作，否则它不会给你太多。查看Monkeysphere 项目 用于实现（使用浏览器插件）（不过，我对项目质量知之甚少）。

• Convergence是Perspectives 项目的后代。如果你认真对待，收敛依赖于希望和懒惰。Convergence 的假设是，想要成为攻击者的攻击者会发现在很长一段时间内以及在许多人看来，用假证书主动冒充给定服务器太困难/昂贵/令人厌烦。即，实际的中间人攻击要么靠近受害者（例如，给定 WiFi 热点的用户），在这种情况下，它们只会影响极少数人，要么靠近服务器，这需要大规模的东西（如严重的 DNS 中毒），这将非常明显，因此不会持续很长时间。在这种模式下，Convergence 是一个不错的、相对便宜的解决方案，只需要很少的中心化（它仍然需要公证人，并且可以预期事实上的中心化，但不如当前的根 CA 集那么彻底）。

重要的一点是当前系统“有效”。针对 PKI 的实际攻击非常罕见（广为宣传，但仍然很少见）。具有根 CA 的实际系统很难破解，攻击者发现通过其他一些方式更容易绕过它（其中最重要的是滥用人类用户的轻信）。因此，几乎没有动机用另一个系统替换它，充其量只能做同样的事情。因此，虽然替代提案有一些优点（主要是在财务和政治方面），但我认为它们中的任何一个都不太可能在不久的将来取代现有的根 CA，因为我们所知道的“网络”。

对于不是 Web 的封闭体系结构，并且您可以同时控制客户端和服务器，您可以使用任何您想要的系统，但封闭体系结构正是分层 PKI 工作得很好的情况。

一种替代方法是DANE/TLSA，它是一种 RFC 标准，允许在 DNS 中使用自签名密钥。

挑战之一是这是非常新的，大多数客户端软件还不支持它。（Chrome 是新添加的）此外，DNS 会受到各种攻击，尤其是在 WiFi 网络等上。

补救 DNS 攻击的一种方法是使用 DNSSec，并确保客户端软件仅将 DNSSec 用于提供它的域。如果后一个功能不存在，那么这将使用户面临 SSL-strip 类型的漏洞。

SSL 还支持安全远程密码 (SRP)。这是您使用密码而不是证书进行身份验证的地方。可惜浏览器不支持。

还有收敛，它是 CA/PKI 系统的替代品。从理论上讲，您可以使用自签名证书并仍然保护自己免受 MITM 攻击。它还提供针对流氓 CA 的保护。

值得指出的是，如果以与我们当前的 PKI 相同的规模实施，信任链概念本身并不比信任网络、共享秘密或任何其他机制更容易受到攻击。

主要问题是受信任的 CA 的扩散以及出于信任目的缺乏 CA 之间的区别。对于特定于应用程序的用例（即不是 Web 浏览器），您可以解决此问题并创建一个非常可靠且非常值得信赖的私有 PKI。由于 SSL/TLS 实现允许您指定自己的信任根，因此没有理由必须包含 Mozilla 和 Microsoft 提供的流行 CA 列表。实际上，如果您不使用浏览器，那么您应该包含全局 CA 列表的理由很少，而您不应该包含的理由也很多。如果您是唯一的 CA，那么您的攻击面就会受到很大限制（正如 Microsoft 最近了解到的那样）。

对于浏览器 PKI，更理想的解决方案是按信任类别（例如*.bank，金融机构等）创建分段的 TLD ，最重要的是，将 CA 权限限制为仅给定的 TLD。这样一来，香港邮政局就不能再为 Paypal 或 Google 签名了。

但是，由于当前的技术已被大众使用有效地固定下来，因此这种或任何其他替代安全基础设施成为主流的机会实际上为零。