SSL-сертифікат для сайту: як підключити HTTPS і виправити помилки

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

Якщо доступу до сервера немає або сайт уже показує помилки, ці роботи можна виконати в межах технічної підтримки сайту. Нижче — інструкція, за якою можна оцінити стан сайту або проконтролювати підрядника.

Що таке SSL-сертифікат і HTTPS

Назва SSL лишилася в повсякденному вжитку, хоча сучасне захищене з’єднання працює на протоколі TLS. Сертифікат містить домен, відкритий ключ, дані центру сертифікації та строк чинності. Браузер перевіряє, чи виданий він довіреним центром, чи відповідає домену та чи не минув строк дії.

HTTPS забезпечує:

• шифрування — сторонній не повинен прочитати трафік між відвідувачем і сервером;

• цілісність — дані не мають бути непомітно змінені під час передавання;

• автентифікацію — браузер перевіряє, що сертифікат видано для потрібного домену.

Водночас SSL не лікує заражений сайт, не закриває вразливості CMS і не замінює контроль доступів. Якщо є підозра на злам, потрібна окрема перевірка сайту на віруси й уразливості.

Безкоштовний чи платний SSL

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

Тип	Що перевіряється	Коли підходить
DV	контроль над доменом	більшість сайтів, блогів, магазинів і сервісів
OV	домен і дані організації	компанії з внутрішніми вимогами до верифікації
EV	розширена перевірка організації	регульовані сфери або формальна вимога політики
Wildcard	домен і всі піддомени одного рівня	багато динамічних піддоменів
SAN / multidomain	кілька вказаних доменів	один проєкт працює на кількох доменах

Перед покупкою перевірте, чи не входить SSL у тариф. Це один із критеріїв у гайді як вибрати хостинг для сайту. Важливіше за бренд сертифіката — підтримка всіх потрібних імен, автоматичне подовження та правильна конфігурація сервера.

Що підготувати перед переходом

Не починайте зі зміни адрес у CMS. Спочатку зафіксуйте поточний стан:

1. Зробіть повну копію файлів і бази даних та перевірте відновлення. Детальний порядок є в інструкції про резервне копіювання сайту.

2. Складіть список доменів: example.com, www.example.com, піддомени, панель, API та поштові вебінтерфейси.

3. Визначте, де завершується HTTPS: на сервері, балансувальнику, CDN або reverse proxy.

4. Перевірте доступи до домену, DNS, панелі хостингу, CMS, CDN і аналітики.

5. Збережіть поточні правила редиректів, canonical, sitemap і robots.txt.

6. Заплануйте вікно з низьким трафіком і людину, яка зможе швидко повернути конфігурацію.

Якщо одночасно змінюється сервер, не змішуйте всі зміни без контрольного плану. Спочатку ознайомтеся з процедурою перенесення сайту на інший хостинг.

Як установити SSL-сертифікат: 12 кроків

1. Визначте всі доменні імена

Сертифікат для example.com не завжди покриває www.example.com. Додайте обидва варіанти, якщо вони доступні, а також реальні піддомени. Не випускайте wildcard «про всяк випадок», якщо достатньо двох конкретних імен.

2. Випустіть сертифікат

Найпростіший шлях — функція SSL/TLS або Let’s Encrypt у панелі хостингу. Якщо керуєте сервером самостійно, використовуйте підтримуваний ACME-клієнт та офіційну документацію вашого вебсервера. Для перевірки домену центр сертифікації може використовувати HTTP-запит або DNS-запис.

3. Установіть сертифікат і повний ланцюжок

Серверу потрібні сертифікат домену, проміжні сертифікати та приватний ключ. Неповний ланцюжок іноді працює на одному пристрої, але дає помилку на іншому. Приватний ключ не надсилайте в чатах або електронною поштою, не зберігайте у відкритому репозиторії та обмежте доступ до файла.

4. Налаштуйте HTTPS на рівні сервера або проксі

Переконайтеся, що правильний сертифікат прив’язаний до потрібного virtual host. Якщо перед сервером працює CDN, балансувальник або Cloudflare, захищеними мають бути обидві ділянки: браузер — проксі та проксі — origin. Режим, за якого проксі звертається до origin через HTTP, створює хибне відчуття повного захисту.

5. Змініть основну адресу в CMS

У налаштуваннях CMS укажіть канонічну HTTPS-адресу. Для WordPress перевірте поля WordPress Address і Site Address, але спочатку переконайтеся, що HTTPS уже відповідає. Інакше можна втратити доступ до адмінпанелі.

6. Замініть внутрішні HTTP-адреси

Оновіть посилання на зображення, CSS, JavaScript, шрифти, iframe, API та завантаження. Для бази WordPress використовуйте інструмент, який коректно обробляє серіалізовані дані, а не сліпу SQL-заміну. Перед масовою операцією створіть копію.

7. Усуньте mixed content

Mixed content виникає, коли HTML відкрито через HTTPS, але окремий ресурс запитується через HTTP. Браузер може заблокувати скрипт, стиль або iframe, через що зникне форма, меню чи оплата. Відкрийте DevTools, знайдіть HTTP-запити та замініть їх на HTTPS-версії. Якщо сторонній сервіс не підтримує HTTPS, його треба замінити або прибрати.

8. Налаштуйте один 301 редирект

Усі HTTP-адреси мають переходити на відповідні HTTPS-адреси одним постійним редиректом:

http://example.com/page → https://example.com/page

Одночасно визначте основний варіант із www або без нього. Уникайте ланцюжка HTTP → HTTPS www → HTTPS без www і циклів між сервером, CMS та CDN.

9. Оновіть SEO-сигнали

Замініть URL у canonical, hreflang, XML sitemap, структурованих даних і внутрішніх посиланнях. Перевірте, що robots.txt не блокує HTTPS-сторінки, а sitemap містить лише фінальні адреси з кодом 200. Додайте HTTPS-ресурс до інструментів вебмайстра, якщо платформа розрізняє протоколи.

10. Оновіть зовнішні системи

Змініть адресу в Google Analytics, Tag Manager, рекламних кабінетах, CRM, платіжних сервісах, webhook, email-шаблонах, картах і профілях компанії. Особливо перевірте callback URL авторизації та оплати.

11. Перевірте всі сценарії

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

12. Увімкніть автоподовження й моніторинг

Сертифікат повинен подовжуватися автоматично задовго до завершення дії. Переконайтеся, що запланована задача реально запускається, домен проходить повторну перевірку, а повідомлення про збій надходить на актуальну адресу. Разова успішна установка не гарантує наступного подовження.

Типові помилки SSL і що вони означають

Симптом або код	Ймовірна причина	Що перевірити
ERR_CERT_DATE_INVALID	сертифікат прострочений, ще не чинний або неправильний час	дату сервера й пристрою, строк дії, журнал автоподовження
ERR_CERT_COMMON_NAME_INVALID	домен не входить до сертифіката	SAN, варіанти www/без www, прив’язку virtual host
ERR_CERT_AUTHORITY_INVALID	недовірений центр або неповний ланцюжок	проміжні сертифікати, full chain, корпоративний proxy
«Не захищено» на частині сторінок	mixed content або форма надсилає дані через HTTP	Console і Network у DevTools, шаблони, плагіни, сторонні ресурси
ERR_TOO_MANY_REDIRECTS	конфлікт правил сервера, CMS і CDN	режим SSL проксі, forwarded headers, дублікати редиректів
SSL handshake / protocol error	несумісний протокол, шифр, SNI або збій origin	журнали сервера, конфігурацію TLS, сертифікат на origin

Не виправляйте помилку вимкненням HTTPS. Спочатку визначте, на якому рівні виникає збій: DNS, CDN, сервер, CMS або конкретний ресурс.

Особливості WordPress

Після встановлення SSL у WordPress часто залишаються старі HTTP-адреси в контенті, налаштуваннях теми та метаданих плагінів. Безпечна послідовність:

1. перевірити роботу https://домен;

2. зробити резервну копію;

3. змінити WordPress Address і Site Address;

4. виконати коректний search-replace з підтримкою серіалізованих даних;

5. очистити кеш CMS, сервера й CDN;

6. перевірити медіафайли, конструктор сторінок, форми та шрифти;

7. лише після цього ввімкнути глобальний 301 редирект.

За reverse proxy WordPress має правильно розпізнавати вихідний HTTPS-запит. Інакше з’являється нескінченний редирект або сайт генерує HTTP-посилання. Не копіюйте випадкові фрагменти конфігурації без розуміння заголовків, які передає саме ваш проксі.

Cloudflare, CDN і origin-сервер

Зелений замок між браузером і CDN ще не означає, що з’єднання до вашого сервера також захищене. Для повного шляху потрібен чинний сертифікат на origin і режим із перевіркою цього сертифіката. Якщо виник цикл, перевірте:

• який протокол CDN використовує до origin;

• чи виконує редирект сервер, CMS або правило CDN;

• чи передається коректний заголовок протоколу;

• чи доступний origin за потрібним ім’ям;

• чи не залишився старий сертифікат після зміни сервера.

Дані про DNS, IP і сервер допоможе зібрати інструкція як перевірити домен, хостинг і сервер.

Чи вплине перехід на HTTPS на SEO

Зміна протоколу змінює URL, тому пошуковій системі потрібні однозначні сигнали. Кожна стара сторінка повинна вести 301 редиректом на точний HTTPS-аналог; canonical, hreflang, sitemap та внутрішні посилання мають указувати на фінальну адресу. Не об’єднуйте перехід на HTTPS із масовою зміною структури URL без необхідності — тоді причину коливань буде складніше знайти.

Після запуску контролюйте:

• індексацію HTTPS-сторінок;

• появу старих HTTP-URL у звітах;

• коди 3xx, 4xx і 5xx;

• органічний трафік і ключові конверсії;

• швидкість та Core Web Vitals.

TLS додає обчислення, але сучасна коректна конфігурація зазвичай не є причиною повільного сайту. Якщо показники погіршилися, перевірте CDN, кеш і сервер за чеклістом прискорення завантаження сайту.

Як перевірити результат

Після міграції перевірте чотири варіанти головної адреси: HTTP/HTTPS і www/без www. Три неосновні варіанти мають одним маршрутом вести на обраний канонічний URL. Далі:

• відкрийте інформацію про сертифікат у браузері й перевірте домен, видавця та строк дії;

• у DevTools переконайтеся, що немає HTTP-запитів і заблокованих ресурсів;

• командою curl -I подивіться коди відповіді та заголовок Location;

• через openssl s_client перевірте ланцюжок і SNI, якщо маєте технічний досвід;

• протестуйте конфігурацію незалежним SSL-сканером;

• обійдіть сайт краулером і знайдіть внутрішні HTTP-посилання;

• перевірте форми, оплату, API та webhook;

• змоделюйте автоподовження або перегляньте журнал тестового запуску.

Інші матеріали про сервер, домени й підтримку зібрані в категорії «Хостинг і технічне».

Чекліст після підключення HTTPS

• Сертифікат охоплює домен, www і потрібні піддомени.

• Сервер віддає повний довірений ланцюжок.

• Приватний ключ зберігається з обмеженим доступом.

• Усі HTTP-URL переходять на точні HTTPS-аналоги кодом 301.

• Немає циклів і ланцюжків редиректів.

• Canonical, hreflang, sitemap і structured data містять HTTPS.

• У коді та базі немає внутрішніх HTTP-ресурсів.

• Форми, оплата, авторизація та API працюють.

• CDN і origin використовують захищене з’єднання.

• Аналітика та конверсії надходять після зміни адреси.

• Автоподовження ввімкнене й протестоване.

• Налаштоване сповіщення про помилку або наближення завершення дії.

Поширені помилки

1. Сертифікат випущено лише для одного варіанта домену. У результаті www або піддомен показує попередження.

2. HTTPS увімкнено, але адреси в CMS не змінено. Сайт продовжує створювати HTTP-посилання.

3. Редирект налаштовано одночасно всюди. Сервер, плагін і CDN сперечаються та створюють цикл.

4. Використано тимчасовий 302 замість постійного 301. Пошукові сигнали передаються менш однозначно.

5. Не перевірено mixed content. Частина функцій блокується лише на окремих сторінках.

6. Забуто про автоподовження. Через кілька тижнів або місяців сайт раптово стає недоступним для частини користувачів.

7. Приватний ключ передають стороннім. У разі витоку сертифікат слід перевипустити, а ключ замінити.

Коли робити самостійно, а коли звернутися до спеціаліста

Самостійне підключення доречне, якщо хостинг має автоматичний SSL, сайт невеликий, є актуальна копія та зрозумілий спосіб відкату. Допомога потрібна, якщо використовується VPS, кілька піддоменів, CDN, reverse proxy, магазин, платіжні системи або нестандартний сервер; якщо зміна вже спричинила цикл, недоступність адмінпанелі чи падіння заявок.

Для аудиту конфігурації та безпечного переходу зв’яжіться з BB STUDIO. Перед початком зафіксуємо резервну копію, канонічну адресу, точки завершення TLS та критерії перевірки.

FAQ

Чи можна отримати SSL-сертифікат безкоштовно?

Так. Для більшості звичайних сайтів достатньо безкоштовного DV-сертифіката, який хостинг або ACME-клієнт автоматично випускає і подовжує. Важливо перевірити не ціну, а покриття доменів, повний ланцюжок і надійність автоподовження.

Чому сайт усе ще показує «Не захищено» після встановлення SSL?

Найчастіше сторінка завантажує зображення, скрипт, шрифт або iframe через HTTP. Інші причини — неправильний домен у сертифікаті, неповний ланцюжок, кеш або прострочений сертифікат.

Чи потрібно закривати порт 80 після переходу?

Зазвичай ні. HTTP-запити на порт 80 потрібні для перенаправлення користувачів на HTTPS і можуть використовуватися під час автоматичної перевірки домену. Сервер повинен відповідати безпечним редиректом, а не віддавати окрему незахищену версію сайту.

Чи втратить сайт позиції після переходу на HTTPS?

Короткочасні коливання можливі під час переобходу URL, але коректні 301 редиректи, canonical, sitemap і внутрішні посилання дають пошуковій системі однозначний маршрут. Найбільший ризик створюють помилки міграції, а не HTTPS як такий.

Як часто треба подовжувати сертифікат?

Строк залежить від центру сертифікації та його поточної політики. Не покладайтеся на ручний календар: налаштуйте автоматичне подовження, тестовий запуск і сповіщення про збій.