Сертифікати, російськомовна документація по ubuntu

Однією з найбільш поширених форм криптографії сьогодні є криптографія на відкритих ключах. Криптографія на відкритих ключах використовує відкритий (public) і закритий (secret) ключі. Система виконує шифрування з використанням відкритого ключа. Розшифровано така інформація може бути тільки з використанням закритого ключа.

Звичайне використання криптографії на відкритих ключах - шифрування трафіку додатків з використанням з'єднань по протоколах SSL і TLS. Наприклад, настройка Apache для надання HTTPS, протоколу HTTP поверх SSL. Це дозволяє застосувати шифрування трафіку з протоколом, який сам по собі шифрування не підтримує.

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

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

Зверніть увагу, що самоподпісанний сертифікат не може бути використаним в більшості виробничих середовищ.

Продовжуючи приклад з HTTPS, сертифікат, підписаний CA, надає дві важливі властивості на відміну від самоподпісанного сертифіката:

Браузери (зазвичай) автоматично розпізнають такий сертифікат і дозволяють встановлювати захищені з'єднання без попередження користувача.

Коли CA випускає підписаний сертифікат, він гарантує ідентичність організації, яка надає інтернет сторінки браузеру.

Більшість інтернет браузерів і комп'ютерів, які підтримують SSL мають список центрів сертифікації, чиї сертифікати вони автоматично приймають. Якщо браузер зустрічає сертифікат, чий посвідчує центр не потрапив в цей список, він запитує користувача на підтвердження або заборона з'єднання. При цьому інші додатки можуть видавати повідомлення про помилку, коли використовується самоподпісанний сертифікат.

Процес отримання сертифікату з CA досить простий. Короткий огляд його наведено нижче:

Створіть пару з відкритого і закритого ключів.

Створіть запит на сертифікат на основі відкритого ключа. Запит на сертифікат містить інформацію про ваш сервер і керуючої їм компанії.

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

Коли центр переконається, що ви дійсно той, за кого себе видаєте, вони відправлять вам цифровий сертифікат.

Встановіть це сертифікат на ваш захищений сервер і налаштуйте відповідні додатки на його використання.

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

Якщо сертифікат буде використовуватися системними сервісами такими, як Apache, Postfix, Dovecot і т.п. доречно створити ключ без пароля. Відсутність пароля дозволяє сервісу стартувати з мінімальним ручним втручанням, зазвичай це кращий варіант запуску сервісу.

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

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

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

Тепер ви можете ввести вашу кодову фразу. Для кращої безпеки рекомендується використовувати не менше восьми символів. Мінімальна довжина при використанні -des3 - 4 символи. Фраза повинна включати цифри та / або знаки пунктуації та не повинно бути словом зі словника. Також не забувайте, що ваша фраза буде чутлива до регістру.

Повторіть введення для перевірки. У разі коректного введення ключ сервера буде створений і записаний в файл server.key.

Тепер створимо небезпечний ключ, без кодової фрази і поміняємо імена ключів:

Небезпечний ключ тепер називається server.key і ви можете використовувати його для створення CSR без кодової фрази.

Для створення CSR виконайте наступну команду в терміналі:

У вас буде запрошена кодова фраза (при використанні ключа з паролем - прим. Пер.). Якщо введена коректна фраза, у вас запитають назву компанії, ім'я сайту, email та ін. Як тільки ви введете всі ці подробиці, буде створений запит CSR і збережений в файл server.csr.

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

Для створення самоподпісанного сертифіката, запустіть наступну команду в терміналі:

Ця команда попросить вас ввести кодову фразу. Як тільки ви введете коректну фразу, ваш сертифікат буде створений і збережений в файл server.crt.

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

Ви можете встановити файли ключа server.key і сертифіката server.crt (або файл сертифікату, виданий вашим CA), запуском наступних команд в терміналі:

Тепер просто налаштуйте будь-який додаток з можливістю використання криптографії на відкритих ключах для використання цих файлів ключа і сертифіката. Наприклад, Apache може надати HTTPS, Dovecot надає IMAPS і POP3S, і т.д.

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

1. Спочатку створіть каталоги для зберігання сертифіката CA і необхідних файлів:

2. Центр сертифікації вимагає кілька додаткових файлів для своєї роботи; один для зберігання останнього серійного номера, використаного CA, інший для запису які сертифікати були випущені:

3. Третій файл - це файл настройок CA. Хоча він не строго обов'язковий, але дуже зручний для випуску безлічі сертифікатів. Відредагуйте /etc/ssl/openssl.cnf, змінивши секцію [CA_default].

4. Далі створіть самоподпісанний сертифікат:

Вам будуть задані питання по деталях сертифіката.

5. Тепер встановимо кореневий сертифікат і ключ:

6. Тепер ви готові приступити до випуску сертифікатів. Перше, що вам потрібно - запит на сертифікат (CSR). Дивіться деталі в розділі Створення запиту на підпис сертифіката (CSR). Отримавши CSR, введіть наступну команду для створення сертифіката, підписаного нашим центром:

Після введення пароля для ключа CA у вас запитають підтвердження на підпис сертифіката і ще одне на збереження нового сертифіката. Потім ви зможете побачити щось з об'ємним висновком, що відноситься до створення сертифіката.

Наступні сертифікати матимуть імена 02.pem, 03.pem і т.д.

Замініть mail.example.com.crt на ваше власне описову назву.

8. Нарешті, скопіюйте новий сертифікат на комп'ютер, для якого він випущений, і налаштуйте відповідні додатки на його використання. Місце за замовчуванням для установки сертифікатів - каталог / etc / ssl / certs. Це дозволяє багатьом сервісів використовувати один і той же сертифікат без надмірного ускладнення прав доступу до файлу.

Для додатків, які можуть бути налаштовані на використання сертифіката CA, ви можете скопіювати файл /etc/ssl/certs/cacert.pem в каталог / etc / ssl / certs / на кожному сервері.

Для більш детальних інструкцій по використанню криптографії дивіться SSL Certificates HOWTO на tlpd.org.