Назад | Перейти на главную страницу

Имеет ли значение, где создаются CSR и ключевые файлы для SSL-сертификации?

Мне нужно создать CSR для подстановочного сертификата SSL. В некоторых часто задаваемых вопросах от поставщиков SSL говорится, что я должен создать файл CSR на машине, на которой я хочу установить сертификат? Насколько я понимаю, не имеет значения, где я создаю CSR или ключевой файл, если позже я перемещу файлы в нужное место.

Итак, мой вопрос: имеет ли значение, где создаются CSR и ключевые файлы для сертификации SSL?

Ваше понимание правильное. При прочих равных это не имеет значения; но есть морщинки.

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

Одно из преимуществ создания на отдельной машине: обычно это ваш рабочий стол. Пул энтропии на настольном компьютере почти всегда больше, чем на необслуживаемом сервере, потому что настольный компьютер имеет большой источник случайности, связанный с помощью кабелей клавиатуры и мыши (то есть вы!). Нехватка энтропии может привести к тому, что генерация ключа займет много времени, или заставит его использовать /dev/urandom Вместо этого вывод PRNG, в зависимости от того, насколько параноидален инструмент генерации, и это может привести к более слабым клавишам; настольные компьютеры, как правило, не имеют этой проблемы.

Позже править: в соответствии с обсуждение в другом месте которые связаны здесь, были подняты два момента. Во-первых, вы можете пойти на полпути, создав энтропия на рабочем столе, например, dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, копирование который на удаленный сервер и подавать его в процесс генерации ключей напрямую или путем увеличения пула энтропии удаленного сервера. Я еще не нашел способ сделать первое, а выполнение второго обычно требует наличия привилегий, которые - если канал между вами и удаленным сервером небезопасен, что, скорее, является предметом всего возражения, - также небезопасен.

Во-вторых, достойный mjg59 поднимает вопрос об аппаратных модулях безопасности, то есть устройствах, в которые вы помещаете или внутри которых вы создаете закрытые ключи, и которые затем выполняют ключевые операции, даже не выпуская ключ. Это отличный момент, но он выходит за рамки этого вопроса.

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

Это в некоторой степени имеет значение.

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

Если вы сгенерируете их на защищенном сервере и просто переместите CSR / сертификат, шансы того, что кто-то / что-то получит закрытый ключ, меньше, чем в первом случае, поскольку закрытый ключ находится только на одной машине.