Часто використовувані скорочення
SSL - рівень захищених сокетів (secure socket layer);
CA - засвідчує центр (center of authority);
CSR - запит на сертифікацію (certificate signing request);
CRL - список відкликаних сертифікатів (certificate revocation list);
PKCS - криптографічні стандарти з відкритим ключем (public-key cryptography standards).
Призначення SSL-сертифікатів
Після створення власного CA всередині компанії з'явиться єдиний центр, підпис якого на сертифікаті буде мати ту ж силу, що і підпис VeriSign, але в масштабах компанії. Для цього достатньо поширити на всі комп'ютери і мобільні пристрої власний сертифікат «рідного» CA, оголосивши його кореневим, і всі ключі, які були або будуть в майбутньому підписані ним, автоматично стануть «безпечними», оскільки їх приналежність може бути перевірена. Це також дасть можливість створювати списки відкликаних сертифікатів, які будуть автоматично перевірятися при встановленні захищеного з'єднання.
VeriSign власного виготовлення
У загальному випадку процедура виглядає так: клієнт, який бажає отримати сертифікат, генерує CSR (при цьому також створюється ключ сертифіката) і відправляє CSR в CA. СА отримує CSR, підписує його і створює власне сертифікат, який відправляється назад клієнту. Можливий і інший варіант: клієнтові відразу генерується ключ сертифіката, сертифікат, і все це разом з сертифікатом СА упаковується в файл формату PKCS # 12 (розширення .p12), захищається паролем і відправляється клієнту.
При створенні власного СА потрібно створити структуру каталогів для зберігання таких даних:
- прийняті запити на сертифікацію (CSR);
- підписані сертифікати (CRT);
- список відкликаних сертифікатів (CRL);
- закритий ключ власного сертифіката CA.
У лістингу 1 показана структура каталогів, створена модулем apache1 mod_ssl, але можна використовувати і довільні назви.
Лістинг 1. Створення каталогів для СА
Після створення необхідних каталогів потрібно внести зміни в конфігураційний файл OpenSSL. У лістингу 2 показані три фрагмента файлу openssl.cnf: стандартний CA_default і два доданих розділу ssl_server і ssl_client.
Лістинг 2. Фрагменти конфігураційного файлу openssl.cnf
У лістингу 2, крім установки шляхів за замовчуванням, додаються дві нові секції - [ssl_server] і [ssl_client]. де вказуються параметри сертифіката в залежності від режиму роботи програми, яка буде його використовувати. Web-сервера і поштові сервера припускають наявність серверного сертифіката, а клієнти електронної пошти - навпаки, клієнтського.
Установка параметрів в секціях [ssl_server] і [ssl_client] проводиться відповідно до man x509v3_config. При використанні параметра crlDistributionPoints його значення повинно містити загальнодоступну посилання на CRL даного CA. CRL буде використовуватися програмами, що мають таку можливість (наприклад, Web-браузерами) для перевірки списку відкликаних сертифікатів, і при спробі використання відкликаного сертифіката з'єднання встановлено не буде, замість цього буде видано повідомлення про помилку.
У лістингу 2 ім'я файлу з сертифікатом СА - caserv.crt. ім'я файлу з ключем сертифікату СА - caserv.key і ім'я файлу з CRL - cacrl.pem. Програми, які не вміють використовувати файл CRL, використовують так званий файл MCF (merged control file - об'єднаний контрольний файл), що представляє собою просто йдуть підряд сертифікат і CRL для даного CA. MCF-файл створюється командою cat. як показано нижче:
Після внесення змін до конфігураційний файл необхідно створити головний сертифікат CA, яким будуть підписуватися всі інші сертифікати. Процес створення показаний в лістингу 3:
Лістинг 3. Створення головного сертифікату СА
Після створення файл caserv.key слід помістити в каталог ssl.key. встановити повноваження 0400 і захистити його від несанкціонованого доступу. Файл caserv.crt. навпаки, слід зробити загальнодоступним і встановити в якості кореневого сертифіката на всі пристрої, які будуть звертатися до ресурсів корпоративної мережі.
Також буде потрібно створити індексний файл бази даних з підписаними сертифікатами (назва цього файлу задається в параметрі database секції [CA_default]) і файл з поточним серійним номером (назва цього файлу задається в параметрі serial секції [CA_default]). У лістингу 4 показані команди для створення двох цих файлів.
Лістинг 4. Створення індексного файлу та файлу поточного серійного номера СА
Після цих дій створений CA готовий до підписання сертифікатів.
створення сертифікатів
Перший спосіб створення сертифіката використовується, коли є можливість створити CSR безпосередньо на машині клієнта - це, як правило, комп'ютери під управлінням UNIX або Linux. У лістингу 5 наведені команди для створення CSR.
Лістинг 5. Створення CSR безпосередньо на клієнтському комп'ютері
У лістингу 5 створюється новий CSR, який буде записаний у файл myfile.pem. і RSA-ключ сертифіката, довжиною 1024 біта. Контрольна сума CSR розраховується із застосуванням алгоритму SHA1. Найбільш значущим параметром є параметр -nodes. що означає, що ключ не буде захищатися паролем (сертифікати серверів зазвичай завантажуються при запуску відповідних програм, а запит пароля може зупинити процес запуску). Під час створення CSR буде задано безліч запитань, відповіді на які будуть занесені в CSR і згодом використовуватися.
Згенерований CSR-файл myfile.pem необхідно передати на сервер, де встановлений СА, і помістити в підкаталог ssl.csr. Після цього можна виконати підписання сертифіката, як показано в лістингу 6.
Лістинг 6. Підпис клієнтського сертифіката клієнта у власному СА
Для сертифіката сервера в параметрі -extensions вказується ім'я секції ssl_server. а для сертифіката клієнта - ssl_client. Створюється відразу два варіанти сертифіката: з текстовою частиною - myfile.pem і без текстової частини - myfile.crt. при цьому сертифікат в одному форматі можна перевести в інший формат. Для підписання сертифіката потрібно ввести пароль від головного СЕРТФІКАТА СА. Після підписання будь-який готовий сертифікат (або обидва) можна відправити назад клієнту для використання в програмах.
Другий спосіб створення сертифікатів використовується тоді, коли створити CSR безпосередньо на клієнтському комп'ютері неможливо (НЕ-UNIX системи, мобільні пристрої, різноманітне мережеве обладнання). У цьому випадку на комп'ютері з встановленим СА створюється CSR, і підписується сертифікат (команди створення CSR та підписи сертифіката ідентичні наведеним вище, тільки в параметрі -extensions використовується ім'я секції ssl_client). Після створення сертифіката все створені файли плюс сертифікат самого СА збираються в архів формату PKCS # 12 і передаються клієнту. Це найвразливіше з точки зору безпеки місце: передається сертифікат разом з ключем, а захищений архів тільки паролем! Команда для створення архіву PKCS # 12 приведена в лістингу 7:
Лістинг 7. Створення архіву PKCS # 12
У лістингу 7 створюється архів myfile.p12 c паролем 123456. містить сертифікат myfile.crt. ключ сертифіката myfile.key і ключ СА caserv.crt. Цей архів передається клієнту і встановлюється засобами ОС клієнта.
Відгук сертифікатів. Списки відкликаних сертифікатів
Необхідно врахувати, що сама по собі операція відкликання не створює і не оновлює цей список, так як вона тільки робить необхідні операції в індексному файлі, вказаному в параметрі database секції CA_default. А для оновлення списку буде потрібно виконати окреме дію. Скасування сертифіката виконується способом, показаним нижче:
В даному прикладі відкликає сертифікат знаходиться в файлі myfile.pem серед інших сертифікатів, підписаних СА. В якості причини відкликання (crl_reason) можна вказати наступні значення:
- unspecified - цей варіант використовується, коли значення параметра вказано невірно або ж опущено;
- keycompromise, cacompromise / - компроментацію ключа або СА;
- affilationchanged - перехід в інший СА;
- superseded - заміна сертифіката (наприклад, після закінчення терміну дії);
- cessationofoperation - припинення обслуговування.
Після відкликання сертифікату необхідно оновити список відкликаних сертифікатів, або створити його, якщо не було ще жодного відгуку, як показано нижче: