Разработка сайта для Вашего бизнеса. Веб дизайн. Дизайн логотипа, фирменного стиля, рекламная фотография . Комплексный рекламный креатив.

Ralex. We do the work.
На рынке с 1999го года. Средняя ценовая категория. Ориентация на эффективность решений.
Ознакомтесь с нашим портфолио
Узнайте больше о услугах
Свяжитесь с нами:
E-mail: [email protected]
Tel: (044) 587 - 84 - 78
Custom web design & дизайн и разработка сайта "под ключ"
Креативный, эффективный дизайн. Система управления сайтом (СУС).
Custom flexible разработка систем электронной коммерции
Система e-commerce разрабатывается под индивидуальные потребности. Гибкая функциональность.
Search Engine Optimzation & оптимизация под поисковые системы (SEO)
Постоянная оптимизация и мониторинг сайта в поисковых системах. Достигаем результата быстро и эффективно
Custom logo design & дизайн логотипа и фирменного стиля
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.
профессиональная рекламная фотография
креативно, смело, качественно
Custom logo design & рекламный креатив. дизайн рекламы
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.

SSL-сертифікати Web-сайтів і їх застосування: Частина 2. Встановлення SSL-сертифікатів для клієнта і сервера і обмеження доступу до Web-сайту на стороні сервера

  1. Серія контенту:
  2. Цей контент є частиною серії: SSL-сертифікати Web-сайтів і їх застосування
  3. Установка серверного сертифіката
  4. Лістинг 1. Підключення SSL-сертифікатів
  5. Установка сертифіката в Web-браузер користувача
  6. Малюнок 1. Відображення невідомого сертифіката в Google Chrome
  7. Перетворення SSL-сертифіката з одного формату в інший
  8. Установка SSL-з'єднання з Web-сайтом
  9. Малюнок 3. Встановлене SSL-З'єднання в Google Chrome
  10. Обмеження можливості підключення для небажаних клієнтів
  11. Лістинг 2. Додавання обмежень на підключення клієнтів
  12. Малюнок 5. Сторінка з повідомленням про відмову в підключенні в Google Chrome
  13. висновок
  14. Ресурси для скачування

Наша взаимовыгодная связь https://banwar.org/

SSL-сертифікати Web-сайтів і їх застосування

Серія контенту:

Цей контент є частиною # з серії # статей: SSL-сертифікати Web-сайтів і їх застосування

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: SSL-сертифікати Web-сайтів і їх застосування

Слідкуйте за виходом нових статей цієї серії.

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

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

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

Часто використовувані скорочення.

  • SSL - рівень захищених сокетів (secure socket layer);
  • CA - засвідчує центр (center of authority);
  • CSR - запит на сертифікацію (certificate signing request);
  • CRL - список відкликаних сертифікатів (certificate revocation list);
  • PKCS - криптографічні стандарти з відкритим ключем (public-key cryptography standards);
  • CN - загальні дані (common name).

Для того, щоб до Web-сайту можна було звертатися по протоколу HTTPS, на ньому повинен бути встановлений власний сертифікат. "Власний" означає, що ім'я сайту, що використовується клієнтами для звернення до сайту, збігається з ім'ям, зазначеним в поле CN сертифіката. Однак, так як за вимогами протоколу SSL комбінація "адреса: порт" повинна бути унікальною, то встановити кілька різних віртуальних серверів (з різними сертифікатами) на один порт 443 не вийде, і для кожного сервера потрібно виділити окремий порт і вказати його при описі даного сервера.

Процес створення SSL-сертифіката для сервера описувався в попередній частині статті. Тому передбачається, що серверний сертифікат вже створений і підписаний в корпоративному СА, а також є файли myfile.key і myfile.crt, відповідні ключу і сертифікату сайту. Але до того, як клієнти Web-сайту зможуть почати ними користуватися, ці файли потрібно підключити до Web-серверу (в рамках даної статті використовується Wеб-сервер Apache) через конфігураційний файл віртуального сервера (або кореневого сайту) як показано в лістингу 1:

Лістинг 1. Підключення SSL-сертифікатів

SSLEngine on SSLProtocol all -SSLv2 SSLCipherSuite HIGH: MEDIUM: EXP:! ANULL: + SHA1: + MD5: + HIGH: + MEDIUM: + EXP SSLCertificateFile "/etc/ssl/certs/myfile.crt" SSLCertificateKeyFile "/ etc / ssl / certs / myfile.key "

У лістингу 1 наведені тільки параметри (директиви конфігурації Apache), що відносяться до SSL-сертифікатами, тому для повноцінної конфігурації буде потрібно вказати і інші параметри. Зазначені директиви записуються в блоці <VirtualHost> (для віртуального сервера) або в файлі конфігурації кореневого сервера (для стандартного Web-сервера).

В даному прикладі виконується включення SSL (1-й рядок), на 2-ий рядку відбувається відключення слабкою і небезпечною версії 2.0 протоколу SSL. Потім на 3-ій рядку встановлюються параметри захищеного з'єднання, які можуть використовуватися (який набір параметрів буде обраний, залежить ще й від подключающегося клієнта). На рядках 4 і 5 вказуються SSLCertificateFile і SSLCertificateKeyFile - шляху до файлу c SSL-сертифікат і до файлу з ключем сертифікату.

Для нормальної роботи SSL необхідно, щоб ім'я сервера, прописане в директиві ServerName, збігалося з ім'ям, зазначеним для поля CN в процесі створення сертифіката. Якщо це правило не виконується, то при зверненні до сайту Web-браузер буде постійно відображати сторінку з попередженням.

Важливе зауваження: перевіряється саме директива ServerName, а не директива ServerAlias. Якщо для сервера необхідно вказати кілька імен, то їх можна прописати в директиві ServerAlias.

Установка сертифіката в Web-браузер користувача

Проте при першій спробі увійти на сайт, де встановлений SSL-сертифікат, підписаний корпоративним СА, все одно виникне помилка, так як Web-браузер буде стверджувати, що виникла критична ситуація і це підроблений сертифікат. У Web-браузері Google Chrome буде відображена сторінка червоного кольору на весь екран, а в Mozilla Firefox - жовтого, при цьому обидві сторінки щоб отримувати повідомлення, що стався критичний збій в системі безпеки, як показано на малюнках 1 і 2.

Малюнок 1. Відображення невідомого сертифіката в Google Chrome
SSL-сертифікати Web-сайтів і їх застосування   Серія контенту:   Цей контент є частиною # з серії # статей: SSL-сертифікати Web-сайтів і їх застосування   https://www
Малюнок 2. Відображення невідомого сертифіката в Mozilla Firefox

Web-браузери виводять повідомлення, зображені на малюнках, так як не можуть перевірити, яка організація підписала цей сертифікат. Як уже згадувалося в минулій частині, система CA - ієрархічна, і сертифікати кореневих СА поширюються разом з Web-браузерами. У Google Chrome використовується сховище сертифікатів Windows, і його список кореневих сертифікатів може змінитися після установки пакета з оновленнями від Microsoft, а в Mozilla Firefox використовується власне сховище сертифікатів.

Оскільки даний сертифікат підписаний всередині самої організації, то її кореневий сертифікат у Web-браузера, звичайно, відсутня, і він вважає, що сталася помилка. Щоб виправити цю помилку, досить просто поширити на всі комп'ютери в локальній мережі сертифікат корпоративного СА (файл caserv.crt) ще до того моменту, як користувачі почнуть звертатися до корпоративних Web-ресурсів по протоколу HTTPS. Цей сертифікат буде потрібно встановити в системне сховище Windows і в сховище Firefox (а якщо використовується ще і Web-браузер Opera, то і в його власне сховище).

Процес установки сертифіката не представляє особливої ​​складності, однак система кілька разів уточнить: чи дійсно можна довіряти цьому видавцеві сертифікатів. Також необхідно звернути увагу, куди саме буде встановлений сертифікат: він повинен бути встановлений в "Довірені Кореневі Центри Сертифікації", а не в будь-яку іншу групу.

Перетворення SSL-сертифіката з одного формату в інший

Установка кореневого сертифіката на мобільний пристрій (наприклад, смартфон Nokia N95 8G) вимагає значно більше зусиль, так як смартфон не розуміє текстових сертифікатів (формат PEM). Тому в даному розділі розглядається процес перекодування сертифіката з одного формату в інший.

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

Перекодування сертифіката з формату PEM в формат DER виконується за допомогою такої команди:

# Openssl x509 -in caserv.crt -out caserv.cer -inform PEM -outform DER

Розширення файлу (.cer) - це стандартне розширення для сертифікатів формату DER. Цей формат підтримується великою кількістю обладнань, зокрема, згаданим вище смартфоном Nokia N95 8G. Зворотне перетворення з формату DER в формат PEM виконується подібним чином:

# Openssl x509 -in caserv.cer -out caserv.crt -inform DER -outform PEM

Для зворотного перетворення в команді досить просто поміняти порядок аргументів, але отриманий таким чином PEM-файл не буде містити текстової частини (вміст сертифіката, придатне для перегляду людиною), тому для створення сертифіката із заповненою текстовою частиною використовується інша команда:

# Openssl x509 -in caserv.crt -out caserv.pem -text

Якщо ж, навпаки, необхідно видалити з сертифіката текстову частину, то використовується наступна команда:

# Openssl x509 -in caserv.pem -out caserv.crt

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

Установка SSL-з'єднання з Web-сайтом

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

Малюнок 3. Встановлене SSL-З'єднання в Google Chrome
Малюнок 4. Встановлене SSL-З'єднання в Mozilla Firefox

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

Також може бути перевірено, відкликання даний сертифікат. Як було згадано в попередній статті, система повинна мати можливість блокування сертифікатів, які були видані людям, на даний момент покинули організацію. Тому в сертифікат можна додати параметри, які будуть розпізнаватися Web-браузерами. На підставі отриманої інформації Web-браузер зможе завантажити із зазначеної адреси CRL і перевірити, чи не входить сертифікат, який використовується для підключення, в список відкликаних. Якщо цей сертифікат присутній в списку відкликаних, то з'єднання буде заблоковано.

Важливе зауваження: посилання на CRL повинна вказуватися і в параметрі CRLDistributionPoint (як визначено в новій версії стандарту), так і в параметрі nsCaRevocationList - саме цей параметр зчитується багатьма Web-браузерами, і при його відсутності виникають повідомлення про відсутній списку CRL і т.д .

Обмеження можливості підключення для небажаних клієнтів

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

Лістинг 2. Додавання обмежень на підключення клієнтів

SSLCertificateChainFile "/etc/ssl/rootca/caserv.crt" SSLCACertificateFile "/etc/ssl/rootca/caserv.crt" SSLCARevocationFile "/etc/ssl/rootca/cacrl.crl" SSLVerifyClient require

Параметри SSLCertificateChainFile і SSLCACertificateFile задають сертифікат корпоративного СА, параметр SSLCARevocationFile визначає шлях до CRL, а параметр SSLVerifyClient активує перевірку клієнтського сертифіката. У цьому прикладі вводиться найпростіше обмеження: до сайту зможуть підключитися тільки ті користувачі, у яких на комп'ютерах встановлено клієнтський сертифікат, підписаний корпоративним СА. При цьому ніяких додаткових перевірок виконуватися не буде, якщо на клієнтському комп'ютері, який здійснює підключення до сервера, відсутня клієнтський сертифікат, то в установці підключення буде відмовлено, як показано нижче.

Малюнок 5. Сторінка з повідомленням про відмову в підключенні в Google Chrome
Малюнок 6. Сторінка з повідомленням про відмову в підключенні в Mozilla Firefox

Якщо простого умови про наявність SSL-сертифікату, підписаного корпоративним СА недостатньо, то на основі параметра SSLRequire можна реалізувати більш складні перевірки, які будуть враховувати різні параметри сертифіката.

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

В даному випадку може стати в нагоді такий прийом, як «зворотне проксінг», при якому, як і в разі звичайного проксінг, є деяка програма, яка працює на сервері і отримує запити з одного боку, а потім транслює їх на іншу. При цьому досить встановити захищене з'єднання тільки з самим проксі-сервером, з'єднання між проксі-сервером і захищеним Web-сайтом може виконуватися і без шифрування.

висновок

C точки зору організації безпечної ІТ-середовища Web-ресурси будь-якої компанії в першу чергу потребують захисту HTTP-трафіку, причому, як правило, необхідно не тільки згенерувати ключі для всіх використовуваних серверів, але і організувати їх поділ по портах, так як з- за вимог протоколу HTTPS на одному фізичному сервері на одному і тому ж порту можна розмістити кілька віртуальних Web-серверів з підтримкою HTTPS.

Додатково слід продумати питання, чи потрібно обмежити коло користувачів, які матимуть доступ до вказаних Web-ресурсів. Якщо така необхідність виникне, то для всіх користувачів буде потрібно згенерувати клієнтські SSL-сертифікати, забезпечити регулярне оновлення CRL для відкликання анульованих сертифікатів і активувати підтримку CRL на Web-сайті, доступ до якого має бути обмежений.

Ресурси для скачування

Схожі теми

  • SSL-сертифікати Web-сайтів і їх застосування. Частина 1 .
  • SSL-сертифікати Web-сайтів і їх застосування. Частина 2 .

Підпишіть мене на повідомлення до коментарів

Com/developerworks/ru/library/?
Категории
  • Биология
  • Математика
  • Краеведению
  • Лечебная
  • Наука
  • Физике
  • Природоведение
  • Информатика
  • Новости

  • Новости
    https://banwar.org/
    Наша взаимовыгодная связь https://banwar.org/. Запустив новый сайт, "Пари Матч" обещает своим клиентам незабываемый опыт и возможность выиграть крупные суммы.


    Наши клиенты
    Клиенты

    Быстрая связь

    Тел.: (044) 587-84-78
    E-mail: [email protected]

    Имя:
    E-mail:
    Телефон:
    Вопрос\Комментарий: