服务器标识-SSL或；手册；

在我的应用程序中，我想检查连接到的服务器是否可靠。我考虑创建自己的身份检查，在连接时向服务器发送一个随机字符串，而不是使用SSL（这需要支付证书的费用）。服务器将使用硬编码私钥对字符串进行rsa加密，并将结果发送回。然后，客户端应用程序将使用硬编码公钥（它只有公钥，没有私钥）对结果进行解密。如果它发送的字符串与它解密的字符串匹配，则服务器的身份将得到验证，tcp通信将仅使用AES加密（验证服务器身份后，AES密钥将以rsa加密格式传输）

问题:

这种方法可行吗？如果可行，缺点在哪里？ （当然，除了我必须对私钥保密之外）

在这种情况下，将SSL与购买的证书一起使用会有什么好处

在这种情况下，自签名SSL证书也足够了吗？我计划公开这项服务

我想检查我连接的服务器是否可靠

您的方法和使用SSL的方法都不能提供有关服务器的可信任程度的任何信息，但只能提供一种识别服务器的方法，即确保您正在与预期的服务器进行对话。服务器仍然可能被黑客攻击并提供恶意软件，因此您不应该仅仅根据身份就信任它

我考虑创建自己的身份检查，在连接时向服务器发送一个随机字符串。。。rsa加密。。。硬编码私钥。。。硬编码公钥

您实际上是在尝试用证书固定重新发明TLS。TLS并不要求从公共CA处购买证书。只要客户事先（即在连接之前）知道预期的证书或公钥，您就可以简单地创建自签名证书。使用由公共CA签名而不是自签名的证书的要点是，它不能扩展到将世界上的每个证书安装到客户端浏览器/OS中，但可以扩展到安装几个信任锚（根CA）

---

有关如何将TLS与证书/公钥绑定在一起使用的更多信息，请参阅本文档，其中甚至包括各种语言的代码示例

我建议您使用TLS。随着时间的推移，TLS中的错误已经被发现并修复。从你自己的设计开始，假设你不会犯类似的错误，这是一个很大的风险

您可以免费创建自己的服务器证书，尤其是在将服务器公钥嵌入客户端时，因为这样您就不需要依赖公共CA来验证服务器的身份

---

您还引入了一个弱点，即使用私钥进行加密，使用公钥进行解密，这不是RSA的设计目的（公钥用于加密）。另一个很大的风险是，假设这样做很好。

证书的成本可以忽略不计或为零。滚动您自己的解决方案并使其出错的成本可能是巨大的。@EJP我知道您来自哪里。所以最好的办法是让客户端连接到一个重定向到我的服务器的域，然后从服务器端发送该域的证书，对吗？如果是的话，使用自签名证书进行开发是否有好处？当我上线时，从一家值得信赖的公司（如Comodo或Thawte）购买证书？