我的客户正在胖客户端中创建证书，因此最终他使用的是服务器证书和安装应用后创建的单个客户端证书。现在客户端和服务器都验证了彼此的证书。
我被问到iOS和Android应用程序是否可以采用这种方法。我在网上发现的只是服务器始终创建证书，公钥随部署一起部署。
对此有何建议？它会提供额外的安全层吗？
答案 0 :(得分：2)
简单的答案是肯定的，您可以在应用程序中创建一个密钥 - 在Java域中有几个库可以执行此操作，例如，主要基于Java JCE Api标准：
有关如何使用库和提供程序的选项，还有独立的加密库，最着名的是BouncyCastle，它是Android衍生的SpobgyCastle：
这里有一个稍微陈旧但非常好的答案，它提供了Android的良好背景：https://stackoverflow.com/a/9965964/334402
上面的Java Cryptography文档中有一个很好的说明，也是：
警告：JCA可以轻松地将安全功能合并到您的应用程序中。但是，除了对讨论API所必需的概念的基本介绍之外，本文档不涉及安全性/加密理论。本文档也没有涵盖特定算法的优点/缺点，也没有涉及协议设计。密码学是一个高级主题，应该参考一个可靠的，最好是最近的参考，以便充分利用这些工具。
您应该始终了解自己在做什么以及为什么：不要简单地复制随机代码并期望它完全解决您的使用场景。许多应用程序已经部署，包含严重的安全性或性能问题，因为选择了错误的工具或算法。
你会发现这在许多密码学文本中也得到了回应 - 基本上它表明你的安全性只有最薄弱的环节那么强大，并且存在将加密技术添加到应用程序并且认为一切都很好的危险。 / p>
一个易于理解的最薄弱环节的例子是，如果你生成一个非常强大的私钥/公钥对，但是私钥本身的安全性较弱，允许黑客调试你的应用程序来发现它。
答案 1 :(得分：0)
我的客户正在胖客户端中创建证书，因此最终他使用的是服务器证书和安装应用后创建的单个客户端证书。现在客户端和服务器都验证了彼此的证书。
对此有何建议？
您可以使用两种型号中的一种（我知道）。在第一个模型中，组织运行私有PKI，服务器颁发客户端证书。在第二个中，客户发布自己的证书。
对于第一个模型，您应该使用Simple Certificate Enrollment Protocol (SCEP)。它允许用户和设备向组织或服务器注册。组织还可以使用密码保护注册，并在带外发送密码（如电子邮件）。
Peter Gutmann最近接管了RFC draft。我相信微软的电话是别的，他们的服务器叫做NDES server。
对于第二个模型，您应该使用Origin Bound Certificates (OBC)。它们是客户需要时即时创建的“撕下”证书。服务器在首次使用（TOFU）时信任它们。
它会提供额外的安全层吗？
这取决于。我们需要看到威胁模型和现有的安全控制。然后，我们需要确定SCEP或OBC是否会弥补现有控制的额外差距。