Новости
SSL-сертифікати сайтів, призначення та використання (ssl cert crypt openssl)
Ключові слова: ssl , cert , crypt , openssl , ( знайти схожі документи )
From: Рашид Ачилов Date: Mon, 16 Apr 2010 17:02:14 +0000 (UTC) Subject: SSL-сертифікати сайтів, призначення та використання Матеріал надано редакцією журналу Системний адміністратор. Опубліковано в журналі " Системний адміністратор "N 3 2010 Статтю можна обговорити на Форумі журналу" Системний адміністратор " http://www.samag.ru/forum/ Що це таке? Чому недостатньо встановити Apache з підтримкою https, щоб сайт вважався безпечним? Як надати доступ до корпоративних порталів ззовні, не встановлюючи ключа для кожного? Ти мені віриш чи ні? У вересні 2009 року була опублікована перша стаття циклу "Заміна Microsoft Exchange на Open Source-рішення" [1], в рамках якої передбачається розповісти про те, як можна замінити багатофункціональний сервер Microsoft Exchange на не менше багатофункціональний Open Source-комплект, який буде робити все те ж саме і навіть більше. І хоча дана стаття не входить в цей цикл безпосередньо, вона має до нього безпосереднє відношення, оскільки первинним завданням було надання доступу до корпоративної пошти з будь-якого комунікатора, смартфона або переносного комп'ютера. Той факт, що даний сервер доступу повинен використовувати https для шифрування трафіку і бути доступний на нестандартному порту, абсолютно очевидний, і як це зробити - наводилося в [6]. Також існує досить багато матеріалів на тему установки Apache з модулем SSL (хоча більшість з них - передруки або [2], або [5]), тому будемо вважати, що у нас вже працює https-сервер на порту, ну, припустимо, 20202 , який використовує ключ http://www.snakeoil.com , Що поставляється в якості зразка). Проте, при спробі зайти на наш сайт, браузер неодмінно відобразить вікно попередження. Чому ж наш сертифікат вважається недійсним, і як цього уникнути? Перш за все - що таке, власне, SSL-сертифікат. Це свого роду "електронний паспорт" сайту, в якому він підтверджує, що він дійсно той сайт, за який видає себе. Оскільки https давно і міцно використовується для безготівкових платежів, в яких не буває багато безпеки, сертифікат сайту покликаний додатково підтверджувати, що цей сайт - дійсно сайт банку, платіжної системи і т.д. Власне, SSL-сертифікат, як і всякий паспорт, зберігає різні дані: найменування організації і підрозділи (якщо воно є), країну, регіон, місто і ім'я сервера, для якого цей сертифікат був створений. І, як і всякий паспорт, він повинен бути підписаний організацією, якій довіряють все. І якщо на документі стоїть її підпис - вважається, що документ містить правильну інформацію. У Росії таку роль при видачі паспортів громадянам виконує УФМС. А як справи йдуть в світі? А в світі ця система чимось схожа на DNS - точно так само існує набір деяких "довірених" центрів (званих центрами сертифікації, Center of Authority, CA), і в тому випадку, якщо наш сертифікат підписаний ключем одного з цих центрів, - інформація в ньому вважається вірною. Послуга ця не з дешевих, річна ліцензія VeriSign (одного з найбільш відомих CA) коштує $ 1200, але зате, якщо сертифікат сайту підписаний будь-яким з "довірених" CA, вважається, що адреса, куди ми зайшли, - це насправді потрібний нам сайт, оскільки це гарантується авторитетом компанії, яка підписала наш сертифікат. Як же система спочатку отримує ключі "довірених" CA? Досить просто. Microsoft поширює їх як оновлення системи через свій механізм установки оновлень, а інші браузери, наприклад Firefox, містять їх безпосередньо в дистрибутиві. А тепер подивимося на наш ключ уважніше. І відразу все стає зрозумілим. По-перше, наш сертифікат ніким не підписаний. Це все одно що написати на аркуші паперу "Паспорт" і намагатися видавати його за документ. По-друге, інформація, яка зберігається в сертифікаті, і реальна інформація про сайт, розрізняються (нагадую, що зараз у нас встановлено тестовий сертифікат, створений для сайту www.snakeoil.com). Ще в сертифікаті може зберігатися дата, після якої він перестає діяти. Якщо не виконується хоча б одна з цих умов, а саме: * сертифікат повинен бути підписаний одним з ключів, що зберігаються як ключі кореневих центрів сертифікації; * Ім'я сервера, що зберігається в сертифікаті, має збігатися з ім'ям відкривається сторінки ;. * Дата закінчення терміну дії сертифіката не повинна бути менше поточної. То тоді сертифікат сайту буде вважатися "небезпечним" і браузери будуть видавати відповідні попередження, а то і не пускати на сайт, в залежності від браузера і його налаштувань. Яким же чином домогтися виконання всіх умов, щоб не спостерігати постійно повідомлення від "системи безпеки" і не писати інструкції про те, як не звертати уваги на ці повідомлення? Імені сервера, точніше кажучи, відповідності імені сервера та імені, збереженого в сертифікаті, домогтися порівняно легко. Для цього тільки й треба, що встановити так званий "самоподпісанний" SSL-сертифікат. Як це зробити - досить докладно описано в [2] і [5], після чого ім'я в просматриваемом сертифікаті www.snakeoil.com заміниться на ім'я нашого сайту. Багато, як правило, на цьому і зупиняються. Причому не просто аматорські сайти, а сайти провайдерів, стільникових операторів і всіх тих, кому не мати цього сертифіката, підписаного тим же VesiSign або Thawte, ну просто соромно. Зупиняються, тому що, користувачеві, щоб прибрати повідомлення "системи безпеки", потрібно встановити якийсь ключ, і тільки після цього браузер заспокоїться. А якщо на наш сайт потрібно заходити зі смартфонів або комунікаторів, у яких немає можливості прийняти довільний ключ безпосередньо в сеансі або необхідно авторизуватися на десятці різних корпоративних сайтів? Тут вже без власного центру сертифікації не обійтися. Чим нам допоможе розгортання CA? Встановлюючи власний CA, ми створюємо всередині компанії єдиний центр, підпис якого сертифіката сайту буде мати ту ж силу, що і підпис VeriSign ... в масштабах компанії. Для цього достатньо буде поширити на всі комп'ютери і мобільні пристрої (смартфони, комунікатори) власний сертифікат нашого CA, оголосивши його кореневим, і всі ключі, які були або будуть в майбутньому підписані ним, автоматично стануть "безпечними", оскільки їх приналежність може бути перевірена . VeriSign власного виготовлення Насправді розгортання власного CA - справа не така вже й складна і досить докладно описано в [4] і [5]. Насамперед треба налаштувати /etc/ssl/openssl.conf - приклад файлу вже лежить там, досить внести в нього наведені нижче зміни. [Ca] # Ця секція буде використовуватися, якщо нічого не задано default_ca = CA_default [CA_default] dir =. # Кореневий каталог (щодо поточного!) Certs = $ dir / ssl.crt # Тут будуть лежати видані сертифікати crl_dir = $ dir / ssl.crl # Тут будуть лежати списки відкликання database = $ dir / index.txt # Це індексний файл бази даних new_certs_dir = $ dir / ssl.crt # Місце для нових сертифікатів certificate = $ dir / caserv.crt # Власний сертифікат CA serial = $ dir / serial # Файл для зберігання поточного серійного номера crl = $ dir / ssl.crl / crl.pem # Поточний CRL private_key = $ dir / ssl.key / caserv.key # Особистий ключ CA [ssl_server] basicConstraints = CA: FALSE nsCertType = server keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, nsSGC, msSGC nsComment = "OpenSSL Certificate for SSL Web Server "subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer: alw ays subjectAltName = email: copy issuerAltName = issuer: copy [ssl_client] basicConstraints = CA: FALSE nsCertType = client keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth nsComment = "OpenSSL Certificate for SSL Client" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid, issuer: always subjectAltName = email: copy issuerAltName = issuer: copy Секції [ssl_server] і [ssl_client] заповнені додатковою інформацією, що включається в сертифікати відповідно до man x509v3_config. Їх можна і не ставити, в файлі конфігурації за замовчуванням вони не визначені, але їх використання підвищує читабельність сертифікатів. Припускаємо, що вся структура каталогів буде розміщуватися в / usr / local / etc / apache22 / ssl. Якщо ніяких каталогів там немає, то створюємо їх (необхідні каталоги створювалися в apache1 установкою mod_ssl, в apache2 mod_ssl вже включений в дистрибутив): # cd / usr / local / etc / apache22 / ssl # mkdir ssl.crl # mkdir ssl.crt # mkdir ssl.csr # mkdir ssl.key # mkdir ssl.prm Створюємо головний ключ сертифікаційного центру: # openssl req -config /etc/ssl/openssl.cnf -new -newkey rsa 1024 \ -keyout caserv.key -x509 -days 7300 -out caserv.cr Country Name (2 letter code) [AU]: RU State or Province Name (full name) [Some-State]: Novosibirskaya Locality Name (eg, city) []: Novosibirsk Organization Name (eg, company ) [Internet Widgits Pty Ltd]: LLC "ShelonSoft Inc." Organizational Unit Name (eg, section) []: IT department Common Name (eg, YOUR name) []: bigcat.sheltonsoft.ru EmailAddress []: [email protected] При завданні пароля слід використовувати сгенерірованни пароль не менше 12 символів довжиною - цим паролем буде кодуватися головний ключ, що засвідчує справжність усіх інших джерел. При введенні іншої інформації будьте уважні: ця інформація буде відображатися як дані про засвідчувальний центр. Ключ створюється в форматі RSA довжиною 1024 біта і буде вважатися чинним два роки. Після створення файлів caserv.key помістити в каталог ssl.key, встановити права 0400 і всіляко перешкоджати спробам його отримати, caserv.crt ж - навпаки, викласти в загальний доступ і встановити в якості кореневого сертифіката на всі пристрої, з яких будуть звертатися до сайтів , сертифікати яких передбачається підписувати ключами даного CA. Крім того, необхідно створити індексний файл бази даних підписаних ключів (ім'я задається в параметрі database секції ca конфігураційного файлу) і файл з поточним серійним номером (ім'я задається в параметрі serial секції ca конфігураційного файлу): # touch index.txt # echo '01' -> serial Наш CA готовий підписувати сертифікати. Але для того, щоб йому довіряли, необхідно поширити власний сертифікат СА на всі пристрої, які будуть звертатися на сайти, сертифікат яких підписано ключем нашого СА. Втім, для стандартних комп'ютерів зробити це нескладно - Windows приймає як PEM-encoded, так і DER-encoded сертифікати, досить подвійного клацання - і сертифікат відкриється для перегляду, а після натискання кнопки "Встановити сертифікат" - запуститься майстер усановкі сертифікатів. Необхідно погодитися з попередженням системи безпеки - і все, наш сертифікат успішно встановлений. Установка сертифіката в якості кореневого в Firefox виконується безпосередньо в самому браузері. Вибираєте "Налаштування -> Додаткові -> Шифрування" і натискаєте кнопку "Перегляд сертифікатів", вибираєте розділ "Центри сертифікації" і натискаєте кнопку "Імпортувати". Знову нас один раз запитають: а чи дійсно ми хочемо довіряти цьому СА? Для мобільних пристроїв все буде дещо складнішою. Як приклад візьмемо смартфон Nokia N95 8G. У розділі "Налаштування -> Загальні -> Захист -> Сертифікати" можна лише переглянути список сертифікатів або видалити будь-якої з них. Для додавання сертифіката в смартфон необхідно виконати наступні дії: # openssl x509 -inform PEM -in caserv.crt -outform DER -out caserv.cer Перетворити його формат - файл * .crt (PEM-encoded) на смартфоні чомусь не розпізнається як файл сертифіката, і його необхідно перетворити в файл * .cer (DER-encoded): Після цього файл можна переносити на смартфон будь-яким стандартним способом. Після переміщення файлу в смартфон, відкрити стандартний менеджер файлів, знайти і вибрати файл сертифіката, натиснути центральну кнопку. Видається, Вам пропонується визначити сертифіката, потім попередження системи безпеки, з яким потрібно погодитися, потім вибір режимів довіри до сертифіката. Вибираємо ОК, сертифікат встановлено. Але найскладніше, звичайно, встановити сертифікат в комунікатор на базі Windows Mobile. У ньому в принципі відсутні будь-які засоби по управлінню сертифікатами і навіть сама компанія Microsoft пропонує тільки єдиний спосіб, що нагадує зломи ігр кінця 90-х. Далі потрібно створити файл з довільним ім'ям, розширенням .xml і наступним змістом: <wap-provisioningdoc> <characteristic type = "CertificateStore"> <characteristic type = "ROOT"> <characteristic type = "<certhash>"> <parm name = "EncodedCertificate" value = "<base64encodedcert>" /> </ characteristic> </ characteristic> </ characteristic> </ wap-provisioningdoc> За допомогою наступної команди отримати "відбиток" ключа, скопіювати текст відбитка і помістити його замість <certhash> , видаливши двокрапки (так, щоб вийшов безперервний текст): # openssl x509 -in caserv.crt -noout -text -sha1 -fingerprint SHA1 Fingerprint = 07: 55: 6E: 18: 20: 18: 01: CB: 0A: 31 : A7: 9D: 0E: C7: 47: 34: 37: D1: EE: 4E Відкриваємо за допомогою текстового редактора файл caserv.crt і копіюємо все, що розташоване між рядками ----- BEGIN SERTIFICATE ----- і ----- END SERTIFICATE -----. Вставляємо скопійований текст замість розділу <base64encodedcert>, видаливши символи розриву рядків, якщо такі є, так, щоб вийшла одна довга безперервна рядок. Зберегти отриманий файл під ім'ям _setup.xml. Упакувати отриманий файл в .cab командою (в Windows):> makecab _setup.xml wmcaserv.cab Повністю стаття, що описує цей спосіб (англійською мовою), викладена на [6]. Після створення файлу установки він стандартним чином переноситься на комунікатор і запускається там. Установка проходить мовчки, не задаючи жодних питань. Ну ось, залишилося тільки забезпечити всі потрібні нам сайти ключами, які замість того, щоб бути "самоподпісанного", будуть підписані нашим CA. Це виконується в два етапи. Спочатку формується запит на сертифікацію і закритий ключ. # Openssl req -new -sha1 -newkey rsa 1024 -nodes -keyout <filename> .key \ -out <filename> .pem -config /etc/ssl/openssl.cnf При створенні запиту будьте уважні при відповідях на питання, особливо при завданні CommonName - тут повинно бути задано ім'я сайту, яке буде вказуватися в браузерах без префікса https. Country Name (2 letter code) [AU]: RU State or Province Name (full name) [Some-State]: Novosibirskaya Locality Name (eg, city) []: Novosibirsk Organization Name (eg, company) [Internet Widgits Pty Ltd ]: LLC "SheltonSoft Inc." Organizational Unit Name (eg, section) []: Web server Common Name (eg, YOUR name) []: www.sheltonsoft.ru Email Address []: [email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: 123456 An optional company name []: LLC "SheltonSoft Inc." В даному випадку ключ запитується для сервера з адресою www.sheltonsoft.ru. Після створення закритого ключа і запиту на сертифікацію, файл <filename> .key поміщається в каталог ssl.key того комп'ютера, на якому створювався запит на сертифікацію, а файл <filename> .pem передається на той комп'ютер, на якому розгорнуто СА, де отриманий запит необхідно підписати, зберігши його для цього в каталог ssl.csr: # openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything \ -out ssl.crt / <filename> .pem -infiles ssl.csr / <filename > .pem # openssl x509 -in ssl.crt / <filename> .pem -out ssl.crt / <filename> .crt Тепер готовий файл сертифіката буде знаходитися в каталозі ssl.crt, його необхідно нам передати назад на той комп'ютер, з кото ого вирушав запит на сертифікацію. Останнє, що необхідно зробити, - це налаштувати Apache для використання даного ключа. SSLCertificateFile /usr/local/etc/apache/ssl.crt/<filename>.crt SSLCertificateKeyFile /usr/local/etc/apache/ssl.key/<filename>.key Виконується це двома директивами конфігураційного файлу (основного або віртуального хоста) . Не забувайте, що після зміни даних директив необхідний повний перезапуск Apache, виконання команди apachectl restart недостатньо. Ну ось, тепер у нас є власний засвідчує центр, і при відвідуванні корпоративних порталів браузери більше не будуть видавати повідомлення "системи безпеки" (які особливо дратують на смартфонах, де чомусь немає можливості зберегти сертифікат безпосередньо при підключенні). Чи обмежуються можливості CA тільки посвідченням сертифікатів сайтів? Та ні, звичайно ж. У наступній статті ми розглянемо, яким чином можна використовувати SSL при підключенні до стандартних поштових сервісів - POP3 І IMAP. 1. Ачилов Р. Замінюємо сервер MS Exchange. Установка Horde Groupware. // Системний адміністратор, No.9, 2009 г. - С. 42-47. 2. Apache2 з SSL / TLS. Крок за кроком - http://www.ti.chernigov.ua/labs/ksm/apache_ssl/ssl.html 3. Основи роботи з OpenSSL - http://www.nixp.ru/articles/openssl 4. Авторизація за допомогою клієнтських SSL-сертифікатів - https://www.opennet.ru/base/sec/ssl_cert.txt.html 5. Налаштування Apache + modssl для роботи через https - https://www.opennet.ru/base/net/apache_mod_ssl.txt.html 6. Adding a Certificate to the Root Store of a Windows Mobile-based Device - http://technet.microsoft.com/en-us/library/cc182241.aspx Статтю можна обговорити на Форумі журналу "Системний адміністратор" http://www.samag.ru/forum/
Обговорення [ RSS ]
- 2.6 , AdVv (??), 22:07 21/04/2013 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]
> Наскільки я зрозумів, навіть найпростіші сертифікати забезпечують захист вводяться > Особистих даних. Але все-таки який краще вибрати для простого електронного-магазину?
Звичайний сертифікат на доменне ім'я.
Можна на доменне ім'я + всі піддомени, це іноді зручніше, але дорожче.
Рівень безпеки однаковий у всіх видів сертифікатів.
Додати коментар
Спонсори:
Хостинг:
Чому недостатньо встановити Apache з підтримкою https, щоб сайт вважався безпечним?
Як надати доступ до корпоративних порталів ззовні, не встановлюючи ключа для кожного?
Ти мені віриш чи ні?
Чому ж наш сертифікат вважається недійсним, і як цього уникнути?
А як справи йдуть в світі?
Як же система спочатку отримує ключі "довірених" CA?
Яким же чином домогтися виконання всіх умов, щоб не спостерігати постійно повідомлення від "системи безпеки" і не писати інструкції про те, як не звертати уваги на ці повідомлення?
Чим нам допоможе розгортання CA?
Знову нас один раз запитають: а чи дійсно ми хочемо довіряти цьому СА?