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

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. SSL-сертифікати Web-сайтів і їх застосування: Частина 2. Встановлення SSL-сертифікатів для клієнта...
  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. Ресурси для скачування
  15. SSL-сертифікати Web-сайтів і їх застосування: Частина 2. Встановлення SSL-сертифікатів для клієнта...
  16. Серія контенту:
  17. Цей контент є частиною серії: SSL-сертифікати Web-сайтів і їх застосування
  18. Установка серверного сертифіката
  19. Лістинг 1. Підключення SSL-сертифікатів
  20. Установка сертифіката в Web-браузер користувача
  21. Малюнок 1. Відображення невідомого сертифіката в Google Chrome
  22. Перетворення SSL-сертифіката з одного формату в інший
  23. Установка SSL-з'єднання з Web-сайтом
  24. Малюнок 3. Встановлене SSL-З'єднання в Google Chrome
  25. Обмеження можливості підключення для небажаних клієнтів
  26. Лістинг 2. Додавання обмежень на підключення клієнтів
  27. Малюнок 5. Сторінка з повідомленням про відмову в підключенні в Google Chrome
  28. висновок
  29. Ресурси для скачування
  30. SSL-сертифікати Web-сайтів і їх застосування: Частина 2. Встановлення SSL-сертифікатів для клієнта...
  31. Серія контенту:
  32. Цей контент є частиною серії: SSL-сертифікати Web-сайтів і їх застосування
  33. Установка серверного сертифіката
  34. Лістинг 1. Підключення SSL-сертифікатів
  35. Установка сертифіката в Web-браузер користувача
  36. Малюнок 1. Відображення невідомого сертифіката в Google Chrome
  37. Перетворення SSL-сертифіката з одного формату в інший
  38. Установка SSL-з'єднання з Web-сайтом
  39. Малюнок 3. Встановлене SSL-З'єднання в Google Chrome
  40. Обмеження можливості підключення для небажаних клієнтів
  41. Лістинг 2. Додавання обмежень на підключення клієнтів
  42. Малюнок 5. Сторінка з повідомленням про відмову в підключенні в Google Chrome
  43. висновок
  44. Ресурси для скачування

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

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
Малюнок 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 .

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

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

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
Малюнок 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 .

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

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

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

  • Новости
    Подготовка к ЕГЭ по математике
    Статьи Опубликовано: 05.10.2017 Подготовка к ЕГЭ по МАТЕМАТИКЕ. 1 часть. Эффективный курс подготовки. Вы находитесь на сайте www.ege-ok.ru - Подготовка к ЕГЭ по математике. Меня зовут Инна Владимировна

    Куда поступить с обществознанием, русским и математикой
    Статьи Опубликовано: 06.10.2017 Сдача ЕГЭ. Куда поступать? Обществознание считается одним из самых популярных предметов, которые выпускники сдают на ЕГЭ. Ввиду высокого рейтинга дисциплины Рособрнадзор

    Сайт Майер Елены - ЕГЭ по математике
    Планируется проведение двух отдельных экзаменов – базового и профильного. Кому сдавать базовый ЕГЭ по математике? Базовый ЕГЭ организуется для выпускников, изучающих математику для общего развития

    ГДЗ решебник по математике 4 класс
    Извините, тут пока ничего нет ((( Решебник по математике 4 класс (Истомина Н.Б.) – не просто возможность быстро выполнить домашнее задание для учащегося, но и способ разобраться в труднорешаемых задачах.

    ГДЗ по математике 1 класс Самсонова самостоятельные работы
    Решебник по математике за 1 класс автора Самсоновой Л.Ю. 2012 года издания. Данное пособие предлагает готовые решения на разнообразные упражнения, направленные на активизацию всего учебного процесса. Здесь

    Для этой работы нужна математика
    Слотов: 956 Рулеток: 7 Лицензия: Pragmatic Play, Microgaming, ELK, Yggdrasil, Habanero, Amatic, Isoftbet, Netent, Rival, Igrosoft, Quickspin. Игры: Автоматы, Покер, Рулетки. Всего 963 Отдача: 98% Бонус

    Веселые задачи по математике 2 класс
    Во время занятий для того, чтобы немного переключить внимание школьников, но при этом не уйти от предмета, можно давать шутливые задачи на сообразительность. Буду пополнять коллекцию таких задач. Дополнительная

    Функция экспонента в Excel
    Одной из самых известных показательных функций в математике является экспонента. Она представляет собой число Эйлера, возведенное в указанную степень. В Экселе существует отдельный оператор, позволяющий

    ЕГЭ по математике 2018
    ЕГЭ по математике, наравне с русским языком , – обязательный экзамен для сдачи выпускниками 11-х классов. По статистике он самый сложный. Мы предлагаем ознакомиться с общей информацией об экзамене и

    Секреты эффективной и быстрой подготовки ко второй части ОГЭ по математике.
    Уважаемые девятиклассники, настоящие или будущие! Часто от вас приходится слышать следующие вопросы. Легко ли подготовиться к заданиям второй части ОГЭ по математике? Сколько для этого понадобится


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

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

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

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