在服务器端生成私钥（cert）是不是一个好主意？

我正在使用一些encryption项目（使用C＃），有一个任务，我正在考虑如何做好。

我需要客户端为非对称encryption生成私钥，但正如我已经回顾了一些库，它不是这样干净和容易的任务。

为什么？

为了在Windows中生成私钥，我有下面的可能性：

生成他们使用makecert.exe ， pvk2pfx.exe等…但这些工具是从Windows SDK，似乎是他们与其他DLL链接，所以如果客户端有一个干净的操作系统（没有任何安装库），我可能：1 ）。在客户端PC上安装Windows SDK 2）。复制makecert.exe和其他实用程序，并与项目分布（我认为，这是一个坏主意，由于不同的Windows版本（从7到10）和32/64位体系结构
使用Bouncy Castle生成，不坏的方式（也可以使用编程语言而不使用外部工具，这对我来说是一个优势），但C＃版本没有很好的logging，并且在源代码中有一些丑陋的地方
使用OpenSSL ，不喜欢它，因为有几个函数调用库中的错误，本身（与multithreading）
使用PowerShell （也是一个选项，但我想在支持它的老版本的Windows，如7会有问题）

由于这些事实，我想，如果我把客户从私钥中解脱出来怎么办呢？这是一个坏主意吗？我可以在服务器端生成它，不要在它保存私钥，只需通过TLS传输。

哪种安全漏洞存在？考虑一下，使用TLS是STRICT选项。

这取决于你的应用程序。在服务器上生成私钥至少有几个问题。

客户必须相信你以后不保存这个密钥。你知道你不知道，但客户不知道。根据应用程序，这可能是重要的区别。
即使你通过TLS发送密钥，在某些情况下仍然可以被中间人拦截。例如，公司可能会在组织中的每台计算机上安装受信任的根证书，然后拦截并解密出现在该组织中的所有ssl流量。再次，这可能或可能不重要，取决于您的应用程序的类型。

假设您编写面向大量用户的聊天应用程序，并希望加密用户之间的所有消息。然后，如果您将在服务器上生成密钥 – 没有人会（或至少应该）使用您的应用程序。首先，你可以把所有的密钥都存放在政府的\什么（他们不能100％肯定这是不可能发生的），即使你不这样做 – 有整个国家的SSL流量通过使用“假”受信任的根证书。

所以长话短说 – 如果你可以在客户端上生成私钥 – 这样做。在你的情况下，我认为你可以。

取决于多重考虑！

你的用户期望什么？旨在提供“零知识”解决方案（如SpiderOak）的设计可确保即使是具有对服务器的完全管理访问权的人也无法解密您的数据。在这种情况下，在服务器上生成密钥并承诺不存储它并不会削减它：任何具有对服务器的完全管理访问权的人都可能随时破坏这个承诺。所以为了实现真正的零知识，你必须在客户端生成密钥。
你是否愿意接受性能影响？它打开DoS向量？也许因为我是一个安全人员，我绝对不会在服务器上这样做。

如果我是你，我会在客户端追求BouncyCastle。