Возможно, он еще не получил никаких ответов, потому что это сложная проблема, и нет единого правильного ответа.
Ключевой доступ для серверов сводится к компромиссу между посещаемым и автоматическим запуском. Вам может потребоваться взаимодействие с администратором (например, зашифровать файл закрытого ключа и ввести пароль при запуске вручную); это защищает ключ в покое (на диске) от воздействия, но предотвращает автоматический запуск. Или вы можете сделать доступным ключ-покой для сервера, что позволяет запускать его автоматически, но это может подвергнуть его злоумышленникам.
Таким образом, гигиена в состоянии покоя должна отражать вашу модель угроз. Стоит ли тратить деньги (время, неудобства, задержка запуска) на взаимодействие? Или риск раскрытия ключа (вероятность того, что это произойдет в разы дороже для вас) достаточно низок, чтобы вы могли разрешить автоматический запуск?
Предполагая, что вы продолжаете держать закрытый ключ сервера доступным для автоматического запуска (т. Е. Для чтения сервером без вмешательства администратора), вот несколько соображений:
Получить корневой ключ там. Ключи CA не должны храниться в системах, подверженных воздействию внешнего мира. В данном случае это ваш собственный CA, а не публичный, но это базовая гигиена ключей PKIX.
Вероятно, нет никакой дополнительной информации о наличии ключа сервера в двух формах, но в этом нет и никакого преимущества. Избавьтесь от server.key.
Этот каталог может также принадлежать root.http и иметь значение 750 (доступный для записи в корневой каталог, доступный для чтения http-группы, без мировых разрешений). Наиболее вероятные векторы атаки - через HTTP-сервер, но есть и другие; может также отговорить некоторых из них, блокируя чтение / обход мира.
Относительно вашего последнего вопроса: я никогда не использовал lighttpd, но некоторые серверы поддерживают процесс ввода ключей, при котором сервер читает ключ при запуске, а затем отбрасывает разрешения таким образом, чтобы он впоследствии не мог его прочитать. Например, сервер может запускаться с правами суперпользователя (как это должно быть в UNIX / Linux, если он хочет привязаться к портам 80 и 443), затем читает файл ключа, а затем выполняет setuid для http (или любого другого). Другие могут иметь возможность для чтения ключа из канала или аналогичного.
С помощью lighttpd также возможно, чтобы он считывал ключ из временной копии, которую процедура запуска удаляет после запуска сервера.
Однако первая линия защиты заключается в том, чтобы удостовериться, что каталог, содержащий файл ключа, недоступен через какой-либо из корневых сетей, и приложить все усилия, чтобы избежать уязвимостей при обходе пути во всем, что обслуживает сервер. И блокировка ОС в целом.
Мне нравится книга Ивана Ристича по пуленепробиваемым SSL и TLS, доступная на feistyduck.com, за советы по использованию SSL / TLS в целом и с HTTPS в частности. Для веб-серверов он в первую очередь обсуждает Apache, но большая часть материала широко применима.
Я надеюсь, что это полезно.