TLS і SSL згадуються останнім часом все частіше і частіше, більш актуальним стає використання цифрових сертифікатів, і навіть з'явилися компанії, які готові безкоштовно надавати цифрові сертифікати всім бажаючим, щоб гарантувати шифрування трафіку між відвідуваними сайтами та браузером клієнта. Потрібно це, звичайно, для безпеки, щоб ніхто в мережі не міг отримати дані, які передаються від клієнта серверу та назад. Як це все працює і як це використовувати? Щоб це зрозуміти, треба, мабуть, почати з теорії, а потім показати на практиці. Отже, SSL та TLS.
Що таке SSL та що таке TLS?
SSL – Secure Socket Layer, рівень захищених сокетів. TLS - Transport Layer Security, безпека транспортного рівня. SSL є більш ранньою системою, TLS з'явився пізніше і заснований на специфікації SSL 3.0, розробленої компанією Netscape Communications. Проте завдання цих протоколів одне — забезпечення захищеної передачі між двома комп'ютерами у мережі Інтернет. Таку передачу використовують для різних сайтів, для електронної пошти, для обміну повідомленнями та багато чого. В принципі, можна передавати будь-яку інформацію таким чином, про це трохи нижче.
Безпечна передача забезпечується за допомогою аутентифікації та шифрування інформації, що передається. Насправді ці протоколи, TLS і SSL, працюють однаково, важливих відмінностей немає. TLS, можна сказати, є наступником SSL, хоча вони і можуть використовуватися одночасно, причому навіть на тому самому сервері. Така підтримка необхідна для того, щоб забезпечити роботу як з новими клієнтами (пристроями та браузерами), так і застарілими, які TLS не підтримують. Послідовність виникнення цих протоколів має такий вигляд:
SSL 1.0 - ніколи не публікувався
SSL 2.0 - лютий 1995 року
SSL 3.0 - 1996 рік
TLS 1.0 - січень 1999 року
TLS 1.1 - квітень 2006 року
TLS 1.2 - серпень 2008 року
Принцип роботи SSL та TLS
Принцип роботи SSL і TLS, як я вже сказав, той самий. Поверх протоколу TCP/IP встановлюється зашифрований канал, у якому передаються дані з прикладного протоколу — HTTP, FTP, тощо. Ось як це можна уявити графічно:
Прикладний протокол "загортається" в TLS/SSL, а той у свою чергу в TCP/IP. По суті дані прикладного протоколу передаються по TCP/IP, але вони зашифровані. І розшифрувати дані, що передаються, може тільки та машина, яка встановила з'єднання. Для всіх інших, хто отримає пакети, що передаються, ця інформація буде безглуздою, якщо вони не зможуть її розшифрувати.
Установка з'єднання забезпечується у кілька етапів:
1) Клієнт встановлює з'єднання з сервером та запитує захищене підключення. Це може забезпечуватися або встановленням з'єднання на порт, який спочатку призначений для роботи з SSL/TLS, наприклад, 443, або додатковим запитом клієнта встановлення захищеного з'єднання після встановлення звичайного.
2) При встановленні з'єднання клієнт надає список алгоритмів шифрування, які він знає. Сервер звіряє отриманий список зі списком алгоритмів, які «знає» сам сервер, і вибирає найбільш надійний алгоритм, після чого повідомляє клієнта, який алгоритм використовувати
3) Сервер відправляє клієнту свій цифровий сертифікат, підписаний центром, що засвідчує, і відкритий ключ сервера.
4) Клієнт може зв'язатися із сервером довіреного центру сертифікації, який підписав сертифікат сервера, та перевірити, чи валідний сертифікат сервера. Але може не зв'язуватися. В операційній системі зазвичай вже встановлені кореневі сертифікати центрів сертифікації, з якими звіряють підписи серверних сертифікатів, наприклад, браузери.
5) Генерується сеансовий ключ для захищеного з'єднання. Це робиться так:
— Клієнт генерує випадкову цифрову послідовність
— Клієнт шифрує її відкритим ключем сервера та посилає результат на сервер
— Сервер розшифровує отриману послідовність за допомогою закритого ключа
Враховуючи, що алгоритм шифрування є асиметричним, розшифрувати послідовність може лише сервер. При використанні асиметричного шифрування використовують два ключі — приватний і публічний. Публічним повідомлення, що надсилається, шифрується, а приватним розшифровується. Розшифрувати повідомлення, маючи публічний ключ не можна.
6) У такий спосіб встановлюється зашифроване з'єднання. Дані, що передаються ним, шифруються і розшифровуються до тих пір, поки з'єднання не буде розірвано.
Кореневий сертифікат
Трохи вище я згадав про кореневий сертифікат. Це сертифікат авторизаційного центру, підпис яким підтверджує, що підписаний сертифікат є саме тим, що належить відповідному сервісу. У самому сертифікаті зазвичай міститься ряд інформаційних полів, в яких міститься інформація про ім'я сервера, якому видано сертифікат, та терміни дії цього сертифіката. Якщо термін дії сертифіката минув, він визнається недійсним.
Запит на підпис (CSR, Certificate Sign Request)
Для отримання підписаного серверного сертифіката необхідно згенерувати запит на підпис (CSR, Certificate Sign Request) і відправити цей запит до авторизаційного центру, який поверне підписаний сертифікат, що встановлюється безпосередньо на сервер, трохи нижче подивимося, як це зробити на практиці. Спочатку генерується ключ для шифрування, потім на підставі цього ключа генерується запит на підпис CSR-файл.
Клієнтський сертифікат
Сертифікат клієнта може бути згенерований як для використання в пристроях, так і для використання користувачами. Зазвичай такі сертифікати використовуються при двосторонній верифікації, коли клієнт верифікує, що сервер дійсно той, за кого себе видає, і сервер у відповідь робить те саме. Така взаємодія називається двосторонньою аутентифікацією або mutual authentication. Двостороння автентифікація дозволяє підвищити рівень безпеки порівняно з односторонньою, а також може бути заміною автентифікації з використанням логіну та пароля.
Ланцюжок дій із генерації сертифікатів
Давайте подивимося практично, як відбуваються дії, пов'язані з генерацією сертифікатів, від початку, і навіть на практиці.
Перше, що робиться – це генерація кореневого сертифікату. Кореневий сертифікат підписується самим собою. А потім уже цим сертифікатом підписуватимуться інші сертифікати.
$ openssl genrsa -out root.key 2048 Generating RSA private key, 2048 bit long modulus ..........+++ ................... ........................+++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr You are про те, щоб отримати інформацію про те, що буде введено в ваш Certificate Request. What you are about to enter is what is called a Distinguished Name or a DN. Там існують кілька філій, але ви можете скористатися деяким бланк. ----- Country Name (2 letter code) :UA State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :IT Service Common Name (e.g. server FQDN або YOUR name) :My Company Root Certificate Email Address : [email protected]Подивіться на наступні "extra" atributes для того, щоб бути з вашим відповідним запитом повідомлень повідомлень : Мій компанії $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signature OK subject = / C = RU / ST = N / A / L = Saint-Petersburg / O = My Company / OU = IT Service / CN = My Company Root Certificate / [email protected] Getting Private key
Таким чином ми згенерували спочатку приватний ключ, потім запит підпису, а потім своїм ключем підписали свій запит і отримали власний цифровий сертифікат, виданий на 10 років. Пароль (challenge password) під час створення сертифіката можна не вводити.
Приватний ключ ОБОВ'ЯЗКОВО необхідно зберігати у надійному місці, маючи його можна підписати від вашого імені будь-який сертифікат. А отриманий кореневий сертифікат можна використовувати для ідентифікації того, що сертифікат, наприклад сервера підписаний саме нами, а не кимось ще. Саме такі дії виконують авторизаційні центри, коли генерують власні сертифікати. Після створення кореневого сертифіката можна приступати до створення сертифіката сервера.
Перегляд інформації про сертифікат
Вміст сертифіката можна переглянути таким чином:
$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/ [email protected] notAfter=Jan 22 11:49:41 2025 GMT
Ми бачимо, хто видав цей сертифікат і коли закінчується термін його придатності.
Серверний сертифікат
Для підпису сертифіката для сервера нам потрібно виконати такі дії:
1) Згенерувати ключ
2) Згенерувати запит на підпис
3) Надіслати CSR-файл до авторизаційного центру або підписати самостійно
Сертифікат сервера може включати ланцюжок сертифікатів, яким підписано сертифікат сервера, але його можна також зберігати в окремому файлі. У принципі виглядає все приблизно так само, як і при генерації кореневого сертифіката
$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus ................................ .................................................. .+++ ..........................+++ e is 65537 (0x10001) $ openssl req -new -key server.key - out server.csr Ви повинні бути введені в інформацію про те, що буде введено в вашій довідковій системі. What you are about to enter is what is called a Distinguished Name or a DN. Там існують кілька філій, але ви можете скористатися деяким бланк. ----- Country Name (2 letter code) :UA State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) [email protected]Подивіться на наступні "extra" atributes для того, щоб бути з вашим відповідним запитом повідомлень повідомлень : Оцінка імені користувача : $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem-days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =My Company Root Certificate/ [email protected] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [email protected] notAfter=Jan 25 12:22:32 2016 GMT
Таким чином, сертифікат сервера підписаний і ми будемо знати, якою організацією виданий цей сертифікат. Після підпису готовий сертифікат можна використовувати за призначенням, наприклад, встановити на веб-сервер.
Встановлення SSL/TLS-сертифіката на сервер з nginx
Для встановлення SSL/TLS-сертифіката на веб-сервер nginx потрібно виконати кілька простих кроків:
1) Скопіювати файли.key і.pem на сервер. У різних операційних системах сертифікати та ключі можуть зберігатися в різних директоріях. У Debian'і, наприклад, це директорія /etc/ssl/certs для сертифікатів та /etc/ssl/private для ключів. У CentOS це /etc/pki/tls/certs та /etc/pki/tls/private
2) Прописати необхідні налаштування конфігураційний файл для хоста. Ось як це приблизно має виглядати (це просто приклад):
Server ( listen 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # Не рекомендується використовувати SSLv3 !!! # тільки для прикладу ssl_protocols SSLv3 TLSv1;ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;ssl_prefer_server_ciphers on;location/ )
3) Перезапустити nginx
4) Зайти браузером на 443 порт сервера - https://www.mycompany.com та перевірити його працездатність.
Встановлення SSL/TLS-сертифіката на сервер з Apache
Установка SSL/TLS-сертифіката на Apache виглядає приблизно так само.
1) Скопіювати файли ключа та сертифіката на сервер у відповідні директорії
2) Увімкнути модуль ssl для Apache командою "a2enmod ssl", якщо він ще не включений
3) Створити віртуальний хост, який слухатиме 443 порти. Конфіг виглядатиме приблизно так:
При цьому треба зробити ще щось. Знайти у файлі httpd.conf, або apache2.conf, або ports.conf, залежно від системи, таку ділянку конфігу:
Якщо такої умови немає, його треба додати до конфігу. І ще одне: Треба додати рядок
NameVirtualHost *:443
Цей рядок може бути у файлі httpd.conf, apache2.conf або ports.conf
4) Перезапустити веб-сервер Apache
Створення клієнтського сертифікату
Клієнтський сертифікат створюється приблизно так, як серверний.
$ openssl genrsa -out client.key 2048 Generating RSA private key, 2048 bit long modulus ........................+++ ..... .............................................+++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Ви повинні бути введені в інформацію про те, що буде введено в свій довідковий запит. What you are about to enter is what is called a Distinguished Name or a DN. Там існують кілька філій, але ви можете скористатися деяким бланк. ----- Country Name (2 letter code) :UA State or Province Name (full name) :Saint-Petersburg Locality Name (eg, city) :^C [email protected]:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Ви повинні бути введені до введення інформації про те, що буде введено в свій довідковий запит. What you are about to enter is what is called a Distinguished Name or a DN. Там існують кілька філій, але ви можете скористатися деяким бланк. ----- Country Name (2 letter code) :UA State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petrersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :Engineering Common Name (e.g. server FQDN або YOUR name) :Ivan Ivanov Email Address : [email protected]Подивіться на наступні "extra" atributes для того, щоб бути з вашим відповідним запитом повідомлень повідомлень : Оцінка імені користувача : $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/ [email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =My Company Root Certificate/ [email protected] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/ [email protected] notAfter=Jan 25 13:17:15 2016 GMT
Якщо потрібний клієнтський сертифікат у форматі PKCS12, створюємо його:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Enter Export Password: Verifying - Enter Export Password:
Тепер можна використовувати сертифікат клієнта для роботи з нашим сервером.
Налаштування nginx на використання клієнтських сертифікатів
Найчастіше, як я вже сказав, використовується одностороння автентифікація, зазвичай перевіряється лише сертифікат сервера. Давайте подивимося, як змусити веб-сервер nginx перевіряти клієнтський сертифікат. Необхідно до секції server додати опції для роботи з клієнтськими сертифікатами:
# Кореневий сертифікат(и), яким(и) підписано клієнтський ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Можливі варіанти: | off | optional | optional_no_ca ssl_verify_client optional; # Глибина перевірки ланцюжка сертифікатів, якими підписано клієнтський ssl_verify_depth 2;
Після цього потрібно перезавантажити налаштування або сервер повністю і можна перевіряти роботу.
Налаштування Apache на використання клієнтських сертифікатів
Apache налаштовується також через додавання додаткових опцій до секції віртуального хоста:
# Директорія, що містить кореневі сертифікати для перевірки клієнтів SSLCARevocationPath /etc/apache2/ssl.crl/ # або файл, що містить сертифікати SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Опція верифікації клієнта. Можливі варіанти: # none, optional, require and optional_no_ca SSLVerifyClient require # Глибина перегляду ланцюжка підписів. Типово 1 SSLVerifyDepth 2
Як бачите, опції приблизно такі самі, як і для nginx, оскільки процес перевірки організований однаково.
«Прослуховування» інформації про сертифікат за допомогою openssl
Для перевірки взаємодії сервера з клієнтськими сертифікатами можна перевірити, чи з'єднання з'являється з використанням TLS/SSL.
На стороні сервера запускаємо прослуховування порту за допомогою openssl:
Openssl s_server -accept 443 -cert server.pem -key server.key -state
На стороні клієнта звертаємося до сервера, наприклад, culr'ом:
Curl-k https://127.0.0.1:443
У консолі сервера можна спостерігати процес обміну інформацією між сервером і клієнтом.
Також можна використовувати опції -verify [глибина перевірки] та -Verify [глибина перевірки]. Опція з невеликої літери запитує у клієнта сертифікат, але він не повинен його надавати. З великої літери – якщо сертифікат не надано, виникне помилка. Запустимо прослуховування з боку сервера таким чином:
Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3
З боку сервера помилка виглядає так:
140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:Peer did не відновить certificate:s3_srvr.c:3287:
З боку клієнта так:
Curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Додамо з клієнтської сторони сертифікат та доменне ім'я (можна для перевірки вписати у файл /etc/hosts ім'я хоста для адреси 127.0.0.1):
Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key
Тепер з'єднання пройде успішно і можна встановлювати серверний сертифікат на веб-сервер, клієнтський віддати клієнту, і працювати з ними.
Безпека
При використанні SSL/TLS одним із основних методів є метод MITM (Man In The Middle), "людина посередині". Цей метод ґрунтується на використанні серверного сертифіката та ключа на якомусь вузлі, який прослуховуватиме трафік і розшифровуватиме інформацію, якою обмінюються сервер та клієнт. Для організації прослуховування можна використовувати, наприклад, програму sslsniff. Тому кореневий сертифікат і ключ зазвичай бажано зберігати на машині, яка не підключена до мережі, для підписання приносити запити на підпис на флешці, підписувати і так само виносити. І, звичайно, робити резервні копії.
Загалом саме так і використовуються цифрові сертифікати та протоколи TLS та SSL. Якщо є запитання/доповнення, пишіть у коментарі.
Запис опублікований автором у рубриці з мітками , .Навігація за записами
: 29 коментарів
cl-service.com
CSR клієнт генерує сам при замовленні сертифіката, де зберігати закритий ключ також вирішує клієнт, для випуску сертифіката нам не потрібний закритий ключ і клієнт нам його не передає. Якщо це відбувається на звичайному віртуальному, то у адміністраторів з root доступом до сервера є доступ і до ключів, які там зберігаються.
- Доброзичник.
Тема цицьок не розкрита, бо описана технологія роботи PKI не має нічого спільного із заголовком теми. Хоч би для причин посилання на rfc навів.
P.S. Був такий анекдот про собаку та блоху. - Доброзичник.
У жодному разі не хотів тебе образити. Шукав інфу про відмінність SSl і TLS на практиці і твоє посилання в куті було перше. Був зацікавлений назвою теми. Все круто, то тримати!
- DrAibolit
Дякую за тлумачні пояснення про цифрову сертифікацію. Я новачок у цьому =)
Сподіваюся роз'яснити наступне питання.
Оскільки в інтернет індустрії дуже розвинена тема шахрайства, хотілося б навчитися визначати на «вошивість» сайти, що самостійно відвідуваються (особливо, де присутні кашельки та оплати, інвестиції тощо) і визначати виходячи з цього ступінь моєї довіри (доводиться часто реєструватися, залишати особисту інформацію, здійснювати покупки, транзакції, інвестиції). Якщо я правильно зрозумів, що наявність цієї сертифікації дозволяє зробити таку оцінку. Ну і з іншого боку, отримати її не є проблемою і навіть безкоштовно.
Як або за допомогою якої програми можна визначити наявність цифрового сертифіката того чи іншого сайту? та бажано його категорію, яка присвоюється при видачі спецорганом SSL DV (видача сертифіката проводиться з перевіркою лише домену), SSL OV (з перевіркою організації), EV (з розширеною перевіркою юрособи). Шахрайські сайти швидше за все останнім варіантом сертифікації користуватися не стануть.
Буду радий, якщо розкажете ще способи визначення надійності сайтів))- mnorinАвтор запису
Якоїсь певної програми для цих цілей я ще не зустрічав, але кілька порад із цього приводу можу дати.
Можна використовувати, наприклад, Chromium або Google Chrome. Візьмемо, наприклад, сайт https://www.thawte.com/ - компанія, яка власне цифровими сертифікатами і займається.
В адресному рядку буде написано назву компанії та зелений замочок. Це означає, що організація перевірена, це щонайменше SSL OV.
Якщо клікнути на замочок, а у вікні «Details», а потім «View Certificate», то можна побачити інформацію про сертифікат. Для Thawte сертифікат підписаний наступним сертифікатом: Thawte Extended Validation SHA256 SSL CA, а сертифікат для click.alfabank.ru теж підписаний Thawte, але іншим сертифікатом. Це "thawte EV SSL CA - G3", тобто вони також проходили Extended Validation.
Якось так.
- mnorinАвтор запису
- Руслан
Розділ «Принцип роботи SSL та TLS», «Клієнт генерує випадкову цифрову послідовність».
Я був впевнений, що клієнт генерує сеансовий закритий і, відповідно, відкритий ключі (який ви, очевидно, назвали «цифрова послідовність»). Відкритий ключ передається серверу та сервер шифрує пакети у бік клієнта сеансовим відкритим клієнтським ключем.
Уточніть будь ласка.
- Новачок
Стаття дуже корисна! Навіть є практичні приклади=) Тільки я не зрозумів одну річ — у чому різниця між кореневим сертифікатом та серверним? чи це одне й теж?
- Віталій
Добрий день.
Хостер запропонував послугу – SSL для віртуальних серверів. Скористалися. Виявилося, що з третього рівня, тобто. http://www.site.ru сертифікат недійсний, тільки для site.ru. Причому відвідувачів наполегливо кидає на протокол https, не важливо, чи заходять вони на site.ru або на http://www.site.ru. Зрозуміло, у другому випадку браузер починає несамовито лаятися, а відвідувач до сайту так і не добирається.
А для тих, хто до сайту таки дістався, сайт став виглядати криво, зникла частина меню, перестала відображатися частина картинок у видачі деякими компонентами.
Додаткові параметри сервера веб-доступу
Налаштування захищеного з'єднання (на основі Secure Socket Layers, SSL)
За потреби можна налаштувати захист з'єднаньз сервером веб-доступу до DIRECTUM : інформація, що передається каналами зв'язку, буде шифруватися. Для того щоб можна було працювати із захищеними з'єднаннями, зробіть наступне:
1. Змініть конфігураційний файл сервера веб-доступу:
· Крок 1. Запустіть утиліту конфігурування сервера веб-доступу C :\ Program Files \ DIRECTUM Company \ WebAccessConfig \DirWebConfigurator.exe.
· Крок 2. Вікно «Вибір веб-сайту Сервера веб-доступу DIRECTUM»:
а) у списку, що випадає, виберіть веб-сайт сервера веб-доступу до DIRECTUM . За промовчанням він має назву «Сервер веб-доступу до DIRECTUM»;
б) Натисніть на кнопку OK ;
· Крок 3. Вікно «Параметри сервера веб-доступу до DIRECTUM », закладка «Загальні»:
а) у списку «Захищене з'єднання» виберіть «Для віддалених». Якщо потрібно встановити захищене з'єднання і для користувачів локальної мережі, виберіть «Для віддалених і локальних»;
б) Натисніть на кнопку OK .
2. Налаштуйте IIS на роботу з SSL -з'єднаннями, встановивши сертифікат автентифікації сервера. Для цього генерується сертифікат із призначенням «Забезпечує отримання ідентифікації від віддаленого комп'ютера» з можливістю експорту до служби сертифікації підприємства, внаслідок чого необхідно отримати *. pfx -Файл закритого ключа.
3. Якщо ви використовуєте веб-службу сертифікації Windows , то зробіть таке:
а) під час створення сертифіката вкажіть опцію можливого експорту сертифіката. Після того, як сертифікат встановлений у локальній системі, його можна переглянути за допомогою Internet Explorer – пункт меню «Властивості браузера», закладка «Зміст», кнопка Сертифікати . Для експорту використовуйте кнопку Експорт , вкажіть Так, експортувати закритий ключ, та вкажіть пароль.
б) Імпортуйте сертифікат. Для цього на закладці «Безпека каталогу» картки властивостей веб-сайту натисніть кнопку Сертифікати і, дотримуючись інструкцій на екрані, імпортуйте сертифікат, вказавши пароль, який було встановлено на попередньому кроці. Після прийому сертифіката встановиться порт захищеного з'єднання 443 та робота через SSL стане можливим.
4. Щоб підтримувалися і відкриті (незахищені) з'єднання, потрібно встановити опцію Дозволити підтримку відкритих з'єднань HTTPна закладці «Веб-сайт» властивостей веб-сайту.
5. Для того щоб можна було встановити сертифікат центру, що посвідчує, за посиланням зі сторінки входу, необхідно користувачеві, від якого запускається група додатків « DIRECTUM », дозволити «Читання» та «Запит сертифікатів» у оснащенні «Центр сертифікації» у властивостях потрібного центру сертифікації на закладці «Безпека».
Див. також:
Налаштування платіжних систем
Налаштування платіжних систем багато в чому залежить від того, як надає зв'язок зі своїми терміналами сам оператор платіжної системи. Як правило, якщо використовуються термінали міських платежів, то використовується захищене SSL-з'єднання і вам потрібно включити та налаштувати для зв'язку з терміналами SSL WEB-сервер як показано нижче. Якщо для проведення платежів використовуються веб-сайти в інтернеті, то, як часто в таких випадках потрібно налаштовувати саме http сервер на Carbon Billing. Попередньо обов'язково уточніть у вашого оператора платіжних систем за яким саме протоколом зв'язку він надає підключення до своїх терміналів оплати перед налаштуванням Carbon Billing.
SSL WEB-сервер для платежів має кілька параметрів, значення яких наведено нижче.
Увімкнути SSL WEB-сервер для платежів- Якщо оператор платіжної системи здійснює роботу з терміналами оплати SSL, то потрібно включити саме SSL WEB-сервер.
IP-адреса для підключення за HTTPS- адреса для підключення терміналів або сайтів платіжних систем для платежу клієнту в БД Carbon Billing.
Порт для підключення по HTTPS- за замовчуванням використовується порт 1443. Якщо необхідно змінити цей порт, то по можливості вказуйте порти вище 1024.
Дозволені адреси клієнтів для SSL WEB-сервера
Домен для сертифіката серверного SSL- вкажіть ваш публічний домен або окремо зареєстрований для сервера платежів на Carbon Billing домен. Опція не обов'язкова і дозволяє звернутися до SSL-WEB-сервера по домену імені замість IP-адреси.
Вимагати та перевіряти клієнтський сертифікат- Обов'язково відзначити якщо настроюєте веб-інтерфейс касира. Якщо ви налаштовуєте роботу з платіжною системою, то уточніть необхідність перевірки клієнтського сертифіката у оператора платіжної системи.
Створити клієнтський сертифікат- Буде створено клієнтський сертифікат, який потрібно надати оператору платіжної системи. Сертифікат із суфіксом.pfx буде доступний на сервері в каталозі /var/lib/usrcert і матиме ім'я файлу, що дорівнює CN-імені, вказаному вами при створенні сертифіката. Завантажити файл сертифіката із сервера можна програмою winscp.
У разі налаштування HTTP WEB-сервера для платежів.
Увімкнути HTTP-сервер для платежів- Якщо оператор платіжної системи здійснює роботу з терміналами оплати по відкритому http-з'єднанню, увімкніть саме HTTP-сервер.
IP-адреса для підключення по HTTP- адреса веб-сервера для підключення до нього терміналів або серверів платежів.
Порт для підключення по HTTP- за промовчанням використовується порт 1444. Якщо є потреба змінити цей порт, то по можливості вказуйте порти вище 1024.
Дозволені адреси клієнтів для HTTP-сервера- якщо не вказано, доступ буде відкритий всім.
Якщо ви користуєтеся послугами операторів платіжних систем, зазначеними нижче на цій вкладці, увімкніть відповідні пункти меню. У майбутньому ці прапорці будуть встановлювати специфічні налаштування системи, необхідні для кожного оператора, який ви використовуєте. Якщо ваш оператор не входить до перелічених нижче, то не включайте жоден з них.
При налаштуванні системи платежів Robokassa не забудьте вказати секретний пароль, необхідний для організації з'єднання між терміналом та сервером.
Критичність параметра subjectAltName ssl-сертифікатів
Під час створення ssl-сертифікатів для сервера, наприклад для https-сервера платежів, використовується розширення subjectAltName. Історично по дефолту це розширення у сертифікаті позначається як критичне, що може призвести до проблем при інтеграції білінгу з деякими платіжними системами.
Під час створення клієнтських сертифікатів subjectAltName не задається.
Критичність параметра скасовується опцією в локальній консолі "Конфігурування сервера - Додаткові налаштування - Налаштування для розробників - Не робити SSL параметр AltName критичним".
Після включення цієї опції всі новостворені серверні сертифікати генеруватимуться з некритичним розширенням subjectAltName. Старий сертифікат для https-сервера платежів доведеться перегенерувати вручну таким чином:
1. Перемонтуємо в rw розділ, на якому лежить конфіг (для цього має бути включений режим віддаленого помічника):
Mount -o rw, remount /mnt/bk_disc/
2. Відкриваємо редактором файл /etc/ics/ics.conf та коментуємо рядок з MHTTPD_F_CERT .
3. Перезапускаємо https-сервер платежів:
/etc/init.d/mhttpd_F restart
Зміна сертифіката у https-сервера платежів не зачіпає згенеровані раніше клієнтські сертифікати для касирів або платіжних систем.
Налаштування прийому платежів за http без шифрування
При необхідності здійснювати прийом платежів від платіжних систем за незахищеним протоколом http необхідно зробити наступні опції:
1) Включити http сервер прийому платежів.
2) Вказати IP адресу, на якій повинен працювати прийом запитів. Ця адреса має належати одному з інтерфейсів Carbon Billing:
Потім вказати порт, на якому прийматиме запити запити сервер.
3) Зробити список IP адрес, з яких прийматимуться запити. Це дуже важливий крок, оскільки http не передбачає авторизацію платіжної системи через сертифікат:
За промовчанням з HTTP можуть працювати протоколи платіжної системи Робокасса та Унікасу. Якщо потрібно, наприклад, приймати запити на http за протоколом ОСМП необхідно зробити таке:
1) Завантажити сервер у режимі уд. помічника і підключитися через ssh під користувачем root.
2) Виконати такі команди:
Mount -o rw, remount /mnt/ro_disc chattr -i -R /var /www/fiscal/htdocs/http/ cp /var /www/fiscal/htdocs/osmp.php /var /www/fiscal/htdocs/http/ osmp.php chown mhttpd_F:mhttpd_F /var /www/fiscal/htdocs/http/osmp.php
Потрібно відредагувати рядок у скрипті:
Mcedit /var /www/fiscal/htdocs/http/osmp.php рядок: include "../include/class_page.php"; замінюємо на: include "../../include/class_page.php";
Зберігаємо файл та виходимо з редактора.
Після м'якого перезавантаження модуль прийому платежів за протоколом ОСМП буде доступний за адресою http://1.1.1.1:1444/osmp.php з IP-адреси 2.2.2.2.
Доступ за негативного балансу
Може бути реалізований двома способами:
- Через редактор правил та мереж тарифу;
- Через [файл додаткових параметрів ics_tune.sh]
Ми випустили нову книгу «Контент-маркетинг у соціальних мережах: Як засісти в голову передплатників та закохати їх у свій бренд».
Світ збожеволів на інтернет-безпеці. Якщо ви в тренді і переписуєтеся виключно в "Телеграмі", то почитайте про те, як встановити на сайт захищеного з'єднання. Він стане в нагоді в будь-якому випадку, а якщо ви інтернет-магазин, то без нього взагалі не можна буде обійтися. Принагідно розповімо про сертифікати: що це таке і для чого вони потрібні.
Що таке HTTPS
Це протокол захищеного з'єднання. Він шифрує інформацію, якою обмінюється сервер та браузер користувача – це допомагає захистити дані про паролі, номери кредиток та адреси електронної пошти. Використання HTTPS сильно і робить його трохи привабливішим в очах пошукових систем - Google ранжує захищені сайти вище, ніж незахищені. Щоб увімкнути протокол HTTPS на своєму сайті, потрібно спочатку встановити на сервері SSL-сертифікат.
Для чого потрібний сертифікат SSL
Він формує унікальний цифровий підпис сайту, який допомагає захистити з'єднання. Без сертифіката SSL отримати протокол HTTPS не вийде, як не намагайся. У ньому міститься:
- домен сайту;
- повна юридична назва компанії-власника;
- фізична адреса компанії;
- термін дії сертифіката;
- реквізити розробника SSL
Сертифікат знадобиться для підключення будь-якої платіжної системи, наприклад «Яндекс.Грошей». Логіка проста – ніхто не дозволить вам ризикувати чужими грошима.
Як вибрати SSL-сертифікат
Вони поділяються на два типи, залежно від ступеня захисту та .
Domain Validation SSL
Найпростіший варіант. Запрацює після того, як ви підтвердите володіння доменом. Зробити це можна трьома способами:
- Через електронну пошту. Вам на пошту прийде лист із інструкцією з верифікації. Як адреса відправки вибирається або пошта з Whois домену, або ящики адміну чи вебмайстра.
- Через запис DNS. Якщо у вас налаштований сервер електронної пошти, створіть спеціальний запис DNS. По ній система і підтвердить, що ви справді власник сайту. Метод автоматизований і підходить тим, у кого пошта Whois прихована у налаштуваннях.
- Через хеш-файл. Розмістіть спеціальний.txt файл у себе на сервері, щоб центр сертифікації зміг встановити його наявність.
Така верифікація підійде, якщо у вас особистий блог або невеликий офлайновий бізнес, тому що вона не дозволяє захищати субдомени та проводити фінансові операції. Плюс, для підтвердження чистоти домену та ваших помислів не потрібно робити нічого складного, а готовий сертифікат робиться швидко.
Business Validation
Цей вид сертифіката SSL надійніший, тому що ви підтверджуєте факт зв'язку компанії з сайтом. Для цього потрібно надіслати до верифікаційного центру кілька документів та прийняти дзвінок на корпоративний номер. Business Validation-сертифікати поділяються на 3 види:
- Extended Validation SSL. Це сертифікати із розширеною перевіркою. Вони потрібні всім, хто працює з великим обсягом грошей: банкам, великим інтернет-магазинам, фінансовим компаніям, платіжним системам.
- Wildcard SSL. Такий сертифікат захищає і сам сайт, і його піддомен. Причому їх може бути будь-яка кількість, а вони можуть розташовуватися на різних серверах. Обов'язковий, якщо ви використовуєте піддомени з різними регіональними прив'язками або різними проектами.
- SAN SSl. Головна перевага цього сертифікату – підтримка альтернативних доменних імен: і зовнішніх, і внутрішніх.
- CodeSigning SSL. Підтверджує коду та програмних продуктів з сайту. Підійде розробникам будь-яких програм.
Чи можна встановити на свій сайт безкоштовний SSL-сертифікат?
Так. Більшість таких продуктів є платними, але є й варіанти, за які не доведеться віддавати гроші. Це базові сертифікати з валідацією домену. Вони не дозволять прикрутити до ресурсу онлайн-касу, але захистити з'єднання користувача із сервером зможуть. Такі SSL підійдуть невеликим інформаційним сайтам чи офлайн-бізнесам. Приклад – базовий сертифікат StartSSL.
Встановлення сертифіката SSL
Спочатку потрібно згенерувати запит CSR отримання сертифіката. У ньому міститься вся інформація про господаря домену та відкритий ключ. Більшість постачальників SSL дозволяють це зробити в процесі замовлення сертифіката, але згенерувати запит можна і на стороні веб-сервера.
У процесі генерації ключа CSR потрібно вказати:
- Ім'я сервера: "site.com" або "*.site.com", якщо отримуєте WIldcard сертифікат. Зірочка означає будь-яку кількість будь-яких символів перед точкою.
- Код країни: RU, UA, KZ і таке інше.
- Область, наприклад, Saratov Region.
- Місто.
- Повна назва організації чи ім'я власника сайту.
Запит CSR надсилається до центру верифікації. На виході ви отримуєте сертифікат SSL та файл із приватним ключем, який не можна втрачати та викладати у відкритий доступ.
Після цього необхідно встановити сертифікат на веб-сервер. Розглянемо випадки з Apache та nginx.
Apache
Щоб це зробити, потрібно завантажити на сервер усі сертифікати: і основні, і проміжні. Насамперед потрібно останній у директорію /usr/local/ssl/crt (використовується за умовчанням, у вашому випадку може відрізнятися). У ній зберігатимуться всі сертифікати.
Після цього скачайте основний сертифікат, відкрийте його в будь-якому текстовому редакторі та повністю скопіюйте вміст разом із рядками «BEGIN» та «END».
У директорії /ssl/crt/ створіть файл vashsite.crt і вставте вміст сертифіката.
Файл приватного ключа перемістіть до директорії /usr/local/ssl/private/
У файлі VirtualHost додайте рядки:
SSLEngine on
SSLCertificateKeyFile /usr/local/ssl/private/private.key
SSLCertificateFile /usr/local/ssl/crt/vashsite.crt
SSLCertificateChainFile /usr/local/ssl/crt/intermediate.crt
Вказувати потрібно дійсні шляхи до файлів. Збережіть зміни та перезапустіть сервер.
nginx
Тут процес встановлення SSL сертифіката трохи відрізняється. Спочатку потрібно об'єднати кореневий, проміжний та SSL-сертифікати в один. Для цього створіть файл vashsite.crt та вставте туди вміст сертифікатів разом із рядками «BEGIN» та «END» (порядок: SSL, проміжний, кореневий). Порожніх рядків не повинно бути.
Майже те саме потрібно зробити і з приватним ключем - створити файл vashsite.key і перенести вміст ключа, завантаженого з сайту постачальника.
Обидва файли (vashsite.crt та vashsite.key) помістіть у директорію /etc/ssl/ (вона використовується за умовчанням, але може відрізнятися).
У файлі конфігурацій відредагуйте VirtualHost. Додайте:
server(
listen 443;
ssl on;
ssl_certificate /etc/ssl/vashsite.crt;
ssl_certificate_key /etc/ssl/vashsite.key;
server_name vashsite.com;
Якщо директорія із сертифікатом та ключем відрізняється від дефолтної, поміняйте її.
Тепер збережіть зміни та перезапустіть nginx.
Як отримати робоче HTTPS-з'єднання
Після встановлення сертифікатів SSL сайт стане доступним за двома адресами: http://vashsite.com та https://vashsite.com. Вам потрібно залишити лише останній. Для цього налаштуйте файл robots.txt і зробіть 301-редирект зі старого сайту.
У "robots" потрібно оновити host. Приклад: Host: http://vashsite.com. Для налаштування редиректу потрібно додати файл.htacsess рядки:
RewriteCond %(SERVER_PORT) !^443$
RewriteRule ^(.*)$ https://vashsite.com/$1 .
Тепер залишилося повідомити про зміни пошукових систем. У «Вебмайстрі» «Яндекса» додайте сторінку з https та вкажіть її як головне для старого сайту.
Підсумки
Ми розібралися, що таке https, як встановити його на свій сайт та як налаштувати все правильно. Цей протокол вже став стандартом з'єднання і згодом на нього перейдуть усі живі сайти. Цей процес заохочують пошукові системи – наявність встановленого протоколу захищеного з'єднання HTTPS стала одним із факторів ранжирування. Тому, якщо хочете потрапити до топу, встановити його доведеться.
Приємні новини листопада 2016 року для наших дорогих клієнтів та користувачів сайту сайт. Наш інтернет-магазин не стоїть на місці, регулярно оновлюючи не лише асортимент товарних пропозицій, а й розширюючи функціонал сайту, його безпеку для користувачів та значущість у глобальній системі Інтернет. Отже, 26 вересня 2016 року інтернет-магазин сайт отримав сертифікат SSL з розширеною перевіркою, а з 1 листопада 2016 року після тестування та покращення алгоритмів роботи ми підключили на сайт платіжні системи!
Тепер розглянемо докладніше необхідність цих дій та які плюси отримують від цього наші дорогоцінні клієнти?
Основним візуальним плюсом, який кожен клієнт може помітити, є можливість оплатити ОНЛАЙН банківською картою будь-яке замовлення з нашого інтернет-магазину і прийняти його за зручною адресою. Що ж стосується внутрішньої, прихованої гідності оновлень сайту - сертифікат SSL - це спеціальний спосіб шифрування сайту між глобальною мережею Інтернет, браузером та користувачем сайту, тобто це те, що тепер сайт захищений від можливості атаки та заволодіння Вашою платіжною (і навіть контактною) інформацією третіми особами. Для отримання сертифіката SSL нашому сайту необхідно було пройти перевірку реального існування організації, підтвердження отримання та прив'язки сертифіката до домену та інтегрування нової системи захищеного сайту на звичний інтернет-магазин сайт. Відтепер користувачі нашого сайту можуть бути повністю впевнені у безпеці користування нашим зручним та сучасним сайтом, здійснювати покупки та не боятися за витік своїх даних третім особам.
До речі, ми також не стоїмо на місці у розширенні можливостей отримання наших замовлень та з осені 2016 року ми почали пропонувати нашим клієнтам можливість отримання замовлень новими способами доставки – кур'єрською службою СДЕК та через поштомати компанії inPost. Обидві служби присутні у багатьох великих містах Росії, вартість їхніх послуг дуже демократична, а швидкість роботи іноді вражає навіть любителів дорогих та якісних кур'єрських служб! Радимо спробувати скористатися новими способами доставки, це заощадить Ваш час та гроші, та подарує Вам приємні враження від отримання товарів.
Наш інтернет-магазин сайт є сучасною компанією, що динамічно розвивається, пропонуючи нашим клієнтам найсучасніші та найбезпечніші способи оплати та отримання наших замовлень. Слідкуйте за оновленнями, які будуть грандіозними і глобальними, як у розширенні асортименту, так і в наданні більших можливостей нашим дорогим клієнтам!!
Віруси
