Original on http://gnomint.sourceforge.net/?q=node/20

Підручник по gnoMint

Давайте уявимо, ви системний адміністратор фірми. Ви найняли два різних сервера для резервного копіювання всіх ваших надлишкових даних, в двох різних і далеких датацентрах. Ваш бос попросить вас налаштувати VPN, так щоб доступ до даних в серверах можна було легко здійснювати. Цей VPN буде використовуватися теж для підключення чотирьох міцних офісів, які розкидані по всій країні.

Ми збираємося створити VPN за допомогою програмного забезпечення OpenVPN, надійну систему, яка використовує SSL для тунелювання комунікації. Ми вважаємо, що всі ваші сервера на Linux. І ви збираєтеся використовувати сертифікати X.509 для аутентифікації віддалених колег, так щоб VPN міг легко рости без особливих проблем. У цьому уроці ми розглянемо, як управляти необхідною інфраструктурою відкритих ключів, використовуючи gnoMint.

Налаштування Вашого CA

Перш за все, Ви повинні встановити Вашу сертифікацію (Certification Authority). Це правда, що OpenVPN несе свої власні скрипти (простий rsa) для створення невеликої CA інфраструктури, що базується на openssl, і, можливо, їх досить для того, що вам потрібно. Але gnoMint дозволяє управляти CA в більш комфортабельною формі, завжди бачачи поточний стан установки. І з gnoMint можна дивитися далі, ніж просто на VPN-орієнтовану CA.

До речі: якщо у вас вже є OpenSSL CA (як ті, зроблені через CA сценарій openssl, в tinyCA, OpenVPN простому RSA ...), ви повинні знати, що gnoMint, починаючи з 0.6.0 версії, може імпортувати їх в базу даних gnoMint.

Перед запуском програми, давайте подумаємо трохи про СА, який ми будемо створювати. У цьому прикладі ми хочемо створити єдиний кореневої центр сертифікації для вашої фірми, тому ми контролюємо всі видані сертифікати тільки однієї бази даних. Цей корінь сертифікації видасть CA-здатні сертифікати, які будуть спеціалізованими (як це рекомендується, що даний CA видає сертифікати з однаковими властивостями).

  • Ми створимо CA другого рівня для ідентифікації системи VPN (в цьому прикладі фірма буде використовувати OpenVPN).
  • Інший вторинний CA для ідентифікації співробітників у фірмі (можливо використовувати для передачі надсекретної інформації через пошту).
  • І ще один для забезпечення підписання (так як Департамент розробки програмного забезпечення хоче підписати всі патчі безпеки, для того щоб вироблене програмне забезпечення можна було оновити тільки з криптографически підписаними патчами).

Створення сертифіката кореневого центру сертифікації

Таким чином, ви встановите останню версію gnoMint (для наступних цим підручником, вона повинна бути, принаймні, 0.5.3 версія). Ви можете завантажити його з SourceForge, Launchpad, або з невеликою кількістю удачі, з вашого улюбленого сховища розподілу. Після його установки, ви можете запустити його за допомогою:

 $ gnomint & 

Головне вікно gnoMint з'явиться, з відкритою базою даних за замовчуванням (~ /.gnomint /default.gnomint):

Опис: http://gnomint.sourceforge.net/?q=system/files/screenshot-gnomint1_0.png

Тепер ми створимо приватний ключ і самоподпісанний сертифікат для CA. Для цього, в меню Сертифікати, виберіть "Додати / Додати самозаверенний CA". Відкриється вікно, що просять у нас дані для нового сертифікату CA.

Window for entering new CA Properties 

Після завершення вихідних даних для CA, натисніть кнопку Далі. На цьому етапі, ми повинні вибрати вид шифрування, який ми будемо використовувати при створенні цієї нової CA. Виберемо RSA (хоча ви можете вибрати DSA, якщо ви віддаєте перевагу). Оскільки ми хочемо, щоб це тривало протягом тривалого часу (20 років), ми будемо вибирати довгий секретний ключ, з бітової довгою 4096, або навіть краще, 5120. За кілька місяців до закінчення кореневого сертифіката буде 20 років: 240 місяців.

Після натискання кнопки ОК, приватний / відкритий ключ кореневої СА і покоління сертифіката буде продовжено. Через деякий час, ви отримаєте такий екран:

Тепер ми створили наш сертифікат кореневого центру сертифікації і закритий ключ. Значок невеликий друку в сертифікаті каже, що сертифікат є сертифікованим (тобто може бути використаний для генерації інших сертифікатів).

Значок кнопки каже, що закритий ключ, відповідний сертифікату, знаходиться в базі даних. Це може бути проблемою безпеки. Будь-яка людина з доступом до копії файлу бази даних gnoMint зможе генерувати сертифікати і підключити свої машини до VPN.

Захист бази даних gnoMint

Для уникнення такої ситуації, gnoMint має дві різні, що не виключають, альтернативи:

  • Ви можете склеїти всі приватні (секретні) ключі в базі даних за допомогою кодової фрази, так що тільки авторизовані користувачі зможуть використовувати закриті ключі в базі даних.

Всі закриті ключі в базі даних будуть шифруватися за допомогою AES 256 алгоритму, в режимі CTR. NSA вважає AES, з довжиною ключа 256, як досить для забезпечення архівування надсекретної документації.

  • Іншою альтернативою є збереження секретного ключа кореневого центру сертифікації в пральний фразі, захищеної зовнішнім файлом. Для підвищення безпеки, цей файл може знаходитися в зовнішньому знімному пристрої, наприклад, як маленький диск USB, який зазвичай зберігається в безпеці і використовується тільки тоді, коли потрібно щось підписати з сертифікатом CA Root.

Незалежно від того, витягли ви особисті ключі на зовнішні файли або пристрої, завжди рекомендується використовувати кодову фразу для захисту бази даних gnoMint, так щоб не було чистих особистих даних в ньому.

У цьому навчальному посібнику, ми виберемо перший варіант один, так як це найпростіший. Натисніть на "Змінити пароль до бази даних", в меню Сертифікати.

Після вибору зробіть захист бази даних СА і закритих ключів з паролями, і, ввівши два рази нову кодову фразу, база даних буде захищена.

Установка правил Root-CA

ОК. Ми маємо сертифікат кореневого СА. Тепер ми збираємося створити свою політику: ми двічі клацаємо по ньому, або після його вибору, вибрати Властивості в меню Правка. На екрані з'явиться вікно властивостей сертифіката. У його третій вкладці ми можемо змінити політику CA.

 

СА Root буде генерувати вторинні сертифікати СА. Таким чином, ми повинні вибрати, в "використанні нових генеруються сертифікатів" розділ "Центр сертифікації" і "покоління CRL".

Крім того, ми хочемо змусити вторинні сертифікати СА належати до фірми. Таким чином, ми форсуємо країну і організацію полів сертифікатів вторинних CА мати однакові значення, як ті в кореневому СА Інші поля матимуть, як значення за замовчуванням, то ж, що і той, в кореневій СА, але це може бути модифіковано згодом.

Крім того, ми встановимо, що ці вторинні сертифікати СА закінчуються через 5 років (60 місяців) після їх створення, і буде так, що розрахунковий час між CRL видачею буде 7 днів (168 годин).

Створення сертифіката запитів на підписи для вторинної сертифікації

Все готово для створення вторинного CA. Для цього, перший крок - це створення їх CRS (запити підпису сертифіката). Ці CRS будуть підписані кореневої СА, відповідно до вторинними сертифікатами СА. В меню Сертифікат ми вибираємо "Додати / Додати запит сертифіката". У новому вікні ми вибираємо успадковувати поля від кореневої СА і натисніть кнопку Далі.

Після цього, ми повинні ввести дані для нового запиту на сертифікат. По-перше, ми будемо збиратися створити CSR для сертифікації, яка випустить сертифікати на системи, які отримали дозвіл на в'їзд в VPN.

Після натискання на кнопку Далі, ми вибираємо властивості шифрування для CSR (тобто, для нового сертифікату). Ми продовжуємо за допомогою RSA, але так, як цей сертифікат закінчується раніше, ми вибираємо тільки 2048 бітів для довжини секретного ключа.

Після цього, якщо база даних захищена паролем, gnoMint питатиме нас пароль бази даних, так як це потрібно для шифрування закритого ключа в CSR перед збереженням в базі даних. Можливо, ви бачили вікно про те, що CRS був створений правильно, але ви не можете побачити його в будь-якому місці. У цьому випадку, перевірте в меню Вид, якщо запити підпису сертифіката перевірені. Якщо немає, то перевірте його, і ... вуаля! Ось воно.

ОК. Ми маємо CSR для першого вторинного СА (пов'язаного з VPN) в базі даних. Тепер ми повторюємо попередні кроки для створення ще двох CSR, одну для співробітників СА, а іншу для програмного забезпечення і його підписання CA. Тепер все CSR для вторинних CA створені.

Підписання CSR для створення сертифікатів

Тепер ми збираємося підписати всі CSR з сертифікатом кореневого центру сертифікації, тому вони стануть нашими вторинними сертифікатами СА.

Так, виберіть один з сертифікатів, і натисніть на пункт меню "сертифікати / підписувати", або натисніть на CSR правою кнопкою миші і виберіть "Підписати" в контекстному меню. З'явиться наступне вікно. Тут ви повинні перевірити, що це правильний CSR.

Після натискання Далі, необхідно вибрати центр сертифікації, який збирається підписати поточний CSR. У нашому випадку, виберіть тільки СА.

Після цього ви зможете вибрати властивості сертифіката. Рекомендується опція настройки всіх властивостей сертифіката за допомогою політики СА, але з цим вікном можна налаштовувати властивості будь-якого конкретного сертифіката (тільки перед створенням його !!).

Слід зазначити, що ви не можете змінити властивості сертифіката таким чином, що не допускається політикою СА. Так, наприклад, якщо політика Кореневий CA допускає тільки сертифікати з Certification Authority і CRL підписання використання, ви не можете активувати використання цифрового підпису в новому сертифікаті, підписаному кореневих CA

Після натискання кнопки ОК додаток буде запитувати пароль DB, оскільки воно повинно отримати доступ до закритого ключа кореневої СА. Після введення його, CSR буде підписаний, і тоді у нас буде наш перший вторинний СА, готовий до дії.

Тепер ми повторюємо останні дії з іншими двома CSR, і тоді ми будемо мати три середніх СA, по одному для кожної мети застосування.

Визначення вторинної політики СА

Тепер ми повинні визначити політику для вторинного СА.

система CA

По-перше, VPN систематизує CA. Сертифікати, створені з цим СА, повинні використовуватися для цифрового підпису, шифрування ключа та узгодження ключів. Його дозволені цілей повинні включати веб-сервер TLS, і веб-клієнт TLS (так як ці біти можуть бути прочитані як "TLS сервера" і "TLS клієнт", без частини "веб").

Як виняток з цього правила, ми хочемо тільки один сертифікат (той, який буде використовуватися в системі сервера VPN) з біт-активним "веб-сервером TLS". Це може бути досягнуто за допомогою ручної деактивації біта в кожному створенні сертифіката або деактивації біта сервера після створення сертифіката на серверній системі. Ми будемо використовувати другий варіант.

співробітники CA

Ми хочемо, щоб співробітники СА видавали сертифікат для кожного працівника фірми. Вони повинні бути в змозі використати ці сертифікати для перевірки достовірності електронної пошти (підписання та шифрування теж), і для веб-аутентифікації (щоб вони могли увійти в інтрамережі фірми автоматично).

Сертифікати, створені з цієї СА повинні використовуватися для цифрового підпису, шифрування ключа та узгодження ключів. Його включені цілі повинні бути веб-клієнт TLS і Захист електронної пошти.

Програмне забезпечення підписання СА

Кожна з груп розвитку матиме свій сертифікат підпису програмного забезпечення, використовуваного для підписання патчів безпеки і нових версій.

Сертифікати, створені з цієї СА повинні бути використані тільки для цифрового підпису. Його єдина мета включає підписи коду.

ОК. Ми готові почати створювати кінцеві сертифікати. Давайте почнемо.

Створення системи сертифікатів

Після того як наші CA налаштовані, спочатку ми створимо сертифікати, відповідні системам в нашій VPN.

VPN буде сформований центральним сервером, який буде прослуховувати вхідні з'єднання від машин, розгорнутих в складі делегацій по всій країні. Отже, ми збираємося створити сертифікат для сервера VPN (в Мадриді, Іспанія), а потім два клієнтських сертифікатів (для делегацій Барселони і Севільї). Таким чином, ми створимо запити підписує сертифіката для трьох VPN вузлів.

Безпечніше наближення б сказало вам, що Барселонська і севільська делегації повинні створити свій власний CSR. З gnoMint це можливо: вони можуть створити CSR за допомогою gnoMint, експортувати його в файл PEM (або створити CSR з будь-якою іншою програмою), а потім відправити його вам по електронній пошті або будь-яким іншим способом. Оскільки CSR не містить ніякої особистої інформації, він може бути направлений по ненадійних каналах.

Давайте припустимо, що це більш безпечно, ніж будь-яка можлива апроксимація, тому що ми єдині працівники в фірмі з технічною підтримкою. Таким чином, три CSR будуть створені нами.

Натисніть на Сертифікати / Додати / Додати запит сертифіката. З'явиться наступне вікно. Ми вибираємо успадковувати властивості від СА Systems, так як це ті, які ми розробили для видачі сертифікатів для VPN вузлів.

CA selection for the new CSRs

Після натискання на кнопку Далі, ми повинні завершити тематику інформації CRS. Хоча це не є обов'язковим, ми повинні заповнити всі поля правильну інформацію.

New CSR subject properties

Після того, як інформація Предмету вірна, натискаємо Далі і вибераем Властивості для відкритої / приватної ключової пари. Ключова довжина 2048 повинна підійти, на даний момент (2008). Пам'ятайте, що, відповідно до прогресією в швидкості процесора, поточні безпечні довжини ключів можуть стати небезпечними в найближчі кілька років.

CSR Key pair properties

Після тиснемо ОК, CRS і відповідний секретний ключ буде створено. Тепер ми повинні повторити цей процес ще раз двічі для створення CSR для барселонській і Севільський делегацій, тому ми закінчуємо з цим екраном.

After creating CSR certificates for VPN nodes

Тепер ми підпишемо CSR для отримання сертифікатів VPNузлов.

(далі буде...)