SSL-сертифікат не працює на хостингу: як перестати бачити «Ваше з'єднання не захищене» і повернути довіру
Уявіть: ви нарешті запустили сайт, розіслали посилання клієнтам, відкрили шампанське - і раптом вам надсилають скріншот з червоним замком та написом «Ваше з'єднання не захищене». Клієнт закриває вкладку. Google знижує позиції. Конверсія падає в прірву. А ви навіть не розумієте, що пішло не так, бо у вас все відкривається нормально. Знайомо? Проблеми з SSL-сертифікатами на хостингу - це одна з тих пасток, що виглядає як дрібниця, поки не з'їдає ваші гроші та репутацію.
Давайте розберемося, чому SSL ламається, як це діагностувати самостійно і - головне - як виправити все за хвилини, а не за дні листування з підтримкою хостингу.
Чому браузер кричить на ваш сайт, хоча сертифікат встановлений
Перше, що потрібно зрозуміти: встановити SSL-сертифікат і налаштувати його правильно - це дві абсолютно різні речі. Це як купити замок на двері, але не вставити його в дверну раму. Формально замок є. Фактично двері відкриті.
Найчастіша ситуація: ви натиснули кнопку «Встановити Let's Encrypt» у cPanel або ISPmanager, побачили зелену галочку і вирішили, що справу зроблено. Але браузер каже інше. Чому?
- Неповний ланцюжок сертифікатів (chain) - сервер віддає тільки кінцевий сертифікат без проміжних, і браузер не може побудувати довірчий шлях до кореневого центру сертифікації
- Mixed content - сайт вантажить CSS, JS або зображення по http замість https, і браузер вважає з'єднання небезпечним
- Невідповідність доменного імені - сертифікат випущений для example.com, але сайт відкривається через www.example.com або піддомен
- Протермінований сертифікат - автооновлення тихо зламалося, а ви дізналися останніми
- Конфлікт з Cloudflare або CDN - два рівні SSL накладаються один на одного і створюють цикл редиректів
Кожна з цих причин має своє рішення. І жодна з них не потребує диплома з кібербезпеки.
Діагностика за п'ять хвилин: інструменти, які знає не кожен адмін
Перш ніж щось чіпати на сервері, потрібно зрозуміти, що саме зламано. Ось мій перевірений алгоритм, який я використовую вже років сім:
- SSL Labs Server Test (ssllabs.com/ssltest) - вставляєте домен, чекаєте 2 хвилини, отримуєте детальний звіт. Оцінка нижче B? Є проблема. Оцінка F? У вас пожежа.
- Why No Padlock (whynopadlock.com) - сканує сторінку на mixed content і показує конкретні URL, що вантажаться по http. Безцінна штука.
- Перевірка ланцюжка сертифікатів - команда openssl s_client -connect yourdomain.com:443 -servername yourdomain.com покаже весь chain. Якщо бачите «verify error» - проміжний сертифікат не на місці.
- Перевірка дати - в тому ж openssl дивіться поля «Not Before» та «Not After». Прострочено? Ось і відповідь.
- Інспектор браузера (F12) - вкладка Security в Chrome покаже, що конкретно не так з SSL на цій сторінці. Вкладка Console - всі http-ресурси, що блокуються.
Золоте правило: ніколи не починайте «лагодити» SSL наосліп. Спочатку діагностика - потім дія. Інакше ви ризикуєте перетворити одну проблему на п'ять.
Mixed content: невидимий ворог, що ховається у ваших картинках
Ось вам реальна історія. Один мій знайомий запустив інтернет-магазин на WordPress. SSL встановлений, замочок зелений. Через тиждень дзвонить: «На сторінках товарів замочок зник, Google Search Console сипле попередженнями». Виявилося, менеджер контенту завантажував зображення через старі посилання з http. Кілька картинок - і браузер знімає статус «безпечне з'єднання» з усієї сторінки.
Mixed content - це коли ваша https-сторінка підтягує ресурси по http. Браузер сприймає це як діру в захисті. І він правий.
Як це виправити?
- Запустіть пошук по базі даних WordPress (плагін Better Search Replace) і замініть всі http://вашдомен на https://вашдомен
- Перевірте хардкод у темі - деякі розробники прописують URL зображень напряму в шаблонах
- Додайте заголовок Content-Security-Policy: upgrade-insecure-requests - це змусить браузер автоматично конвертувати http-запити в https
- Перевірте зовнішні скрипти: Google Fonts, аналітику, віджети чатів - все повинно вантажитися по https
Здається дрібницею? Але Google офіційно заявив ще у 2014 році: HTTPS - фактор ранжування. А з 2018-го Chrome маркує всі http-сайти як «не безпечні». Кілька забутих картинок можуть коштувати вам позицій у видачі.
Ланцюжок сертифікатів: де зазвичай ламається довіра
Це технічна тема, але я спробую пояснити її через аналогію. Уявіть, що SSL-сертифікат - це паспорт вашого сайту. Щоб паспорт визнали дійсним, потрібен підпис від органу, якому довіряє браузер. Але ваш сертифікат підписаний не напряму кореневим центром (Root CA), а проміжним (Intermediate CA). Якщо сервер не віддає цей проміжний сертифікат разом з основним - браузер не може перевірити ланцюжок і показує помилку.
«Більше 30% усіх помилок SSL-з'єднань пов'язані з неправильною конфігурацією ланцюжка сертифікатів, а не з самим сертифікатом» - дослідження Netcraft, 2023
Як виправити? Потрібно знайти правильний intermediate certificate для вашого сертифіката (зазвичай він є на сайті центру сертифікації) і додати його у файл, який ваш вебсервер використовує як ssl_certificate. В Nginx це виглядає так: ви об'єднуєте ваш сертифікат та проміжний в один файл командою cat. В Apache прописуєте директиву SSLCertificateChainFile окремо.
Якщо ви на shared-хостингу і не маєте доступу до конфігурації вебсервера - зверніться до підтримки. Але зверніться грамотно: не «у мене SSL не працює», а «сервер не віддає intermediate certificate, ось результат SSL Labs - chain incomplete». Повірте, швидкість відповіді зросте вдвічі.
Порівняння типових SSL-проблем: що ламається, де шукати, скільки часу на фікс
| Проблема | Симптом у браузері | Де шукати причину | Час на виправлення |
|---|---|---|---|
| Протермінований сертифікат | ERR_CERT_DATE_INVALID | cPanel / certbot / панель провайдера | 5-10 хвилин |
| Неповний ланцюжок | ERR_CERT_AUTHORITY_INVALID | Конфігурація Nginx/Apache | 10-20 хвилин |
| Mixed content | Замочок зі знаком оклику або без замочка | Інспектор браузера, Console | 15-60 хвилин |
| Невідповідність домену | ERR_CERT_COMMON_NAME_INVALID | Налаштування сертифіката (SAN/CN) | 5-15 хвилин |
| Цикл редиректів з CDN | ERR_TOO_MANY_REDIRECTS | Налаштування Cloudflare (SSL mode) | 5 хвилин |
| Автооновлення зламалося | ERR_CERT_DATE_INVALID (раптово) | cron, certbot renew, логи | 10-30 хвилин |
Зверніть увагу: більшість проблем вирішуються за пів години або швидше. Але тільки якщо ви знаєте, куди дивитися. Без діагностики можна витратити дні.
Автооновлення Let's Encrypt: чому воно зламалося і як зробити його «вічним»
Let's Encrypt - геніальний проєкт. Безкоштовні сертифікати, автоматичне оновлення кожні 90 днів. Красота. Але ось проблема: автооновлення ламається мовчки. Ви не отримуєте жодного сповіщення, поки сертифікат не протухне і сайт не впаде.
Типові причини поломки автооновлення:
- Зміна DNS - ви перенесли домен на Cloudflare, і http-01 challenge перестав проходити, бо запити йдуть через проксі
- Зміна шляхів на сервері - оновили вебсервер, змінили DocumentRoot, і certbot більше не може покласти файл верифікації у потрібну папку
- Заповнений диск - банально, але часто. Certbot не може записати новий сертифікат, тихо падає в лог, який ніхто не читає
- Застарілий certbot - старі версії мають баги з новими версіями ACME-протоколу
Рішення? По-перше, завжди налаштовуйте моніторинг закінчення сертифіката. Безкоштовний сервіс UptimeRobot вміє перевіряти SSL і слати алерти за 14 днів до закінчення. По-друге, запустіть вручну certbot renew --dry-run після будь-яких змін на сервері. Ця команда симулює оновлення без реальних змін і покаже помилки, якщо вони є.
І третє - додайте в cron не тільки certbot renew, але й перезавантаження вебсервера після цього. Навіть якщо сертифікат оновився на диску, Nginx чи Apache продовжуватимуть використовувати старий, поки не перечитають конфігурацію.
Cloudflare + хостинг: коли два захисники б'ються між собою
Окрема історія болю - це конфлікт SSL між Cloudflare і вашим хостингом. Cloudflare пропонує три режими SSL: Off, Flexible, Full і Full (Strict). І вибір неправильного режиму - причина номер один циклічних редиректів.
Як це працює: Cloudflare стоїть між користувачем і вашим сервером. Якщо ви обрали Flexible - Cloudflare з'єднується з вашим сервером по http, навіть якщо на ньому є SSL. А ваш сервер бачить http-запит і перенаправляє на https. Cloudflare знову з'єднується по http. І так по колу. Браузер показує ERR_TOO_MANY_REDIRECTS.
Правильне рішення: завжди використовуйте режим Full (Strict), встановіть дійсний сертифікат на хостингу і забудьте про Flexible як про страшний сон. Режим Flexible створений для ситуацій, коли SSL на сервері неможливий - а це вже рідкість навіть на найдешевших хостингах.
Якщо вам ліньки возитися з Let's Encrypt на сервері - Cloudflare дає Origin Certificate, який валідний 15 років, але працює тільки через їхню мережу. Встановлюєте його на сервер, обираєте Full (Strict) - і SSL працює без жодних проблем.
SSL на хостингу - це не та річ, яку можна налаштувати один раз і забути. Сертифікати протухають, конфігурації ламаються, CDN-сервіси додають нові шари складності. Але з правильними інструментами і розумінням того, як працює ланцюжок довіри, ви перетворюєте цю задачу з нічного кошмару на рутинну п'ятихвилинну перевірку. Запитайте себе прямо зараз: коли ви востаннє перевіряли свій SSL через SSL Labs? Якщо відповідь «ніколи» або «не пам'ятаю» - відкрийте нову вкладку і зробіть це. Результат може вас здивувати.