在主机提供商处使用密码encryption密钥的SSL证书

无论发生什么，您都需要解密密钥文件才能使用它。 有几个选项。

1. 解密密钥文件并使用它。 这为您的服务提供永久优雅的重启。 但是，关键是没有保护，未encryption存储在您的服务器上。
2. 将服务提供商密码提供给您的证书。 这可能是理想的，但是您需要一定程度的保证，服务将在启动时通过提示符重新启动。 因为他们可能有他们的监控软件提醒他们这个事件，但是在这种情况下，你应该打开没有input密码密码的情况，或者根本没有input服务提供商的密码。 关于服务提供商为您提供这项服务的条款以及他们将提供什么样的成功保证将由您来协商。 如果他们会提供的话。
3. 一些http服务器（如apache）提供了一个名为SSLPassPhraseDialog的选项，它将尝试使用写入的程序来解密密钥，该程序在执行时会传递正确的密码。 这可以是一个shell脚本或你select的程序来做到这一点。 这有一个好处，就是可以给你一个选项，但是对于选项1中描述的所有问题来说，这只是一个弱点。另外，根据你是否小心地提供一个可执行的密码，这可能提供一个机制有人得到除了密码可执行文件以外的东西在启动时运行。
4. 您的托pipe服务提供商要求他们提供预定的停机时间（如果他们正在重新启动），以便您可以准备好将自己的密码插入到自己的位置，或者在准备好input密码时更改运行的更新到证书及时。

我的第一个build议是问问自己，为什么你需要encryptionSSL证书，以及如果服务停止运行，例如 – 2小时，直到它被发现，这会对你的操作产生什么样的损失。 如果证书被破坏，那么你可能会遭受什么样的损失？需要多长时间才能纠正？ 如果它本身比SSL证书本身花费更多，并且在违规事件发生时恢复的时间太长，那么保留encryption也许是正确的。

说实话，你不能吃你的蛋糕。 如果要encryptionSSL密钥，则需要花费非正常的重新启动和延迟操作。 如果你对它进行了encryption，但提供了一种自动解密的方法，那么它可能与将密钥解密放在首位一样无用，或者可能更危险。 如果你让你的VPS供应商承担责任，那么你只需将问题转移到他们身上，这可能要么花费你很多，给你你想要的保证，否则你将不得不接受VPS提供商当他们重新启动VPS时不符合您的期望。

我的build议是及时进行重新启动，并预先警告，我不认为向您的VPS提供商提供这个服务是不合理的。 那样的话，不应该有一个事情，至less不能放在一定的控制之下。

*使用SSLPassPhraseDialog的问题是一个类似的，更常见的和有问题的人犯 cron作业的错误。 也就是说，部署cronjob以root身份运行，然后使文件拥有运行非root（即FTP）用户的文件，这些用户可能会修改应用程序以升级权限。 如果你编写一个程序来吐出口令，就要确保文件不易读取，而且文件可以用除root以外的任何东西来修改（这包括确保其父目录不被其他人拥有）。