Apache 2 з SSL / TLS: Крок за Кроком, Частина 2

1. Рекомендовані настройки mod_ssl
2. Аутентифікація веб сервера
3. опис атрибута
4. Парольная фраза dilemma
5. Створюємо сертифікат веб-сервера
6. Спосіб 1: самоподпісанного сертифікат (тільки для тестування)
7. Спосіб 2: Сертифікат, підписаний довіреною CA (рекомендується)
8. Спосіб 3: Сертифікат, підписаний локальним CA
9. установка сертифіката
10. Висновок другий частини

У другій частині ми обговоримо рекомендовані настройки mod_ssl, націлені на отримання максимальної безпеки і оптимальної продуктивності. Крім того, читач дізнається, як створити локальний Certification Authority і SSL-сертифікат, використовуючи OpenSSL бібліотеку з відкритим кодом.

Автор Artur Maj

У першій статті цього циклу ми розповіли як правильно встановлювати налаштовувати і усувати несправності Apache 2.0 з підтримкою SSL / TLS. У другій частині ми обговоримо рекомендовані настройки mod_ssl, націлені на отримання максимальної безпеки і оптимальної продуктивності. Крім того, читач дізнається, як створити локальний Certification Authority і SSL-сертифікат, використовуючи OpenSSL бібліотеку з відкритим кодом.

Рекомендовані настройки mod_ssl

В Apache 2.0.52 існує більше 30 директив, які використовуються для настройки mod_ssl. Детальний опис їх всіх можна знайти в Apache's mod_ssl documentation . У цьому розділі розглянемо тільки рекомендовані настройки, які впливають на безпеку або продуктивність SSL / TLS сполук.

Лістинг цих налаштувань показаний в Таблиці 1.

SSLEngine Повинна бути включена, інакше головний сервер (або віртуальний хост) не підтримуватиме SSL / TLS. SSLRequireSSL Повинна бути включена, інакше користувачі зможуть отримувати доступ до веб-контенту через звичайні HTTP-запити, в обхід SSL / TLS. SSLProtocol

SSLProxyProtocol

Слід налаштувати на використання тільки TLS v1.0 і SSL v3.0. Більшість нових веб-браузерів підтримують обидва протоколи, тобто ми можемо впевнено відключити SSL v2.0. SSLCipherSuite

SSLProxyCipherSuite

Для забезпечення сильної криптографії цей параметр слід встановити в режим HIGH (> 168 біт) і MEDIUM (128 біт). LOW (<56 біт) і NULL (без шифрування) слід відключити. Крім того, рекомендується відключити всі алгоритми шифрування, які підтримують анонімну аутентифікацію (aNULL). Опціонально, якщо ми хочемо забезпечити працездатність браузерів, які не справляються з сильним шифруванням, нам слід включити EXPORT (56-бітний і 40-бітний) алгоритм шифрування. Останнє, що потрібно поправити, це переважне використання SHA1 перед MD5. Отже, рекомендовані настройки можуть виглядати наступним чином:

HIGH: MEDIUM:! ANULL: + SHA1: + MD5: + HIGH: + MEDIUM

Ми можемо переглянути які алгоритми шифрування підтримують передбачувані настройки:

openssl ciphers -v 'HIGH: MEDIUM: \! aNULL: + SHA1: + MD5: + HIGH: + MEDIUM'

SSLOptions Опції "+ StrictRequire" слід встановити, інакше директива "Satisfy Any" може дозволити отримати доступ до веб-контенту, навіть якщо не використовується SL / TLS. SSLRandomSeed Для запуску Apache слід встановити в режим використання псевдо випадкового пристрої (/ dev / urandom) і / або EGD (Entrophy Gathering Daemon). Перед установкою кожного нового SSL-з'єднання, воно повинно бути налаштоване на використання вбудованого джерела, / dev / urandom або EGD. Не рекомендується використовувати / dev / random в обох випадках. SSLSessionCache Щоб уникнути повторюваних SSL «рукостискань» для паралельний HTTP запитів (наприклад, коли веб браузер завантажує кілька картинок одночасно), має бути дозволено SSL кешування. Варто встановити режим спільного використання пам'яті (SHM - shared memory) або DBM. Якщо встановити значення в "none", продуктивність веб-сервера різко знизиться. SSLSessionCacheTimeout Це значення вказує - скільки секунд має пройти до закінчення SSLSessionCache. Слід поставити хоча б 300-600 секунд. Однак насправді цей час має залежати від того, скільки часу користувачі знаходяться на веб-сервері. Наприклад, максимальний час - 15 хвилин, тоді як значення повинно бути виставлено в 900 (15 хвилин * 60 секунд). SSLVerifyClient

SSLProxyVerify

Без використання аутентифікації клієнта або проксі, цих опцій слід привласнити значення "none". Ніколи не встановлюйте значення "optional_no_ca", тому що це буде суперечити ідеї PKI аутентифікації, коли для аутентифікації клієнта повинен бути присутнім тільки нормальний сертифікат. Можна вибрати "optional" (залежить від індивідуальних потреб), але можливі глюки з деякими веб браузерами. SSLVerifyDepth

SSLProxyVerifyDepth

Повинно містити максимальне число проміжних CA. Наприклад, для прийняття тільки самоподпісанного сертифікатів, підписаних root'ом CA - має бути 1. І так далі. SSLProxyEngine Слід відключити, якщо не використовується SSL / TLS проксі-механізм.

Table 1. Рекомендовані настройки mod_ssl.

Ось наш приклад настоянок в httpd.conf, слідую рекомендаціям вище:

SSLEngine on SSLOptions + StrictRequire <Directory /> SSLRequireSSL </ Directory> SSLProtocol -all + TLSv1 + SSLv3 # Support only for strong cryptography SSLCipherSuite HIGH: MEDIUM:! ANULL: + SHA1: + MD5: + HIGH: + MEDIUM # Support for strong and export cryptography # SSLCipherSuite HIGH: MEDIUM: EXP:! aNULL: + SHA1: + MD5: + HIGH: + MEDIUM: + EXP SSLRandomSeed startup file: / dev / urandom 1024 SSLRandomSeed connect file: / dev / urandom 1024 SSLSessionCache shm: / usr / local / apache2 / logs / ssl_cache_shm SSLSessionCacheTimeout 600 SSLVerify none SSLProxyEngine off

Як додаток до вищезазначених директив mod_ssl, існують ще дві дуже важливі директиви від інших модулів Apache (mod_log_config і mod_set_envif), які потрібно налаштувати, як показано в Таблиці 2.

Директива (и)Рекомендована настройка або коментар

CustomLog Щоб вести логи про SSL параметрах (рекомендований мінімум: версія протоколу і обраний алгоритм шифрування), нам слід використовувати таке значення: CustomLog logs / ssl_request_log \ "% t% h% {HTTPS} x% { SSL_PROTOCOL} x% {SSL_CIPHER} x% {SSL_CIPHER_USEKEYSIZE} x% {SSL_CLIENT_VERIFY} x

\ "% R \"% b "

Setenvif Для забезпечення сумісності зі старими версіями MS Internet Explorer, в якому є помилки в здійсненні SSL (наприклад, проблеми з функцією підтримки з'єднання, HTTP / 1.1 через SSL, і закриття SSL-повідомлень при закритті з'єднань сокета), ставимо такі параметри: SetEnvIf User -Agent ". * MSIE. *" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0

Вище описана опція призведе до того, що веб-сервер не буде використовувати ні HTTP / 1.1, ні підтримку з'єднань, не надсилатиме SSL-повідомлення про закриття, якщо веб-браузер MS Internet Explorer.

Table 2. Рекомендовані настройки mod_log і mod_set_envif.

Приклад конфігураційного файлу (httpd.conf), представленого в попередній статті вже включає настройки, наведені вище.

Аутентифікація веб сервера

Отже, нам вдалося налаштувати і протестувати SSL / TLS, але веб-браузер не зміг перевірити достовірність веб-сервера. У першій статті ми використовували сертифікат веб-сервера, створеного тільки в цілях тестування і не містить інформацію, необхідну для справжньої аутентифікації і комерційних транзакцій.

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

• Відкритий ключ веб-сервера
• Дати автентичності (початку і закінчення)
• Підтримувані алгоритми шифрування
• Відмітна ім'я (the distinguish name DN), яке повинно містити повністю певне доменне ім'я веб-сервера, зване загальним ім'ям (Common Name CN). Опціонально DN може містити і деякі інші атрибути, наприклад, країну (Country C), штат (State S), Розташування (Location L), назва організації (the Organization's name O), назва служби організації (the Organization Unit's name OU), і ін.
• Серійний номер сертифікату
• Атрибути X.509v3, які будуть повідомляти веб-браузерам про тип і застосуванні
• URI CRL (якщо є)
• URI політики сертифіката X.509v3 (якщо є)
• Ім'я та підпис довіреної джерела сертифікатів (Certification Authority CA)

Варто відзначити, що атрибут загальне ім'я (Common Name CN) повинен мати значення, рівне доменному імені сервера (Fully Qualified Domain Name FQDN). Інакше браузерам не вдасться визначити приналежність сертифіката веб-сервера, на якому присутній наш сертифікат.

Приклад сертифіката веб-сервера (текстова репродукція):

Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: O = Seccure, OU = Seccure Root CA Validity Not Before: Nov 28 1:00:20 2004 GMT Not After: Nov 28 1:00:20 2005 GMT Subject: O = Seccure, OU = Seccure Labs, CN = www.seccure.lab Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00 : c1: 19: c7: 38: f4: 89: 91: 27: a2: 1b: 1d: b6: 8d: 91: 48: 63: 0E: 3d: 0d: 2 e: f8: 65: 45: 56: db : 98: 4d: 11: 21: 01: ac: 81: 8e: 3f: 64: 4a: 8a: 3f: 21: 15: ca: 49: 6e: 64: 5c: 5d: a2: ab: 5a: 48 : cb: 2a: 9f: 0c: 02: b9: ff: 52: f6: d9: 39: 6d: a3: 4a: 94: 41: f9: e9: ab: f0: 42: fb: 68: 9a: 4b : 53: 41: e7: 4f: b0: 2b: 02: d7: 92: a2: 2b: 02: a2: f9: f1: 2d: 68: fa: 50: 01: 2f: 49: c1: 28: 2f : a8: c6: 6d: 6d: ab: 1d: b9: bd: c9: 80: 63: f1: d6: 22: 19: de: 2d: 4a: 43: 50: 76: 79: 7e: a5: 5a : 75: af: 19 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA: FALSE Netscape Cert Type: SSL Server X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authenticat ion, Netscape Server Gated Crypto, Microsoft Server Gated Crypto Netscape Comment: OpenSSL Certificate for SSL Web Server Signature Algorithm: sha1WithRSAEncryption 45: 30: 9d: 04: 0E: b7: 86: 9e: 61: a1: b0: 68: 2b: 44: 93: 1c: 57: 2a: 99: 42: bb: 16: b1: ab: f5: c0: d2: 33: 12: c8: d3: 1d: 2b: bb: 6b: 9a: 4c: c7: 53: bc: e4: 88: ef: 1e: c3: 37: ed: 53: 2c: 15: cf: b8: 90: df: df: 4b: 34: b8: db: cc: 23: 77: 46: 06: 72: 9d: 43: 60: a8: a2: ed: 0a: bb: 1a: a4: e8: 4e: ba: 66: 93: 63: 74: 87: fd: 43: 48: b6: 93: a2: e3: 3d: da: 1b: 64: 46: 35: 88: b4: 4b: 22: e6: 3c: 84: 70: 5d: 88: dd: 64: c2: 51: c2: d6: 59: 80: 87: bc: bd: 7f: e3: c1: 45: 7e: c0: 5f: 9c: ca: e1: a1

Приклади, представлені в наступних розділах статті засновані на значеннях, показаних в Таблиці 3. Для створення відповідних сертифікатів читачеві потрібно змінити ці значення на назву їх власної компанії або організації.

опис атрибута

Атрибут

приклад значення

Код країни - Country code (two letters) CC = PL Штат або регіон - State or Province SS = mazowieckie Розташування - Location LL = Warsaw Назва організації - Organization Name OO = Seccure Назва служби організації - Organization Unit OU OU = Seccure Labs Загальна ім'я - Common Name CN CN = www.seccure.lab

Table 3. Приклади значень сертифіката.

Парольная фраза dilemma

Перед створенням сертифікатів важливо зрозуміти причетність парольної фрази. Чи слід шифрувати закритий ключ чи ні? Існує багато думок, але рекомендується не захищати закритий ключ веб-сервера з використанням парольної фрази. Це не тільки незручно, але і являє собою лише міраж безпеки. Чому? Розглянемо ці точки зору:

1. Необхідно буде вводити парольний фразу після кожної перезавантаження сервера, що може дратувати, якщо систему потрібно часто перезавантажувати (наприклад, при оновленні ядра, перебоях з харчуванням, зміні конфігурації і т.п.)
2. Якщо зловмисникові вдасться отримати закритий ключ на веб-сервері, це буде означати, що веб-сервер уже компрометувати і зломщик отримає привілеї root'a. В цьому випадку хакер зможе дізнатися і парольний фразу, встановивши кей-логгер і перезагрузив систему, тим самим він все одно змусить системного адміністратора ввести парольний фразу. Також зловмисник може переглянути пам'ять Apache і знайти Закритий ключ веб-сервера, що зберігається в дампі у відкритому тексті. Хоча здійснити це складно, але для тих, хто має досвід у зломі систем сімейства Unix, великої проблеми це не викличе (найпростіший спосіб - використовувати утиліту pcat з The Coroner's Toolkit ).

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

Створюємо сертифікат веб-сервера

Тепер ми можемо створити сертифікат нашого веб-сервера. Взагалі, існує три типи сертифікатів, які ми можемо використовувати:

1. Самоподпісанний сертифікат.
2. Сертифікат, підписаний довіреною CA (найбільш рекомендований).
3. Сертифікат, підписаний локальним CA.

Наступні розділи детально описують способи створення цих сертифікатів. Кінцевий результат будь-якого способу буде всього в двох файлах:

• server.key - закритий ключ веб-сервера
• server.crt - зашифрований PEM сертифікат, що містить открийтий ключ сервера

Спосіб 1: самоподпісанного сертифікат (тільки для тестування)

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

Закритий / відкритий ключ і самоподпісанний РЕМ-зашифрований сертифікат створюються в такий спосіб:

openssl req \ -new \ -x509 \ -days 365 \ -sha1 \ -newkey rsa 1024 \ -nodes \ -keyout server.key \ -out server.crt \ -subj '/ O = Seccure / OU = Seccure Labs / CN = www.seccure.lab '

За допомогою цих команд виконуються наступні дії: створення нового (-new) сертифіката (-x509), який буде дійсний протягом року (-days 365) і буде підписаний з використанням алгоритму SHA1 (-sha1). Закритий ключ RSA матиме довжину 1024 біт (-newkey rsa: 1024), і не буде захищений пральний фразою (-nodes). Сертифікат і закритий / відкритий ключі будуть створені в файлах "server.crt" і "server.key" (-out server.crt -keyout server.key). Параметр "-subj" говорить про те, що назва компанії "Seccure" (O = Seccure), назва служби "Seccure Labs", і цілком визначене доменне ім'я "www.seccure.lab".

Після створення цього сертифіката ми повинні встановити його в кожен веб-браузер, який буде потенційним клієнтом нашого сервера. Інакше, веб-браузери, котрі відправляють запит на з'єднання нашого сервера, не зможуть перевірити його справжність. Для Windows середовища це буде виглядати наступним чином:

Малюнок 1. Установка самоподпісанного сертифіката на машину клієнта.

Спосіб 2: Сертифікат, підписаний довіреною CA (рекомендується)

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

Не забувайте, що кожен СА має різні обмеження на атрибут DN, тому читачеві варто заздалегідь ознайомитися з ними. Рекомендується також вибирати такі сертифікати, які встановлені в більшості веб браузерів (Thawte, Verisign і деякі інші). Інакше, у веб-браузера користувача виникнуть проблеми з аутентифікацією веб-сервера.

Процес отримання підписаного сертифікату від довіреної СА складається з наступних кроків:

1. Насамперед, слід створити пару закритого / відкритого ключа (server.key) і запит сертифіката (request.pem), як показано нижче:

openssl req \ -new \ -sha1 \ -newkey rsa 1024 \ -nodes \ -keyout server.key \ -out request.pem \ -subj '/ O = Seccure / OU = Seccure Labs / CN = www.seccure.lab '

2. Тепер ми повинні послати запит на отримання сертифіката (request.pem) в СА і дочекатися, поки він буде підписаний і надісланий назад у вигляді сертифіката.

3. Після отримання сертифікату від довіреної СА ми повинні упевнитися в тому, що він закодований у форматі PEM, а не TXT або DER. Якщо ж отриманий сертифікат не відповідає формату РЕМ, то ми повинні конвертувати його, в якому б форматі він не прийшов.

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

• PEM, Base64 кодування формату X.509 (* .crt, * .pem, * .cer)

----- BEGIN CERTIFICATE ----- MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN ... ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9 f + PBRX7AX5zK4aE = ----- END CERTIFICATE -----

• TXT + PEM format (* .crt, * .cer, * .pem, * .txt)

Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: O = Seccure, OU = Seccure Root CA ... RSA Public Key: (1024 bit) Modulus (1024 bit): 00 : c1: 19: c7: 38: f4: 89: 91: 27: a2: 1b: 1d: b6: 8d: 91: ... X509v3 extensions: X509v3 Basic Constraints: CA: FALSE ... ----- BEGIN CERTIFICATE ----- MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN ... ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9 f + PBRX7AX5zK4aE = ----- END CERTIFICATE -----

Команда для конвертації формату TXT + PEM в РЕМ:

openssl x509 -in signed_cert.pem -out server.crt

• DER, двійкова кодування X.509 (* .der, * .crt, * .cer)

[Нетекстової, двійкове подання]

Команда для перетворення формату DER в РЕМ:

openssl x509 -in signed_cert.der -inform DER -out server.crt

1. Верифікація і тестування сертифіката

Перед установкою сертифіката ми повинні перевірити, чи дійсно він законний і може бути використаний в цілях аутентифікації веб-ервера:

openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt

Крім того, було б непогано переконатися в тому, що наш сертифікат відповідає раніше створеному закритому ключу (результати виконання обох команд повинні бути однаковими):

openssl x509 -noout -modulus -in server.crt | openssl sha1 openssl rsa -noout -modulus -in server.key | openssl sha1

Спосіб 3: Сертифікат, підписаний локальним CA

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

Для використання цього способу нам потрібно створити локальний закритий / відкритий ключ СА, також як і сертифікат і репозиторій СА для нових ключів.

Примітка: Локальний СА повинен бути створений на окремому сервері, який не має з'єднання з мережею. Операційна система повинна давати доступ тільки авторизованому персоналу, а сама машина повинна бути під охороною. Закритий СА ключ - найважливіший елемент всієї системи PKI - якщо він буде компрометувати, то всі інші сертифікати, підписані цим СА також будуть компрометувати!

Для установки середовища ми буде використовувати бібліотеку OpenSSL. Зрозуміло, що якщо у нас вже є локальний СА, ми можемо пропустити цей розділ і продовжити створення запиту на сертифікат для веб-сервера.

1. Підготуємо структуру каталогу для нового СА (середа змінної $ SSLDIR винна буті додана до відповідніх скрипти автозавантаження, Такі як / etc / profile або /etc/rc.local:

export SSLDIR = $ HOME / ca mkdir $ SSLDIR mkdir $ SSLDIR / certs mkdir $ SSLDIR / crl mkdir $ SSLDIR / newcerts mkdir $ SSLDIR / private mkdir $ SSLDIR / requests touch $ SSLDIR / index.txt echo "01"> $ SSLDIR / serial chmod 700 $ SSLDIR

1. Створюємо основний файл настройок OpenSSL - $ SSLDIR / openssl.cnf, з Наступний змістом (оптимізовано для использование з SSL веб-серверами):

# ================================================= # OpenSSL configuration file # ============================================= ==== RANDFILE = $ ENV :: SSLDIR / .rnd [ca] default_ca = CA_default [CA_default] dir = $ ENV :: SSLDIR certs = $ dir / certs new_certs_dir = $ dir / newcerts crl_dir = $ dir / crl database = $ dir / index.txt private_key = $ dir / private / ca.key certificate = $ dir / ca.crt serial = $ dir / serial crl = $ dir / crl.pem RANDFILE = $ dir / private / .rand default_days = 365 default_crl_days = 30 default_md = sha1 preserve = no policy = policy_anything name_opt = ca_default cert_opt = ca_default [policy_anything] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [req] default_bits = 1024 default_md = sha1 default_keyfile = privkey.pem distinguished_name = req_distinguished_name x509_extensions = v3_ca string_mask = nombstr [Req_distinguished_name] countryN ame = Country Name (2 letter code) countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) localityName = Locality Name (eg, city) 0.organizationName = Organization Name (eg, company) organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [usr_cert] basicConstraints = CA: FALSE # nsCaRevocationUrl = https: // url-to-exposed- clr-list / crl.pem [ssl_server] basicConstraints = CA: FALSE nsCertType = server keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, nsSGC, msSGC nsComment = "OpenSSL Certificate for SSL Web Server" [ssl_client] basicConstraints = CA: FALSE nsCertType = client keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth nsComment = "OpenSSL Certificate for SSL Client" [v3_req] basicConstraints = CA: FALSE keyUsage = nonRepudiation, d igitalSignature, keyEncipherment [v3 _ca] basicConstraints = critical, CA: true, pathlen: 0 nsCertType = sslCA keyUsage = cRLSign, keyCertSign extendedKeyUsage = serverAuth, clientAuth nsComment = "OpenSSL CA Certificate" [crl_ext] basicConstraints = CA: FALSE keyUsage = digitalSignature, keyEncipherment nsComment = "OpenSSL generated CRL"

• Тепер створюємо пару СА закритого / відкритого ключа та самоподпісанного сертифіката СА:
openssl req \ -config $ SSLDIR / openssl.cnf \ -new \ -x509 \ -days 3652 \ -sha1 \ -newkey rsa 1024 \ -keyout $ SSLDIR / private / ca.key \ -out $ SSLDIR / ca.crt \ -subj '/ O = Seccure / OU = Seccure Root CA'

Для закритого СА ключа слід придумати парольний фразу, яку важко підібрати і вона повинна бути нормальною більшу кількість часу, ніж звичайні сертифікати (зазвичай від 10 до 30 років або більше).

Сертифікат СА "ca.crt" слід викласти у відкритий доступ на веб-сторінках интрасети і встановити в кожен веб-браузер, яким він може знадобитися. Нижче показаний приклад встановленого в Internet Explorer сертифіката.



Малюнок 2. Приклад кореневого CA сертифікату, встановленого в Internet Explorer.

Тепер ми можемо використовувати наш локальний СА для підписання / анулювання сертифікатів. Для створення сертифіката веб-сервера потрібно дотримуватися наступних кроків:

1. Створюємо пару закритий / відкритий ключ веб-сервера (server.key), і запит на сертифікат (request.pem). На веб-сервері потрібно виконати наступні команди:

openssl req \ -new \ -sha1 \ -newkey rsa 1024 \ -nodes \ -keyout server.key \ -out request.pem \ -subj '/ O = Seccure / OU = Seccure Labs / CN = www.seccure.lab '

1. Копіюємо цей запит (request.pem) в директорію $ SSLDIR / requests на хост CA (з використанням переносного носія, наприклад USB драйву).
2. Підпишемо запит на сертифікат (команди виконувати тільки на хості СА):

openssl ca \ -config $ SSLDIR / openssl.cnf \ -policy policy_anything \ -extensions ssl_server \ -out $ SSLDIR / requests / signed.pem \ -infiles $ SSLDIR / requests / request.pem

4. Результатом цих команд буде підписаний сертифікат (signed.pem), який буде знаходиться в директорії $ SSLDIR / newcerts, і в файлі $ SSLDIR / signed.pem. Він складається відразу з TXT і PEM поданні сертифікату. Так як Apache очікує усічений варіант в форматі PEM, ми конвертуємо його:

openssl x509 \ -in $ SSLDIR / requests / signed.pem \ -out $ SSLDIR / requests / server.crt

1. Скопіюйте підписаний, в форматі PEM сертифікат (server.crt) назад на машину, яка є веб-сервером.

Тепер сертифікат готовий до використання.

Для місцевих СА в разі компрометації сертифіката строго рекомендується анулювати сертифікат і інформувати користувачів про те, що сертифікат більше не дійсний. Для анулювання сертифіката ми повинні відшукати його серійний номер у файлі $ SSLDIR / index.txt. Далі виконуємо наступні команди:

openssl ca \ -config $ SSLDIR / openssl.cnf \ -revoke $ SSLDIR / newcerts / .pem

Для створення CRL (Certificate Revocation List - Список анулювати Сертифікатів) файлу, робимо наступне:

openssl ca -config $ SSLDIR / openssl.cnf -gencrl -crlexts crl_ext -md sha1 -out $ SSLDIR / crl.pem

Цей файл повинен бути опублікований на сайті СА і / або надано користувачам іншим способом. У процесі поширення CRL'ов також рекомендується використовувати Online Certificate Status Protocol (OCSP). Більш детальну інформацію можна знайти в RFC 2560 .

Зауважте, що деякі браузери (включаючи Firefox) приймають CRL'и тільки в форматі DER, тому для установки сертифікатів в ці браузери потрібно конвертувати файл crl.pem:

openssl crl \ -in $ SSLDIR / crl.pem \ -out $ SSLDIR / revoke_certs.crl \ -outform DER

Крім того, щоб браузер перевіряв - анулювати сертифікат веб-сервера, потрібно встановити опцію "Check for server certificate revocation" (Перевіряти анулювання сертифікатів серверів). Приклад для MS Internet Explorer:

Малюнок 3. Налаштування Internet Explorer на перевірку анулювання сертифікатів. Малюнок 4. Реакція Internet Explorer на анульований сертифікат.

установка сертифіката

Тепер можна продовжити установку закритого ключа веб-сервера (server.key) і самого сертифіката (server.crt) в середу Apache:

install -m 600 -o root -g sys server.key /usr/local/apache2/conf/ssl.key/ install -m 644 -o root -g sys server.crt / usr / local / apache2 / conf / ssl. crt /

Слід перевірити, що директиви в конфігурації Apache посилаються саме на файли, зазначені вище (в httpd.conf):

SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key Нарешті, перезапускаємо Apache і зміни вступають в силу: SSLCertificateFile / usr / local / apache2 / conf / ssl.crt / server.crt SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

Перевіримо, чи працює SSL веб-сайт і чи можуть браузери аутентифицировать веб-сервер. Тепер не повинно з'явитися жодних повідомлень:

> Малюнок 5. Безпечне з'єднання з чинним законним сертифікатом.

Висновок другий частини

У другій частині ми розповіли, як налаштувати mod_ssl і як створити і використовувати X.509v3 сертифікати веб сервера. У наступній, третій і останній частині цього циклу статей ми обговоримо процес аутентифікації клієнтів через сертифікати, а також часті помилки системних адміністраторів і відомі атаки, які можуть представляти реальну загрозу SSL-з'єднань.