Удалять пароль из ssl-сертификата - это хорошая практика?

Да, он остановит отправку запросов на терминал при запуске веб-сервера.

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

Будет ли это представлять для вас значительную угрозу безопасности, зависит от того, каковы будут последствия, если это произойдет с вами, и какие выгоды вы получите от этого.

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

Лично я считаю, что хранение расшифрованных копий сертификатов SSL в целом имеет больше плюсов, чем минусов для моей типичной рабочей нагрузки, вот почему;

1. У злоумышленника по-прежнему будет копия сертификата, даже если он был зашифрован, поэтому вы в любом случае обязаны отозвать его.
2. В наши дни злоумышленнику гораздо проще получить действующий сертификат для вашего сайта с помощью социальной инженерии, чем украсть его рабочую копию.
3. Срок действия сертификатов истекает естественным образом, что ограничивает их поверхность для атак.
4. Системы безопасности на основе хоста, такие как традиционные разрешения и SELinux, предлагают надежные средства защиты сертификатов на платформе.
5. Сертификат - это не самое главное в безопасной системе. Необходимо учитывать множество других аспектов, таких как данные, которые вы храните, носители, на которых вы их храните, а также ценность и / или личный характер данных.

Что может заставить меня зашифровать:

1. Если вы использовали сертификат для выполнения взаимной аутентификации.
2. Это подстановочный сертификат или сертификат, на котором размещено несколько доменов (потери удваиваются или утраиваются, или любое другое количество хостов, которое можно использовать для этого)
3. Сертификат универсален и в другом отношении.
4. Целью сертификатов является обеспечение целостности ценных данных (медицинские записи, финансовые операции и т. Д.).
5. Другой конец ожидает высокой степени доверия и / или полагается на целостность вашей системы при принятии операционных решений.

В конечном счете, не полагайтесь на других, которые будут принимать решения по безопасности за вас. Вам необходимо взвесить риски и определить, что лучше для вас и вашего учреждения, используя как можно больше информации.

Он обеспечивает дополнительную безопасность, но на самом деле, если кто-то проник в вашу систему достаточно далеко, чтобы получить доступ к вашему закрытому ключу SSL, у вас, вероятно, возникнут более серьезные проблемы.

С практической точки зрения, действительно ли вы хотите присутствовать при каждом перезапуске apache для ввода пароля?

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

Cient ключи, используемые для входа в систему, должны быть защищены паролем.

Если вы хотите, чтобы службы на основе SSL перезапускались без ручного вмешательства, у вас есть два варианта:

1. Не храните пароль на ключе и защитите его, чтобы к нему могли получить доступ только службы, которым он нужен.
2. Храните пароль в виде обычного текста или его эквивалента на сервере, чтобы службы, которым он нужен, могли предоставить пароль. (Вы можете получить несколько копий пароля в плохо защищенных файлах конфигурации.)

Резервные копии ключа должны быть защищены паролем и защищены, как если бы они не были защищены паролем.