HTTPS є, де-факто, обов'язковим для веб-сайтів. Користувачі охочіше лишають свої дані на сайтах з зеленим замком в адресному рядку, Chrome та Firefox позначають небезпечними http-сторінки, де присутні форми, а це впливає на ранжування в пошукових системах і є ймовірною діркою в безпеці. До того ж, зараз є купа способів отримати HTTPS-сертифікат безкоштовно.
Налаштування HTTPS може лякати недосвідчених користувачів, адже треба мати знання в області шифрування та налаштування веб-сервера.
В цій статті я покроково розкажу і покажу як перевести ваш сайт на HTTPS. Я написав детальні інструкції для користувачів розділених хостингів з cPanel, адміністраторів Apache та Nginx на Linux і Unix, а також для адміністраторів IIS на Windows.
Почнімо з самого базового.
HTTP Vs. HTTPS Vs. HTTP/2 Vs. SSL Vs. TLS: що це, в біса, таке?
Для опису процесу спілкування між клієнтом та сервером використовується купа акронімів, вони часто плутають людей, що не досить добре розбираються в внутрішній будові інтернету.
Hypertext Transfer Protocol (HTTP) — базовий протокол передачі даних між клієнтом і сервером. Він описує так речі як запит та відповідь, сесії, кеш, аутентифікація та інше. Робота над ним (і HTML) була розпочата в 1989 році Тімом Бернерс-Лі (Tim Berners-Lee) і його командою в CERN. Перша офіційна версія протоколу (HTTP 1.0) була представлена в 1996, а трохи пізніше, в 1997 була випущена версія 1.1, якою ми користуємося і сьогодні.
По цьому протоколу дані між браузером і клієнтом відсилаються в вигляді звичайного тексту, дозволяючи власнику мережі бачити вміст. Це проблема безпеки, тому було розроблено і представлено HTTP Secure (HTTPS), що дозволяв клієнту і серверу спочатку встановити зашифроване з'єднання, а потім відправляти по ньому HTTP-повідомлення, не хвилюючись, що їх можна просто так прочитати.
Зашифрований канал встановлюється за допомогою протоколу Transport Layer Security (TLS), який раніше називався Secure Socket Layer (SSL). Ці терміни, як правило, взаємозамінні, адже SSL 3.0 був замінений TLS 1.0. SSL був протоколом, розробленим Netscape, в той час як TLS — стандарт IEFT. Всі версії SSL (1.0, 2.0, 3.0) вважаються застарілими через проблеми з безпекою та будуть викликати попередження в браузерів. Версії TLS (1.0, 1.1, 1.2) використовуються й зараз, а TLS 1.3 знаходиться в розробці.
Тобто, десь між 1996 та 1997 утворився той спосіб передачі даних, який ми знаємо (HTTP 1.1 з або без SSL та TLS). Раніше HTTP використовували для загального трафіку (наприклад, читання новин), а для важливого трафіку — HTTPS (аутентифікація, e-commerce). Але висхідний фокус на приватності привніс свої зміни, і тепер Chrome позначає HTTP-сайти як «не приватні».
Наступним оновленням протоколу HTTP є HTTP/2, який підтримує все більше сайтів. Він додає нові функції, зменшує час очікування та поліпшує продуктивність та безпеку.
В HTTP 1.1 безпечне з'єднання є опцією, в той час як в HTTP/2 це майже необхідність. В теорії дані передавати можна й без цього, але вже більшість розробників браузерів сказали що не будуть навіть додавати підтримку HTTP/2 без TLS.
Що надає HTTPS
Чому всі так ганяються за HTTPS, що в ньому такого? Його використовують з трьох причин:
Конфіденційність
HTTPS захищає комунікацію між клієнтом і сервером від сторонніх осіб. Без HTTPS хтось може запустити точку доступу Wi-Fi й бачити всі дані, що через неї йдуть: номери кредитних карток, та інші важливі дані.
Цілісність
Протокол гарантує, що інформація дійде до адресата цілою і незміненою. Зловмисник з точкою доступу з минулого прикладу може додавати власну рекламу на відвідувані веб-сайти, стискати зображення чи змінювати зміст статті, яку ми читаємо. HTTPS гарантує, що інформація не буде змінена.
Ідентифікація
HTTPS гарантує, що веб-сайт є саме тим, ким представився. Зловмисник з точкою доступу може відправляти нам фейкові сайти. HTTPS гарантує, що сайт, що представився як example.com
дійсно є example.com
Криптографія: коротке інтро
Конфіденційність, гарантія цілісності та ідентифікація — ключові концепти криптографії, а не фіча HTTPS. Розглянемо їх.
Конфіденційність
Конфіденційність — основа приватності. Саме вона гарантує, що інформацію не отримають треті особи. Зазвичай для цього інформацію оброблюють таким чином, що вона зі зрозумілої (так званої plaintext
) стає незрозумілою (шифротекст, ciphertext
). Цей процес називається шифруванням (encryption). Зворотній процес — розшифровкою (decryption). Робити це можна по різному, і для цього створено багато алгоритмів шифрування.
І якщо дві сторони хочуть спілкуватися з шифруванням, вони повинні узгодити два аспекти:
-
Який алгоритм шифрування використовувати.
-
З якими параметрами, паролем чи правилами (секретом) відбувається шифрування.
Існує два види алгоритмів шифрування:
-
Симетричний — обидві сторони використовують один і той же ключ.
-
Асиметричний — кожна зі сторін має пару ключів: публічний та приватний
Симетричні методи шифрування базуються на тому, що обидві сторони знають секретний ключ: відправник використовує його для шифрування повідомлення, а отримувач для розшифровки. Проблемою цього методу є те, що сторонам потрібно якось обмінятися цим ключем, а без фізичної зустрічі це досить важко, адже потрібен безпечний канал зв'язку.
Асиметричні методи такої проблеми не мають. Вони використовують пару ключів: коли інформацію зашифровано за допомогою одного ключа, розшифрувати її можна тільки іншим.
Як це працює? Уявімо, що Аліса і Боб хочуть обмінюватися якоюсь інформацією конфіденційно. Кожен з них має пару ключів: приватний та публічний. Приватні ключі відомі лише їх власникам, публічні доступні будь-кому.
Якщо Аліса хоче надіслати повідомлення Бобу, вона знайде його публічний ключ, зашифрує ним повідомлення і надішле Бобу. Розшифрувати його можна лише приватним ключем Боба.
Якщо Боб захоче надіслати повідомлення Алісі, він теж знайде її публічний ключ і зашифрує ним повідомлення. Аліса зможе розшифрувати його своїм приватним ключем.
Постає питання: коли використовувати симетричне шифрування, а коли асиметричне? Асиметричне шифрування використовується для обміну ключем для подальшого спілкування. В реальному житті нам не потрібно використовувати двонапрямне (від Аліси до Боба та від Боба до Аліси) асиметричне шифрування. Достатньо того, що пару ключів матиме одна сторона (сервер), тобто він може приймати й розшифровувати повідомлення для нього. Зворотній напрямок не захищений — інформацію, зашифровану приватним ключем сервера може розшифрувати будь-хто за допомогою його публічного ключа. Інша сторона (клієнт) починає спілкування з сервером надіславши йому зашифроване його публічним ключем повідомлення з випадково згенерованим секретом. Тепер сервер (і тільки він) знає секрет.
Тепер в гру вступає симетричне шифрування, адже воно куди швидше ніж асиметричне. Коли клієнт і сервер конфіденційно обмінялися ключами, для подальшого спілкування використовується алгоритми симетричного шифрування.
Перша асиметрична частина рукостискання (handshake) називається обміном ключами (key exchange).
Цілісність
Однією з проблем, які вирішує HTTPS є цілісність даних:
-
Чи були успішно отримані всі дані?
-
Чи не були змінені дані (третьою стороною) в процесі обміну?
Щоб переконатися, що всі дані доставлені успішно, використовують алгоритм message digest. Обчислення коду ідентифікації повідомлення (message authentication code, MAC. Іноді його називають тегом (tag)) — це процес криптографічного хешування. Вимогами до такого алгоритму є неможливість
-
змінити вміст повідомлення без зміни тегу,
-
згенерувати однаковий тег для двох різних повідомлень,
-
отримати початкове повідомлення, знаючи лише тег.
Ідентифікація
Як щодо ідентифікації? Проблемою додатків з інфраструктурою публічних ключів є те, що обидві сторони не можуть точно знати хто є хто, адже вони фізично розділені. Для того, щоб впевнитися ким дійсно є інша сторона, існує взаємно довірена третя сторона — certificate authority (CA). CA видає сертифікати, що підтверджують, що домен example.com
асоційований з публічним ключем XXX
. В деяких випадках (сертифікати EV та OV) CA також перевіряє чи належить домен певній компанії. Правдивість цієї інформації гарантується (тобто вона сертифікована) certificate authority X, і ця гарантія дійсна не раніше дати Y (begins on) і не пізніше дати Z (expires on). Вся ця інформація зберігається в одному документі, що називається HTTPS сертифікат. Це можна порівняти з державою (якій довіряють всі), яка видає паспорти (сертифікати) людям — всі, хто довіряють державі, будуть впевнені в тому, що власник паспорта є тим, ким представився.
CA — це організації, яким довірено підписувати сертифікати. Операційні системи як Windows, macOS, iOS та Android мають власний список довірених сертифікатів. Також його має Firefox.
Пізніше всі сертифікати перевіряються та вважаються довіреними — операційною системою, браузером або іншим довіреним об'єктом. Цей механізм називається ланцюжком довіри.
Ви можете самі додати CA до списку довірених, це дуже зручно коли ви працюєте з самопідписаними сертифікатами (про них ми поговоримо пізніше).
В більшості ситуацій потрібно достовірно ідентифікувати лише сервер. Користувачі магазину повинні бути впевненими в його справжності, тому сертифікат потрібен лише серверу. В інших системах, наприклад державних, потрібно також точно ідентифікувати і клієнта, тоді їм обом потрібні сертифікати, але це вже виходить за рамки цієї статті.
Типи HTTPS сертифікатів
Є декілька типів сертифікатів, але всі можна розділити за категоріями.
1. Валідація сервера
Domain validated (DV)
Найпопулярніший тип сертифікату, він підтверджує, що домен та публічний ключі не підмінено. Браузер встановлює безпечне з'єднання з сервером та відображає панель з замочком. Клікнувши по ній ви побачите надпис «Цей веб-сайт не надав інформації про власника», адже для отримання цього сертифікату достатньо лише володіти доменом. DV сертифікати зазвичай достатньо дешеві (10 USD в рік) або і взагалі безкоштовні (див. Let's Encrypt та Cloudflare нижче).
Extended validation (EV)
EV сертифікат гарантує, що домен належить певній компанії. Це вид сертифікату, що викликає найбільшу довіру. Він видається після перевірки CA організації, що володіє доменом. Це перевірка:
-
володіння доменом
-
в державному реєстрі: чи дійсно існує така компанія, чи активна вона
-
в незалежних бізнес реєстрах (Dunn and Bradstreet, Salesforce connect.data.com, Yellow Pages, тощо)
-
верифікаційний телефонний дзвінок
-
інспекція всіх доменних імен в сертифікаті
Тепер поряд з замочком відображатиметься назва компанії, яка володіє доменом, клік по якій покаже деталі про компанію, наприклад, її назву та адресу. Коштують такі сертифікати від 150 до 300 USD в рік.
Organization validated (OV)
Ці сертифікати схожі на EV, вони теж гарантують те, що домен належить організації, але її назва не відображається перед URL. Тобто вам потрібно дотриматися всіх правил як і для EV-сертифікату, але без його плюсів. Тому цей сертифікат найменш популярний. Коштує від 40 до 100 USD в рік.
2. Кількість доменів
Раніше, сертифікати видавалися лише для одного домену в CN-полі. Пізніше було додане поле «subject alternative name» (SAN), тепер один сертифікат міг працювати для декількох доменів. Зараз всі сертифікати випускаються по однаковій технології, тому навіть сертифікат для одного домену матиме поле SAN з цим самим доменом (і його www-версією). Але деякі компанії все ще окремо продають сертифікати для одного і для декількох доменів.
Один домен
Найпопулярніший вид сертифікату, який покриває лише один домен: example.com
та www.example.com
Декілька доменів (UCC/SAN)
Такі типи сертифікатів ще називають Unified Communications Certificate (UCC) або Subject Alternative Names (SAN), вони можуть покривати відразу декілька доменів (або піддоменів) до певного ліміту. Зазвичай в ціну включено оплату трьох-п'яти доменів, а решту можна додати за додаткову ціну
Wildcard
Цей тип сертифікату покриває головний домен та всі піддомени (*.example.com
). Але його обмеженням є те, що він покриває лише піддомени основного домену.
Конфігурація
Згадаємо, що для забезпечення HTTPS-шифрування потрібно:
-
Обмінятися ключем. Тут використовуються асиметричні алгоритми шифрування.
-
Ідентифікація сторони за допомогою HTTPS-сертифікату, який видала CA. Використовуються асиметричні алгоритми шифрування.
-
Шифрування повідомлення. Тут використовуються симетричні алгоритми шифрування.
-
Підпис повідомлення за допомогою алгоритмів хешування.
Кожен з цих пунктів має свій набір можливих алгоритмів (деякі з них вже застаріли), які використовують ключі різної довжини. Частиною handshake є узгодження між клієнтом і сервером, які алгоритми будуть використані.
Наприклад, передача ECDHE-RSA-AES256-GCM-SHA384
свідчить, що обмін ключем відбудеться за протоколом Діффі-Хеллмана на еліптичних кривих (Elliptic Curve Diffie-Hellman Ephemeral, ECDHE), сертифікат був підписаний CA за допомогою алгоритму RSA, симетричне шифрування відбуватиметься за допомогою алгоритму AES з довжиною ключа в 256 біт з GCM, а цілісність повідомлення гарантується алгоритмом SHA-2 з довжиною дайджесту в 384 біти.
І тому вам потрібно буде зробити декілька рішень в конфігурації.
Шифри
Рішення, які шифри використовувати — балансування між широкою підтримкою та безпекою, адже для підтримки старіших браузерів сервер потрібен підтримувати старі алгоритми шифрування, багато з яких вже не вважаються безпечними.
Список комбінацій, підтримуваних OpenSSL, влаштований таким чином, що найнадійніша комбінація розташована зверху, а найслабша — знизу. Це має сенс, адже вибір комбінації відбувається перебором цього списку, доки не знайдеться комбінація, яка підтримується і сервером і браузером. Тому краще спочатку спробувати більш захищені способи.
На Вікіпедії є порівняльний список алгоритмів і їх підтримка різними версіями SSL та TLS.
Дуже зручним ресурсом, що допоможе налаштувати HTTPS на сервері є Mozilla SSL Configuration Generator, пізніше в цій статті ми скористаємося ним.
Тип ключа
Сертифікати з використанням еліптичної криптографії швидші та менше навантажують CPU, ніж RSA-сертифікати, що грає важливу роль на мобільних пристроях. Але деякі сервіси (на момент написання, 12 липня 2017 року, серед них були Amazon, CloudFront та Heroku) не підтримують такі сертифікати.
256-бітний ECC-ключ визнано достатнім.
RSA-сертифікати повільніші, але їх підтримує куди більше старих серверів. RSA-ключі більші, тому 2048-бітний RSA-ключ визнано мінімальним. RSA-сертифікати, що підписані 4096-бітним ключем можуть викликати проблеми зі швидкодією, тому зазвичай використовують 2048-бітні, жертвуючи потенціальною безпекою.
Ви, напевно, помітили, що я не привів ніяких конкретних цифр стосовно впливу на швидкодію. Сервери бувають різні за комплектацією, потужностями, також на швидкодію впливає кількість відвідувачів сайту.
Процедура отримання сертифікату
Щоб отримати HTTPS-сертифікат потрібно виконати наступне:
-
Створіть пару з приватного і публічного ключа і підготуйте запит на підписання сертифікату (Certificate Signing Request, CSR), включаючи інформацію про організацію та публічний ключ.
-
Зверніться до CA і зробіть запит на отримання HTTPS-сертифікату, що базується на вашому CSR.
-
Отримайте підписаний сертифікат та встановіть на своєму веб-сервері.
Існує певний набір файлів, що зберігають різні елементи інфраструктури публічних ключів (public key infrastructure, PKI): приватний та публічний ключі, CSR та підписаний HTTPS-сертифікат. І щоб все це ускладнити, різні сторони використовують різні імена та розширення файлів для одних і тих же речей.
Для початку, існує два формати збереження інформації — DER та PEM. Перший є бінарним форматом, а інший це base64-encoded (текстовий) DER-файл. За умовчуванням Windows використовує DER-формат напряму, в той час як світ open-source (Linux, UNIX) використовують PEM. Звісно, існують інструменти для конвертації між цими двома форматами.
Файли, які ми будемо використовувати в прикладах:
-
example.com.key
— цей PEM-форматований файл зберігає приватний ключ. Розширення.key
не є обов'язковим, тому може і не використовуватися. Він повинен бути захищеним і доступним лише суперкористувачу. -
example.com.pub
— цей PEM-форматований файл зберігає публічний ключ. Ви навіть не потребуєте цього файлу, адже ви завжди можете згенерувати його з приватного ключа, як зазвичай і роблять. Але для зрозумілості прикладів ми будемо його використовувати. -
example.com.csr
— це запит на підписання запиту. PEM-форматований файл, що зберігає інформацію про організацію та публічний ключ серверу. Відправляється CA для отримання сертифікату. -
example.com.crt
— це PEM-форматований файл, що і є нашим сертифікатом, який підписаний CA. В ньому зберігається публічний ключ серверу, інформація про організацію, підпис CA та дату закінчення. Розширення.crt
не є стандартом, іноді ще використовують.cert
та.cer
.
Імена (і розширення) файлів не є стандартом та можуть бути будь-якими. Я використовую такі імена, адже вважаю, що вони найзрозуміліше показують що є що.
Приватний ключ – це випадково-згенерований рядок деякої довжини (ми використовуємо 2048-бітний), він виглядає приблизно так:
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAm+036O2PlUQbKbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9N
i8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4E
S17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWu
Q30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnf
b/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDil
Tt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQgNQIDAQABAoIBAEAO2KVM02wTKsWb
dZlXKEi5mrtofLhkbqvTgVE7fbOKnW8FJuqCl+2NMH31F1n03l765p4dNF4JmRhv
/+ne4vCgOPHR/cFsH4z/0d5CpHMlC7JZQ5JjR4QDOYNOpUG51smVamPoZjkOlyih
XGk/q72CxeU6F/gKIdLt6Dx03wBosIq9IAE8LwdMnioeuj18qaVg195OMeIOriIn
tpWP4eFya5rTpIFfIdHdIxyXsd6hF/LrRc9BMWTY1/uOLrpYjTf7chbdNaxhwH7k
buvKxBvCvmXmd6v/AeQQAXbUkdSnbTKDaB9B7IlUTcDJyPBJXvFS1IzzjN6vV+06
XBwHx5ECgYEAyRZLzwnA3bw8Ep9mDw8JHDQoGuQkFEMLqRdRRoZ+hxnBD9V9M0T6
HRiUFOizEVoXxf6zPtHm/T7cRD8AFqB+pA/Nv0ug6KpwUjA4Aihf5ADp0gem0DNw
YlVkCA6Bu7c9IUlE0hwF7RLB7YrryJVJit9AymmUTUUHCQTWW2yBhC8CgYEAxoHS
HGXthin5owOTNPwLwPfU2o7SybkDBKyW69uTi0KxAl3610DjyA/cV2mxIcFlPv1y
HualGd9eNoeCMBy/AUtjzI0K77yeRpjj321rj6k8c8bYWPHH539SiBXLWTY/WQ0w
pxfT3d/Z4QMh5d6p+p5f3UIrXESYQd+fAaG5tNsCgYEAksTdTB4YUT9EsWr6eN9G
jPlclFQUKV3OMvq77bfYvg8EJORz32nnDDmWS7SUjoOtemwutBlMeWbaKk25aMp3
5JNMXuV6apeMJ9Dd8GU7qBUqlIvVK31/96XPvzmnYzWZPqRVwO2HPcRFG3YcJmkg
JmZQyexJvCQ3wFNxiYUm+y0CgYBXQSMhFnCUg4jWbbDcHlnwRT+LnjHrN2arPE3O
eKLfGL6DotmqmjxFaStaRPv2MXMWgAMUsB8sQzG/WEsSaOBQaloAxJJlFIyhzXyE
bi1UZXhMD8BzQDu1dxLI/IN4wE6SDykumVuocEfuDxlsWDZxEgJjWD2E/iXK9seG
yRa+9wKBgEydVz+C1ECLI/dOWb20UC9nGQ+2dMa+3dsmvFwSJJatQv9NGaDUdxmU
hRVzWgogZ8dZ9oH8IY3U0owNRfO65VGe0sN00sQtMoweEQi0SN0J6FePiVCnl7pf
lvYBaemLrW2YI2B7zk5fTm6ng9BW/B1KfrH9Vm5wLQBchAN8Pjbu
-----END RSA PRIVATE KEY-----
Зберігайте ваші приватні ключі в таємниці! Встановіть їм досить обмежені права (600) і не розголошуйте стороннім особам.
Його напарник, публічний ключ, виглядає так:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQbKbSSs2ik
6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5
e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+H
fBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTIN
WniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBC
eVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQg
NQIDAQAB
-----END PUBLIC KEY-----
Запит на підписання сертифіката (CSR) виглядає так:
-----BEGIN CERTIFICATE REQUEST-----
MIICzjCCAbYCAQAwgYgxFDASBgNVBAMMC2V4YW1wbGUuY29tMQswCQYDVQQLDAJJ
VDEPMA0GA1UECAwGTG9uZG9uMRIwEAYDVQQKDAlBQ01FIEluYy4xIDAeBgkqhkiG
9w0BCQEWEWFkbWluQGV4YW1wbGUuY29tMQswCQYDVQQGEwJHQjEPMA0GA1UEBwwG
TG9uZG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQb
KbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3
OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYO
cfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wm
wZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZ
EUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2
tjtp+LQgNQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAGIQVhXfuWdINNfceNPm
CkAGv4yzpx88L34bhO1Dw4PYWnoS2f7ItuQA5zNk9EJhjkwK8gYspK7mPkvHDbFa
Um7lPSWsm3gjd3pU7dIaHxQ+0AW9lOw5ukiBlO4t3qgt+jTVZ3EhMbR0jDSyjTrY
kTgfuqQrGOQSmLb5XviEtCcN0rseWib3fKIl8DM69JiA2AALxyk7DCkS1BqLNChT
pnbgvtlUhc4yFXNCtwPGskXIvLsCn2LRy+qdsPM776kDLgD36hK0Wu14Lpsoa/p+
ZRuwKqTjdaV23o2aUMULyCRuITlghEEkRdJsaXadHXtNd5I5vDJOAAt46PIXcyEZ
aQY=
-----END CERTIFICATE REQUEST-----
Цей CSR зберігає в собі публічний ключ і деталі про компанію ACME Inc., що базується в Лондоні і володіє доменом example.com
.
І нарешті, HTTPS-сертифікат виглядає так:
-----BEGIN CERTIFICATE-----
MIIDjjCCAnYCCQCJdR6v1+W5RzANBgkqhkiG9w0BAQUFADCBiDEUMBIGA1UEAwwL
ZXhhbXBsZS5jb20xCzAJBgNVBAsMAklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNV
BAoMCUFDTUUgSW5jLjEgMB4GCSqGSIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20x
CzAJBgNVBAYTAkdCMQ8wDQYDVQQHDAZMb25kb24wHhcNMTYwNDE5MTAzMjI1WhcN
MTcwNDE5MTAzMjI1WjCBiDEUMBIGA1UEAwwLZXhhbXBsZS5jb20xCzAJBgNVBAsM
AklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNVBAoMCUFDTUUgSW5jLjEgMB4GCSqG
SIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20xCzAJBgNVBAYTAkdCMQ8wDQYDVQQH
DAZMb25kb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb7Tfo7Y+V
RBsptJKzaKTo7pNjLr5mxqzmgCTcaKgYuXVFb02LyRqCp2cPr0S3b2bW+Xk4g+wG
hbc5ZvVoFbl7cnTH2mtcjVb9+m+4/02ascFQ3gRLXtWWJGl9Ufdod88Lysqm/ca8
dg5x86Yw34d8FmVR4okqzpzlaZJV2dkHRHhQBa5DfRocQFWq2uGAepgMGiRV7T8f
jCbBkQhBMg1aeII4VHlSmEl/mc/yWMZuY/E1Od9v+IdL9yGNyMXtMYwbfp7sQGhC
KNkRRCzkgEJ5V586cUsrmMvH4EL/9f4U3MHIOKVO36Xbwj/dk3W6OFqTvdgVtaOM
tHa2O2n4tCA1AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBABwwkE7wX5gmZMRYugSS
7peSx83Oac1ikLnUDMMOU8WmqxaLTTZQeuoq5W23xWQWgcTtfjP9vfV50jFzXwat
5Ch3OQUS53d06hX5EiVrmTyDgybPVlfbq5147MBEC0ePGxG6uV+Ed+oUYX4OM/bB
XiFa4z7eamG+Md2d/A1cB54R3LH6vECLuyJrF0+sCGJJAGumJGhjcOdpvUVt5gvD
FIgT9B04VJnaBatEgWbn9x50EP4j41PNFGx/A0CCLgbTs8kZCdhE4QFMxU9T+T9t
rXgaspIi7RA4xkSE7x7B8NbvSlgP79/qUe80Z7d8Oolva6dTZduByr0CejdfhLhi
mNU=
-----END CERTIFICATE-----
Всі частини пов'язані між собою. Цей сертифікат ще називають самопідписаним, адже він не був підписаний ні однією CA.
Процес налаштування HTTPS буде показано для cPanel, Linux, FreeBSD та Windows. Це процес універсальний для всіх видів сертифікату. Якщо ви хочете отримати безкоштовний DV-сертифікат, вам потрібно виконати трохи інші кроки, що описані в секціях Let's Encrypt та Cloudflare.
Крок перший: створення приватного ключа та запиту на підписання сертифікату (CSR)
Ми будемо використовувати 2048-бітний RSA-сертифікат, але якщо ваш сервер-провайдер підтримує ECC, я рекомендую використовувати його.
cPanel
-
Ввійдіть в вашу cPanel
-
Проскрольте до секції «Security» та клікніть на «SSL/TLS».
- Клікніть по «Private Keys (KEY)», щоб створити новий приватний ключ.
- Виставте параметр «Key Size» в «2048-bit» і натисніть «Generate»
- Буде згенеровано новий приватний ключ і ви побачите екран підтвердження.
- Якщо ви повернетесь на сторінку «Private Keys», то побачите цей ключ в списку.
- Поверніться до сторінки «SSL/TLS Manager» і клікніть по «Certificate Signing Requests (CSR)», щоб створити CSR.
- Тепер оберіть ключ, що ми тільки що згенерували в відповідному полі. Заповнюйте всі поля правильно, адже цю інформацію буде видно публічно в вашому сертифікаті. Зверніть особливу увагу на секцію «Domains», ім'я домену повинно точно збігатися. Коли закінчите, натисніть кнопку «Generate».
- Новий CSR буде згенеровано і ви побачите екран підтвердження.
- Якщо ви повернетесь на сторінку «Certificate Signing Request», то побачите створений CSR:
Linux, FreeBSD
Впевніться, що OpenSSL встановлено:
openssl version
Якщо OpenSSL відсутній, то потрібно його встановити:
- Debian, Ubuntu і подібні
sudo apt-get install openssl
- Red Hat, CentOS і подібні
sudo yum install openssl
- FreeBSD
make -C /usr/ports/security/openssl install clean
Тепер згенерувати ключ і CSR ми можемо однією командою:
openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr
Буде згенеровано приватний ключ, а вам попросять ввести певні дані для CSR:
Generating a 2048 bit RSA private key
........................+++
................................................................+++
writing new private key to 'example.com.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Відповідайте на питання уважно, адже ця інформація буде в вашому сертифікаті. Особливу увагу зверніть на «Common Name», в якому потрібно вказати ваш домен.
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Internet Infromation Server (IIS)
- Відкрийте «Start» → «Administrative Tools» → «Internet Information Services (IIS) Manager». Клікніть по імені сервера. Зробіть подвійний клік по «Server Certificates».
- Клікніть по «Create Certificate Request» в правій колонці.
- Уважно заповнюйте поля, особливо «Common Name», де повинно бути вказане імя вашого домену. Натисніть «Next».
- «Cryptographic Service Provider» залиште як є, а «Bit length» встановіть в
2048
. Натисніть «Next».
- Оберіть куди зберегти готовий CSR та натисніть «Finish».
Крок другий: отримання HTTPS-сертифікату
Щоб отримати HTTPS-сертифікат, перш за все, за нього потрібно заплатити сертифікат-провайдеру. Після цього вам потрібно буде надіслати ваш CSR, а якщо вам потрібен EV чи OV-сертифікат, то потрібно буде ще прикласти додаткові документи. Регістратор перевірить ваш запит (і додаткові документи, якщо є) і видасть вам HTTPS-сертифікат.
Загальна інструкція
Ця процедура може відрізнятися від одного регістратора до іншого, але в загальному покупка HTTPS-сертифіката виглядає так:
-
Знайдіть продавця сертифікатів.
-
Оберіть тип сертифікату ((DV, OV, EV, single site, multisite, wildcard) та додайте до кошика. Оберіть зручний метод і оплатіть покупку.
-
Активуйте ваш сертифікат, завантажте або скопіюйте ваш CSR.
-
Вас спитають про спосіб перевірки володіння доменом (Domain Control Validation, DCV) — через електронну пошту, завантаженням HTML-файлу чи доданням
TXT
-запису до вашої доменної зони. Обирайте який вам зручніше. -
Почекайте декілька хвилин доки проходить валідація і видається HTTPS-сертифікат. Скачайте його.
Самопідписані сертифікати
Також сертифікат можна підписати самому, без допомоги CA. Він буде так само криптографічно надійним як і сертифікат від CA, з цією лише відмінністю, що браузери не будуть йому довіряти. Але це дуже корисно для тестування.
Приклад сертифікату вище є самопідписаним. А створити сертифікат самому можна за допомогою OpenSSL:
openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt
Після цього ви зможете встановити його на власному сервері. Якщо ви купляли сертифікат в свого хостинг-провайдера (так часто буває), скоріше за все, є автоматизована система по встановленню сертифіката. Якщо ні — вам потрібно буде зробити це самому.
Крок третій: встановлення сертифіката
cPanel
- Поверніться на сторінку «SSL/TLS Manager». Клікніть по «Certificates (CRT)», щоб імпортувати новий сертифікат.
- Ви будете переміщені на сторінку «Paste, Upload or Generate». Завантажте або скопіюйте контент файлу, що отримали на минулому кроці.
- Коли ви завантажите сертифікат, його вміст буде розпаршено і дані з'являться в відповідних полях. Натисніть кнопку «Save Certificate».
- Сертифікат буде збережено, а ви отримаєте повідомлення з підтвердженням.
- Якщо ви повернетесь на сторінку «Certificates (CRT)», то побачите наше сертифікат.
- Поверніться на сторінку «SSL/TLS Manager» та клікніть по «Install and Manage SSL for your website (HTTPS)», щоб присвоїти новий сертифікат існуючому веб-сайту.
- Тепер слід заповнити форму «Install an SSL Website». Клікніть по «Browse Certificates» і оберіть наш сертифікат. Оберіть потрібний домен із випадаючого списку і перевірте чи заповнені поля «Certificate» та «Private Key».
Тепер слід перевірити чи все гарно працює: перейдіть по адресі https://www.example.com
. Якщо все працює, то ви, напевно, захочете перенаправляти користувачів з HTTP на HTTPS-версію. Для цього створіть файл .htaccess
(якщо ви використовуєте Apache) в вашій кореневій директорії:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Якщо цей файл вже існує, то скопіюйте лише два останні рядки і вставте відразу після рядка RewriteEngine On
.
Linux, FreeBSD
Перемістіть ваш ключ, CSR та сертифікат в відповідні їм місця:
- Debian, Ubuntu і подібні, FreeBSD
cp example.com.crt /etc/ssl/certs/
cp example.com.key /etc/ssl/private/
cp example.com.csr /etc/ssl/private/
- Red Hat, CentOS і подібні
cp example.com.crt /etc/pki/tls/certs/
cp example.com.key /etc/pki/tls/private/
cp example.com.csr /etc/pki/tls/private/
restorecon -RvF /etc/pki
Власником цих файлів повинен бути супер-користувач, а дозволи встановлені в 600
.
- Debian, Ubuntu і подібні
chown -R root. /etc/ssl/certs /etc/ssl/private
chmod -R 0600 /etc/ssl/certs /etc/ssl/private
- Red Hat, CentOS і подібні
chown -R root. /etc/pki/tls/certs /etc/pki/tls/private
chmod -R 0600 /etc/pki/tls/certs /etc/pki/tls/private
- FreeBSD
chown -R root:wheel /etc/ssl/certs /etc/ssl/private
chmod -R 0600 /etc/ssl/certs /etc/ssl/private
Apache
Щоб запустити HTTPS-версію вашого сайту, ви повинні:
-
переконатися, що
mod_ssl
встановлено на вашому сервері, -
завантажити сертифікат на сервер,
-
редагувати конфіги Apache
Почнемо з mod_ssl
. В залежності від вашої ОС, повинна працювати якась з цих команд
apache2 -M | grep ssl
або
httpd -M | grep ssl
Якщо mod_ssl
встановлено, ви отримаєте ось таке повідомлення (або щось схоже):
ssl_module (shared)
Syntax OK
Якщо модуль не встановлено, виконайте ці команди:
- Debian, Ubuntu і подібні
sudo a2enmod ssl
sudo service apache2 restart
- Red Hat, CentOS і подібні
sudo yum install mod_ssl
sudo service httpd restart
- FreeBSD
make -C /usr/ports/www/apache24 config install clean
apachectl restart
Відредагуйте конфіг Apache:
- Debian, Ubuntu і подібні
/etc/apache2/apache2.conf
- Red Hat, CentOS і подібні
/etc/httpd/conf/httpd.conf
- FreeBSD
/usr/local/etc/apache2x/httpd.conf
Listen 80
Listen 443
<virtualhost *:80="">
ServerName example.com
ServerAlias www.example.com
Redirect 301 / https://www.example.com/
</virtualhost>
<virtualhost *:443="">
ServerName example.com
Redirect 301 / https://www.example.com/
</virtualhost>
<virtualhost *:443="">
ServerName www.example.com
...
SSLEngine on
SSLCertificateFile/path/to/signed_certificate_followed_by_intermediate_certs
SSLCertificateKeyFile /path/to/private/key
# Розкоментуйте наступну директиву, якщо хочете використовувати ідентифікацію клієнтського сертифікату
#SSLCACertificateFile /path/to/ca_certs_for_client_authentication
# HSTS (потрібне mod_headers) (15768000 seconds = 6 months)
Header always set Strict-Transport-Security "max-age=15768000"
...
</virtualhost>
# середня конфігурація, редагуйте під свої потреби
SSLProtocol all -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
# OCSP Stapling, лише в httpd 2.3.3 і новіше
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
Ця конфігурація була згенерована за допомогою Mozilla SSL Configuration Generator. Упевніться, що ви вказали шляхи до сертифікату та приватного ключа.
nginx
Відредагуйте конфіг nginx:
- Debian, Ubuntu, Red Hat, CentOS
/etc/nginx/nginx.conf
- FreeBSD
/usr/local/etc/nginx/nginx.conf
server {
listen 80 default_server;
listen [::]:80 default_server;
# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# сертифікати, що будуть надіслані в SERVER HELLO конкатеновані в ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
# Diffie-Hellman параметри для DHE ciphersuites, рекомендовано 2048 bits
ssl_dhparam /path/to/dhparam.pem;
# середня конфігурація, редагуйте під свої потреби
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;
# HSTS (потрібен ngx_http_headers_module) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# отримання OCSP-записів з URL в ssl_certificate і їх кешування
ssl_stapling on;
ssl_stapling_verify on;
## перевірка ланцюжка довіри OCSP з використанням Root CA
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver <ip dns="" resolver="">;
....
}
Ця конфігурація була згенерована за допомогою Mozilla SSL Configuration Generator. Упевніться, що ви вказали шляхи до сертифікату та приватного ключа. Також сюди вже включено перенаправлення з HTTP до HTTPS, а також підтримується HTTP/2 з коробки.
Internet Infromation Server (IIS)
- Відкрийте «Start» → «Administrative Tools» → «Internet Information Services (IIS) Manager». Клікніть по імені сервера. Зробіть подвійний клік по «Server Certificates».
- Клікніть по «Complete Certificate Request» в правій колонці.
- Оберіть отриманий від CA файл сертифікату. Придумайте для нього зрозуміле ім'я («Friendly name»), щоб зрозуміти що це за сертифікат в майбутньому. Перемістіть новий сертифікат в персональне сховище (IIS 8+), клікніть «ОК».
- Якщо все пройшло добре, ви побачите сертифікат в «Server Certificates».
- «Розкрийте» ім'я сервера. В сайтах оберіть той, якому потрібно присвоїти сертифікат. Клікніть по «Bindings» в правій колонці.
- Тут натисніть кнопку «Add».
-
В цьому вікні заповніть поля так:
-
Type: https
-
IP address: All Unassigned
-
Port: 443
-
SSL Certificate: «friendly name» вашого сертифікату.
Клікніть «ОК».
- Тепер ваш сайт працює як через HTTP, так і через HTTPS.
Попередження про змішаний контент
Ви можете отримати попередження від браузера, що контент цієї сторінки не захищено. Це не означає, що ви встановили щось неправильно, просто скоріше всього десь в коді сторінки є елементи (наприклад, зображення), які завантажуються через HTTP. Адреси всіх ресурсів повинні бути вказані відносно головної директорії (/images/image.png
, /styles/style.css
), відносно поточного документа (../images/image.png
) або з повним URL, на початку якого стоїть https://
(<script src="https://code.jquery.com/jquery-3.1.0.min.js"></script>
).
Протестуйте ваш сервер
Після всіх налаштувань слід перевірити ваш сайт і наскільки він безпечний. Qualys SSL Server Test допоможе вам в цьому, він перевірить правильність конфігурації, можливі проблеми, а також дасть поради для поліпшення безпеки вашого сайту.
Продовження терміну дії
Ваш сертифікат діє не вічно, а лише певний період. Зазвичай, це рік. Не чекайте останнього моменту щоб продовжити сертифікат, ваш регістратор надсилатиме вам нагадування як тільки наблизиться дата кінця його дії. Я рекомендую оформити новий сертифікат при першому такому нагадуванню. Ця процедура мало відрізняється від отримання нового сертифікату: створення CSR, отримання сертифікату та його встановлення. До того ж, сертифікат буде валідним відразу після підписання, і до дати припинення дії минулого сертифікату + один рік. Тобто, буде час, коли обидва сертифікати будуть працювати, а в вас буде час щоб перевірити роботу нового сертифікату без заминок в роботі вашого сайту.
Анулювання
Якщо ви втратили контроль над сервером, чи підозрюєте, що хтось знає ваш приватний ключ, ви маєте негайно анулювати ваш HTTPS-сертифікат. Різні регістратори проводять цю процедуру по різному, але зазвичай це зводиться до маркування вашого сертифікату як неактивного в базі регістартора і видачі вам нового сертифіката.
Let's Encrypt
Як каже нам сайт Let's Encrypt,
Let's Encrypt — це безкоштовна, автоматизована та відкрита CA, що працює для людей. Let's Encrypt підтримується Internet Security Research Group (ISRG).
Головними принципами нашого сервісу є:
- Доступність Кожен, хто володіє доменом, може використовувати Let's Encrypt щоб отримати працюючий сертифікат абсолютно безкоштовно.
- Автоматизація Програмне забезпечення на вашому сервері може взаємодіяти з нашим сервісом, отримувати сертифікати, конфігурувати їх та встановлювати без вашої участі.
- Безпека Let's Encrypt — це платформа, що намагається поширювати TLS, як в ролі CA, так і в ролі бази знань для веб-майстрів.
- Відкритість Наш протокол автоматичної видачі сертифікатів буде опубліковано як відкритий стандарт і кожен зможе його реалізувати.
- Спільнота Як і зачатки інтернету, що розвивалися небайдужою спільнотою, Let's Encrypt теж розвивається завдяки спільноті і для спільноти.
Щоб відчути всі плюси цього сервісу, вам потрібно буде специфічно налаштувати ваш сервер. Let's Encrypt надає короткострокові сертифікати, які потрібно регулярно оновлювати.
Як це працює
Є три суттєві відмінності між Let's Encrypt та іншими CA.
- Доступність
Let's Encrypt видає HTTPS-сертифікати цілком безкоштовно.
- Автоматизація
Сертифікати від Let's Encrypt дійсні протягом 90-та днів, в той час як звичайні — рік. Таким чином людей заохочують автоматизувати цей процес за допомогою окремого ПЗ або скрипта, що запускається по крону. Такий собі «зроби і забудь».
- Безпека
Let's Encrypt не йде на компроміси коли питання стосується безпеки, тому сертифікати можуть не підтримуватися якимись старими чи екзотичними платформами. Список підтримуваних платформ можна переглянути тут.
Обмеження
Let's Encrypt видає лише DV-сертифікати, OV та EV-сертифікати зараз не підтримуються, і, на даний момент, немає планів по їх впровадженню. Підтримуються також сертифікати для одного чи декількох доменів, але не підтримуються шаблони (wildcard). Детальніше описано в FAQ.
Для автоматичного отримання сертифікатів існують певні обмеження. Це зроблено для захисту інфраструктури від навмисного і ненавмисного зловживання. Але ці ліміти настільки низькі, що не впливають на звичайних користувачів навіть з сотнями доменів.
Також не підтримуються старі клієнти (зокрема старіші за Windows XP SP3). Більше інформації на цій сторінці.
Налаштування серверу для використання Let's Encrypt
cPanel
-
Ввійдіть в вашу cPanel.
-
Проскрольте до секції «Security» і клікніть по «Let's Encrypt for cPanel».
- Відмітьте обидва домени (
example.com
таwww.example.com
) і натисніть «Issue Multiple».
- Вам буде показано екран підтвердження. Ваш головний домен (без
www
) буде відмічено як пріоритетний, аwww
-домен буде занесено в сертифікат в поле «Subject Alt Name» (SAN). Натисніть «Issue» для продовження. Дочекайтеся і не спішіть перезавантажувати сторінку, адже ініціалізація може зайняти трохи часу (хвилину чи дві).
- Якщо все пройшло успішно, ви побачите таке повідомлення. Натисніть «Go back», щоб переглянути встановлені сертифікати.
- Ви побачите ваш домен в списку «Your domains with Let's Encrypt certificates».
Linux, FreeBSD і все таке
Найпростішим способом налаштувати автоматичне отримання і встановлення сертифікатів Let's Encrypt на вашому сервері є Certbot. Просто оберіть ваш веб-сервер та ОС із списку і слідуйте інструкціям.
Internet Infromation Server (IIS)
Для IIS не існує офіційного клієнта, але є деякі напрацювання. Існує декілька проектів, в рамках яких створюються нативні клієнти для Windows.
-
ACMESharp (PowerShell) — найперша спроба написати клієнт для Windows.
-
letsencrypt-win-simple (для командного рядка) — схоже, що найпростіший для використання.
-
Certify — GUI для ACMESharp, але все ще знаходиться в беті.
Cloudflare
Cloudflare — сервіс що надає мережу доставки контенту (content delivery network, CDN) та захист сайтів від DDoS-атак. Він надає безкоштовний HTTPS-сертифікат у всіх тарифних планах, включаючи безкоштовний: видається спільний DV Cloudflare Universal SSL, для декількох сертифікатів потрібна бізнес-підписка.
Щоб скористатися цим, створіть аккаунт, налаштуйте веб-сайт та перейдіть в секцію «Crypto».
CertSimple
CertSimple видає лише EV-сертифікати, і робить це схожим на Let's Encrypt способом. І ось в чому його переваги:
- Простий процес подачі заявки
Не потрібно ніякого додаткового софту чи питань в консолі.
- Швидкий час перевірки
Зазвичай перевірка займає близько трьох годин, в той час як в інших CA це займає 7-10 днів.
- Безкоштовне продовження дії сертифікату
Ви можете з легкістю додати новий домен чи замінити втрачений приватний ключ.
Детальніше написано тут.
Декілька HTTPS-сайтів на одному IP
Через особливості процесу handshake, віртуальні хости на одному IP є проблемою для TLS. Віртуальні хости коректно працюють бо користувач вказує в HTTP-заголовках домен, до якого звертається, але при використанні HTTPS спочатку потрібно встановити з'єднання і лише потім відсилати якісь текстові дані. Сервер не знає який HTTPS-сертифікат слід віддати клієнтові, і віддає перший в конфігу, який, звісно, працює лише для одного сайту.
Є декілька виходів з ситуації: мати окремий IP для кожного HTTPS-сайту, або мати один сертифікат для всіх сайтів. Обидва є досить непрактичними — адресний простір IPv4 швидко вичерпується, а мати один великий сертифікат не зручно, адже при найменшій зміні в сертифікаті вам потрібно буде знову встановлювати його на всіх сайтах.
Розширення протоколу TLS під назвою Server Name Indication (SNI) вирішує цю проблему. Але його повинні підтримувати і клієнт, і сервер. І хоча його вже починають вбудовувати в деякі клієнти та сервери, все ж його підтримка досить мала, щоб використовувати на бойовому сервері.
Ви можете дізнатися як ввімкнути SNI для Apache, nginx та IIS (8+).
Корисні ресурси
- Mozilla SSL Configuration Generator
- SSL Server Test, Qualys
- «Security/Server Side TLS», Mozilla wiki
- «SSL and TLS Deployment Best Practices», SSL Labs
- Documentation, Qualys SSL Labs
- «Database Search and Replace Script in PHP», Interconnect IT Скрипт для заміни всіх посилань з HTTP на HTTPS (посилання, зображення тощо) в БД WordPress.
Ще немає коментарів