有两个客户端和一个服务器。每个客户端生成一个 RSA 密钥对并将公钥上传到服务器。服务器将公钥与上传期间指定的用户标识符相关联。
然后客户端 A 需要与客户端 B 共享数据。它向服务器请求客户端 B 的公钥。公钥的指纹呈现给用户进行视觉验证。用户 A 有责任决定她是否信任用户 B 的公钥，反之亦然。
双方用户相互信任对方的公钥后，就可以为对方加密数据。客户端A用客户端B的公钥加密数据，上传到服务器。客户端 B 下载数据并解密。
客户端使用操作系统实现的 TLS 与服务器通信。服务器使用带有 MAC 令牌的 OAuth2 对客户端进行身份验证。
当然，更大的问题是，如果这个系统从这个高度的角度来看已经存在一些安全问题，那么这篇文章的问题是关于证书的。
在这种情况下，当更高的目标是提供端到端加密，并且其中一个决定是让用户验证彼此的公钥时，拥有自签名证书是否有任何好处？公钥？
例如，据说自签名证书保证生成它的人也拥有相应的私钥。当不涉及证书时，客户端 A 使用认为是客户端 B 的公钥但实际上不是公钥的东西加密是否存在安全风险？
一般来说，自签名证书对原始公钥没有提供任何安全优势（可能存在复杂的情况，即自签名提供相应私钥的“拥有证明”，但这很少重要）。不过，自签名证书可以提供可用性优势，因为它允许使用基于证书的软件。
例如，在 Windows 系统中，私钥通常通过相应的证书来引用：用户在“证书存储”中拥有一些证书，每个这样的证书都可以引用相应的私钥。如果要使用.NET 类的CMSSystem.Security.Cryptography.Pkcs.SignedCms格式进行签名，则必须使用“证书”进行签名，因此必须使用看起来像正版 X.509 证书的东西。
这主要相当于重用证书编码格式 (X.509) 来存储公钥。方便的是，这种格式包括人类可读的名称和有效日期；操作系统提供的 GUI 也可用于可视化证书“指纹”，即证书的散列（可用作一种公钥的散列）。不太方便的是，X.509 格式包含一个非可选的签名字段，因此必须有一个至少在表面上看起来像签名的字节序列：使用自签名的习惯由此而来。但是，您也可以存储大约正确大小的随机字节序列，它也可以工作。
为什么在通过 TLS 连接从受信任的服务器获取公钥后尝试验证公钥？
你在混合东西。证书用于将人类可读的名称/组织绑定到其相应的公钥。通常一个公众信任的实体（所有潜在客户都信任）“担保”史密斯先生拥有公钥 XYZ，仅此而已。
在您的情况下，一旦您向您的服务器（即您的真实来源）询问公钥并且一旦获得它，您就需要信任它并使用它来加密。您甚至可以将其安全地存储在本地或缓存它。请记住，这是一个“公共”密钥，因此可以公开。
来自受信任服务器的自签名证书将告诉潜在客户，运行该服务器的组织向任何潜在客户保证 Smith 先生拥有公钥 XYZ。因此，那些真正信任该组织的人可以信任他们的断言和担保。
从编程意义上（即表示 OSI 层及以下），您可以在不处理证书的情况下实现您的目标，除非您必须这样做以便在应用程序层上获得更好的人类可读性。
请记住：运行企业级公钥加密方案不仅仅是加密。您将需要 PKI 和加密密钥机制来轮换、暂停、撤销等可能需要密钥和证书（公共或私有 - 从不自签名）。