Мені потрібно створити КСВ для сертифікату 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-клавіші порушені. Якщо ваша модель загроз відрізняється, слід відповідно адаптувати свою практику.
Це дещо має значення.
Якщо ви генеруєте їх на іншій машині, ключі вразливі на генераторній машині, а потім на сервері. Якщо ви використовуєте заражену машину для їх генерування, деякі virii можуть викрасти ключі, навіть до того, як вони будуть перенесені на захищений сервер.
Якщо ви генеруєте їх на захищеному сервері та просто переміщуєте CSR / cert навколо, шанси, що хтось / щось отримає приватний ключ, менші, ніж у першому випадку, оскільки приватний ключ розташований лише на одній машині.