我今天正在轮换我的AWS X.509证书和私钥（不要与ssh私钥/公钥对混淆），并决定我想在我的私钥上设置一个密码短语以更好地保护它。 所以我做了一些研究，跑了：
openssl rsa -in awsprivatekey.pem -des3 -out awsprivatekey.pem.new 并input了私钥的密码。 在我尝试使用ec2 api工具后，出现错误：
java.io.IOException: DER length more than 4 bytes
当我研究这个话题时，这变得很明显，发现这个链接ec2 api工具不支持带密码的私钥
我对缺乏这方面的信息感到困惑，以及拥有像Amazon EC2一样至关重要的不受保护的私钥的现状。
有关如何更好地保护我的私钥的任何build议？
我一直在做同样的尽职调查，我也担心所有的客户端工具和文档似乎都在促进糟糕的安全最佳实践。 我回答了这个问题：“你真的想为你进入的每一个命令重新input密码吗？” – 是的，或者至less我很高兴有一个像ssh-agent这样的工具为我input。 我从来不想在我的文件系统中find任何私人密钥或通过在平面文本中的短语。 我很惊讶，标准的响应只是“encryption你的整个文件系统”。
即使我装入并encryption一个.ec2目录，并将所有内容隐藏起来，我仍然要小心，不要按照我的bash_profile脚本中的build议将我的密钥设置为环境variables的文档。 所以，也许我只是把它放在我的.ec2目录下的一个脚本中，然后通过命令行传递给它 – 哦，等等，现在我的密码正在我的历史logging中（我仍然不能相信os x不够好跳过存储以空格为前缀的行）。 所以真的我需要encryption我的整个用户目录只是为了安全。 为什么使用x.509证书的不对称过程被弃用，取而代之的是“密钥”authentication过程？ 至less前者允许我将私钥存储在一个文件中 – 后者要求我把它作为一个parameter passing出来（它的价值已经遍布我的历史和脚本）。
问题是这些安全协议有很多，但没有人想花时间去理解它们。 相反，他们只是想让事情发挥作用，因此他们盲目地遵循一些一步一步的文档，这是由一些盲目跟随别人的逐步文档的人写的。 没有人质疑这一点，因为他们不明白，他们只是想要它的工作。 其结果是非常糟糕的安全措施泛滥。
保持在TrueCryptencryption磁盘上。 在你不需要它们的时候，它们将被安全地存储起来，只有当你真正需要使用它们时，才会安装它。 TrueCrypt创build一个文件，然后将其作为虚拟磁盘装入。
编辑：如果你需要在一个不是交互式的代码中保护它，你可以明显地encryption私钥并解密你的应用程序代码。 有大量的样本如何用Java解密文件 。