购买代码签名证书时，从 PKCS12 开始与 JKS 证书相比有何优点？一些vendors http://help.godaddy.com/article/4780提供有关从 JKS 或 PKCS12 证书签名请求开始的说明。我们希望在使用购买的证书时拥有最大的灵活性，特别是考虑到成本。例如，我们可能不仅仅签署 Java 代码（例如：iPhone 或 Android 代码签名）。选择任一方法时我们应该考虑哪些技术因素？
如果您使用 Java 工作，那么 Java 密钥存储是存储私钥的一个相当自然的地方。Java 应用程序通常希望从 JKS 获取所需的密钥，并且可以从您自己的 Java 应用程序轻松访问。不过，JKS 无法从 Java 外部访问（无需跳过一些环节）。
另一方面，PKCS#12（又名 PFX）文件是一种与语言无关的存储加密私钥和证书的方式，并且已经存在了足够长的时间，几乎所有地方都支持它。但请注意，该文件格式过于复杂且过于笼统——请参阅 Peter Gutmann 的“PFX - 如何不设计加密协议/标准”（http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html）以轻松的态度看待问题。
请注意，使用这些存储格式中的一种或另一种实际上是一个关于应用程序如何在本地存储加密私钥的问题。向您出售证书的供应商永远不会看到私钥，因此他不在乎您使用什么格式。您向他（供应商/CA）发送 PKCS#10 证书请求（包含公钥并使用私钥签名，但不包含私钥），他向您发回证书（您可以将其存储在 JKS 或PKCS#12 文件或两者，或您喜欢的任何其他文件）。
从技术上讲，这两种格式都不是理想的，因为它们都通过使用从密码派生的密钥对其进行加密来保护私钥。但这并不意味着其中任何一个都比另一个更好。如果您可以使用智能卡或其他硬件密钥存储解决方案，则安全性（尽管不方便）会更好。
决定您选择的主要因素应该是您计划如何使用私钥，即：哪些应用程序需要使用私钥以及它们已经处理什么格式的密钥存储。 PKCS#12 是更灵活的选项...但如果您打算仅将密钥与您自己编写的代码一起使用（不需要互操作性），那么您也可以考虑使用 PKCS#8 或 PKCS#15 容器。
我不建议您编写自己的代码来处理 PKCS#12（我已经这样做了，但不好玩）——使用经过验证的第三方库（如 OpenSSL）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
