SSL-сертификаты с ключом, зашифрованным паролем у хостинг-провайдера

Что бы ни случилось, вам нужно будет расшифровать ключевой файл, чтобы использовать его. Есть несколько вариантов.

1. Расшифруйте ключевой файл и используйте его. Это предлагает постоянный плавный перезапуск ваших сервисов, что вам и нужно. Но тогда ключ будет незащищенным, незашифрованным и хранится на вашем сервере.
2. Сообщите пароли поставщика услуг к вашим сертификатам. Это может быть идеальным вариантом, однако вам нужен уровень гарантии, что услуга воля будет перезапущен с запросом при запуске. Пусть их программное обеспечение для мониторинга предупреждает их об этом событии, однако в этих обстоятельствах вы должны быть открыты для ситуаций, когда ключевой пароль не вводится вовсе или с задержкой ввода пароля поставщиком услуг. Вам решать, на каких условиях поставщик услуг предложит вам эту услугу и какие гарантии успеха они предоставят. Если они это вообще предоставят.
3. Некоторые HTTP-серверы, такие как apache, предоставляют параметр, называемый SSLPassPhraseDialog который попытается расшифровать ключ с помощью написанной программы, которая передаст правильную парольную фразу при выполнении. Это может быть сценарий оболочки или программа по вашему выбору, которая сделает это. Это дает вам возможность выбора № 1, но действует просто как слабый барьер для всех проблем, описанных в варианте № 1. Кроме того, в зависимости от того, насколько осторожно вы (или нет) предоставляете исполняемый файл пароля, это может обеспечить механизм для кто-то получить что-то Другой чем исполняемая фраза-пароль для запуска при запуске.
4. Попросите вашего хостинг-провайдера предоставить запланированное время простоя (если он выполняет перезагрузку), чтобы вы могли быть готовы ввести пароль в себя или изменить обновления для запуска в то время, когда вы можете быть готовы ввести парольную фразу к сертификату незамедлительно.

Мое первое предложение - спросить себя, зачем вам нужно шифровать SSL-сертификат и какие потери это приведет к вашей работе, если служба не работает, скажем, на 2 часа, пока она не будет обнаружена. Каковы потенциальные потери для вас в случае нарушения сертификата и сколько времени потребуется на исправление? Если он стоит дороже, чем сам сертификат SSL, и время восстановления в случае нарушения слишком велико, то, возможно, будет правильным сохранить его в зашифрованном виде.

Откровенно говоря, вы не можете съесть свой торт и съесть его. Если вы хотите зашифровать ключ SSL, вы делаете это за счет нелегальных перезапусков и задержек в работе. Если вы зашифруете его, но предоставите способ автоматизировать расшифровку, это, вероятно, будет столь же бесполезным или потенциально более опасным, чем расшифровка ключа в первую очередь. Если вы возьмете на себя ответственность поставщика VPS, то вы просто перекладываете проблему на них, и это, вероятно, будет стоить вам очень дорого, чтобы дать вам гарантии, которые вы хотите, или вам придется признать, что будут времена, когда поставщик VPS не соответствует вашим ожиданиям, когда они перезагружают VPS.

Мое предложение - производить перезагрузку своевременно и с предупреждением, я не думаю, что было бы неразумно просить об этом вашего VPS-провайдера. Таким образом не должно быть инцидента, который вы хотя бы не можете взять под контроль.

* Проблема использования SSLPassPhraseDialog Это похожая, более распространенная и проблемная ошибка, которую люди совершают при работе с cron. То есть разверните задание cron для запуска от имени пользователя root, а затем сделайте владельцем файлов то, что запускается, пользователю без полномочий root (например, FTP), который потенциально может изменить приложение для повышения привилегий. Если вы пишете программу, которая выводит парольную фразу, сделайте шаги, чтобы убедиться, что файл не читается и не может быть изменен кем-либо, кроме root (это включает в себя обеспечение того, чтобы его родительский каталог, в котором он хранится, не принадлежал кому-либо).