Як вирішити проблеми з помилками сертифіката TLS та сторінками HTTPS, які не завантажуються

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

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

Що таке сертифікат TLS/SSL і чому HTTPS-з’єднання розривається?

Перш ніж щось чіпати, важливо зрозуміти, що відбувається під ним. Сертифікат TLS/SSL – це цифровий файл, який ідентифікує ваш сайт і шифрує дані між браузером і сервером.Саме це дозволяє вам перейти з HTTP на HTTPS і побачити знаменитий замок в адресному рядку.

Цей сертифікат видається визнаним центром сертифікації (CA) та містить доменне ім'я, терміни дії та відкритий ключВін супроводжується ланцюжком проміжних сертифікатів, які поширюють довіру аж до кореневого центру сертифікації. Якщо щось у цьому ланцюжку або в конфігурації неправильне, браузер порушує довіру та відображає повідомлення про помилку.

У наші дні люди майже ніколи не говорять про «чистий» SSL. Сучасні браузери використовують TLS (Transport Layer Security), еволюцію SSL.Хоча ми все ще звично використовуємо SSL/TLS, принцип той самий: узгоджується зашифроване з’єднання, сертифікат перевіряється, і, якщо все йде добре, користувач переглядає веб-сторінки із захищеними даними.

Коли справи йдуть не дуже добре, трапляється ось що Браузер не може перевірити, чи сервер є тим, за кого себе видає, або чи відповідає з'єднання мінімальним вимогам безпеки.Там ви знайдете такі помилки, як ERR_SSL_PROTOCOL_ERROR, недійсні сертифікати, попередження про «неприватне з’єднання» та інші приємні речі, які відлякають будь-якого пересічного відвідувача.

Найчастіші причини помилок сертифікатів TLS та HTTPS, які не завантажуються

Не всі сповіщення безпеки з'являються з однієї й тієї ж причини. За помилкою сертифіката TLS можуть стояти проблеми з конфігурацією сервера, збої сертифікатів, помилки DNS або навіть локальні налаштування користувача. (дата, антивірус, брандмауер тощо). Розуміння причин позбавляє вас від здогадок.

Перша суттєва відмінність полягає між помилки на стороні сервера (вебсайт) та помилки на стороні клієнта (пристрій користувача)Як адміністратори, ми можемо діяти лише на стороні сервера, але корисно знати обидві сторони, щоб правильно діагностувати проблему.

Серед найпоширеніших причин на стороні сервера є: Сертифікати, термін дії яких минув, невідповідні домени, неповні проміжні рядки, застарілі протоколи TLS або погано налаштовані переадресації HTTP/HTTPSЗмішаний контент також є поширеним явищем: сторінка завантажується через HTTPS, але деякі ресурси все ще запитуються через HTTP.

З точки зору користувача, багато страхів походять від Неправильна системна дата та час, пошкоджений кеш браузера, перехоплення з'єднання антивірусом або брандмауерами, несправний DNS або змінені файли hostsВсе це може викликати попередження, такі як ERR_SSL_PROTOCOL_ERROR, навіть якщо сервер налаштовано ідеально.

Типові помилки SSL/TLS та що вони насправді означають

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

Одним з найбільш відомих є ERR_SSL_PROTOCOL_ERRORЦе вказує на те, що браузер не зміг завершити протокол TLS з цим сервером: це може бути пов'язано з простроченим сертифікатом, непідтримуваним протоколом, змішаним вмістом, помилками в ланцюжку довіри або навіть пошкодженим файлом hosts, який перенаправляє вас до іншого місця призначення, ніж ви очікували.

Ще одна класика ERR_CERT_COMMON_NAME_INVALIDЦе сповіщення з’являється, коли доменне ім’я в сертифікаті не відповідає домену, до якого ви намагаєтеся отримати доступ. Це серйозне попередження, оскільки Це може бути симптомом атаки типу «людина посередині» або поганої конфігурації сервера. (наприклад, обслуговування одного й того ж сертифіката для кількох доменів без відповідних SAN).

Також часто можна побачити NET :: ERR_CERT_AUTHORITY_INVALIDЦе вказує на те, що сертифікат не був виданий центром сертифікації, якому довіряє браузер. Це може бути пов'язано з самопідписаними сертифікатами, внутрішніми сертифікатами або тим, що антивірус чи проксі-сервер впроваджує власний сертифікат, який браузер не розпізнає як довірений.

Тісно пов'язане це Net :: ERR_CERT_DATE_INVALIDЦе вказує на проблему з датою: або термін дії сертифіката минув, або час комп’ютера користувача не відповідає терміну дії. Сертифікати TLS мають дату; якщо термін дії минув, браузер вважатиме, що йому не можна довіряти.

Є й інші, менш приємні повідомлення, такі як ERR_SSL_VERSION_OR_CIPHER_MISMATCHЗазвичай це з'являється, коли сервер підтримує лише старіші протоколи або набори шифрів, які сучасні браузери більше не приймають. На практиці це означає, що Конфігурація сервера застаріла та потребує оновлення.

У деяких випадках ми стикаємося ERR_SSL_WEAK_EPHEMERAL_DH_KEYЦе вказує на те, що сервер використовує недостатньо слабкі тимчасові ключі Діффі-Хеллмана. Користувач мало що може з цим вдіяти. Відповідальність лежить на адміністраторі сервера, який повинен модернізувати криптографічну конфігурацію..

Зрештою, хоча це не є помилкою сертифіката як такою, повідомлення ERR_TOO_MANY_REDIRECTS Це трапляється, коли правила перенаправлення між HTTP та HTTPS, або між версіями з www та без www, створюють нескінченний цикл. Браузер перескакує з однієї URL-адреси на іншу, доки не зупиниться, і сторінка так і не завантажиться.

Помилки змішаного вмісту та «не повністю захищені» HTTPS-сайти

Одна з найпідступніших проблем полягає в тому, помилки змішаного вмістуЦе трапляється, коли головна сторінка завантажується через HTTPS, але Деякі внутрішні ресурси (зображення, скрипти, таблиці стилів, iframe…) все ще викликаються через HTTPРезультат: браузер попереджає, що сайт не повністю безпечний, або безпосередньо блокує ці ресурси.

Такий сценарій дуже поширений після перенесення сайту з HTTP на HTTPS без належної перевірки внутрішніх маршрутів. Кілька зображень або скрипт з абсолютною URL-адресою в HTTP достатньо для запуску попереджень.У робочих середовищах деякі браузери навіть блокують небезпечні скрипти або iframe, порушуючи критично важливу функціональність.

Пошук цих ресурсів залежить від перевірки коду або використання інструментів аудиту. Рішення включає зміну URL-адрес на HTTPS, використання шляхів, відносних до схеми, або оновлення шаблонів і плагінів, які генерують застарілі посилання.У багатьох CMS достатньо хорошого інструменту пошуку та заміни в базі даних (якщо його використовувати обережно), щоб виправити сотні посилань одночасно.

Ми говоримо не лише про зображення чи CSS. Зовнішні скрипти, сторонні бібліотеки та виклики API також повинні передаватися через HTTPSЯкщо ваша сторінка завантажується через HTTPS, але містить виклики API, що використовують HTTP, деякі браузери блокуватимуть запити, порушуватимуть процес входу або запобігатимуть завантаженню певних модулів.

У конкретному випадку сучасних застосувань також необхідно переглянути URI перенаправлення OAuth (наприклад, з Google), що вказують на localhost або HTTPТака комбінація може спричиняти дивні помилки, неочікувані попередження щодо сертифікатів (наприклад, самопідписаний сертифікат від "localhost") та, на додачу до всього, впливати лише на певного користувача або середовище.

Поширені проблеми з встановленням та дійсністю сертифікатів

Окрім неоднозначного вмісту, значна частина конфлікту виникає через те, як було встановлено або поновлено сертифікат. Погано встановлений або недійсний SSL/TLS-сертифікат зазвичай пов'язаний з невідповідністю доменів, неповними проміжними ланцюгами або серверами, які все ще обслуговують старий сертифікат..

Якщо сертифікат не відповідає домену (наприклад, він охоплює лише mydomain.com, але ви заходите на www.mydomain.com), браузер позначить з’єднання як небезпечне. Під час придбання або створення сертифіката необхідно переконатися, що ви включили всі необхідні варіанти (з www та без нього, субдоменами тощо).або використовуйте підстановочні SAN, коли це доречно.

Ще одна класична помилка — забудьте про середній ланцюгБагато центрів сертифікації (CA) доставляють кілька файлів; якщо сервер обслуговує лише основний сертифікат без ланцюжка до кореневого CA, деякі браузери не зможуть встановити довіру. Результат: Користувач бачить сертифікат, який здається дійсним, але браузер не розпізнає його як такий..

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

На керованих платформах, таких як Azure App Service або Vercel, також враховуються інші фактори. дозволи на доступ до сховища ключів або зв'язки між сертифікатами та користувацькими доменамиЯкщо служба, яка керує сертифікатами, не має достатніх дозволів на доступ до сховища ключів або якщо автоматичну синхронізацію не запущено, програма продовжуватиме використовувати старий сертифікат.

Нам також потрібно бути пильними поєднання SNI-посилань та SSL-посилань на основі IPУ деяких середовищах, коли обидва використовуються одночасно, клієнти, які не підтримують SNI, завжди отримують сертифікат, прив'язаний до їхньої IP-адреси, навіть якщо вони отримують доступ до сайту через домен, який повинен використовувати інший. Це може призвести до відображення неправильного сертифіката, який, здавалося б, «випадково» залежить від того, хто підключається.

Переадресації HTTP/HTTPS, домени та DNS: джерела невидимих ​​помилок

Навіть з бездоганним сертифікатом ваш вебсайт може не завантажуватися через HTTPS, якщо є проблеми з перенаправлення, домен або DNSЦі шари, до яких ми зазвичай торкаємося один раз і забуваємо, є невичерпним джерелом ледь помітних помилок.

Щоб сайт завжди виглядав безпечним, це нормально Примусово ввімкнути HTTPS за допомогою правил перенаправлення (наприклад, у .htaccess, Nginx, панелі керування хостингом або зворотному проксі)Якщо ці правила налаштовано неправильно, можна створювати цикли між http:// та https:// або між www та не-www. Типовий результат: ERR_TOO_MANY_REDIRECTS або сторінка, яка просто не відображається.

Також потрібно подбати про те, як домен налаштовано у DNS-провайдера. Під час вказівки домену на веб-застосунок або хмарний сервіс необхідно правильно використовувати записи A, CNAME та TXT.Використання запису A та запису CNAME для одного й того ж хоста, забуття перевірочного TXT або неоновлення IP-адреси під час зміни серверів призведе до помилок розв'язання (DNS_PROBE_FINISHED_NXDOMAIN та інші).

Крім того, DNS не оновлюється миттєвоКожен запис має значення TTL (час життя), яке вказує, як довго резолвери можуть його кешувати. Якщо ви нещодавно змінили хостинг-провайдера або IP-адресу, для деяких користувачів нормально бачити старий сайт або помилку 404 протягом кількох годин. Такі інструменти, як WhatsMyDNS, можуть допомогти перевірити, чи поширення відбувається правильно.

В інших випадках проблема полягає в браузері або системі користувача. Локальний DNS та кеш браузера можуть зберігати старі адреси.Очистіть кеш, скиньте DNS (наприклад, за допомогою IPCONFIG / flushdns (у Windows) або перезавантаження маршрутизатора зазвичай достатньо, щоб забезпечити правильне визначення домену та правильного сервера.

Не можна забувати і про архів. хостів операційної системи. До появи DNS все вирішувалося там, і він досі використовується для фіксованих зіставлень у локальних мережах. Шкідливе програмне забезпечення, інструменти налагодження або застарілі конфігурації можуть змінити його та перенаправити вас на неочікувані IP-адреси або підроблені сертифікати.Відновлення файлу до стану за замовчуванням зазвичай усуває багато незрозумілих помилок ERR_SSL_PROTOCOL_ERROR одним махом.

Спеціальні сценарії: хмари, панелі та обмеження платформи

Якщо ви працюєте з керованими платформами (Azure, Vercel, cPanel тощо), виникають помилки, зумовлені самою інфраструктурою. Спосіб, яким ви пов’язуєте сертифікати з програмами, ліміти покупок і тип плану, впливає на те, як і коли ви можете використовувати TLS..

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

Також відносно поширеним є те, що Той самий сертифікат намагається підключитися до кількох програм з однаковою IP-адресою, використовуючи посилання на основі IP-адрес.Якщо VIP-користувач вже використовує цей сертифікат, портал може відмовити у додаванні другого зв’язування та відобразити повідомлення про помилку, в якому зазначено, що «інший VIP-користувач вже використовує цей сертифікат». Рішенням є видалення попереднього зв’язування або використання зв’язування SNI, коли це можливо.

Щодо користувацьких доменів, придбаних через ці платформи, важливо зазначити, що Вони покладаються на зовнішніх реєстраторів (таких як GoDaddy) та Azure DNS або інших постачальників послуг хостингу DNS.Це означає, що ви можете мати ліміти покупок, правила автоматичного поновлення та окремі витрати на реєстрацію та DNS.

Якщо домен видалено помилково, зазвичай Існує короткий період (кілька днів), протягом якого його можна відновити без додаткової оплати.Після цього періоду вам потрібно буде звернутися до служби підтримки постачальника або реєстратора, щоб дізнатися, чи він все ще доступний і як його відновити. Тим часом пов’язані сертифікати будуть заблоковані.

Нарешті, Формат сертифікатів має значенняБагато платформ вимагають файлів .pfx з паролем та повним рядком. Якщо ваш центр сертифікації надає сертифікати у форматі .pem або .key, вам потрібно буде конвертувати їх (наприклад, за допомогою OpenSSL) та включити закритий ключ і всі проміжні дані у правильному порядку, перш ніж ви зможете їх завантажити.

Як виправити помилки SSL-з'єднання з боку користувача

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

Перше, що потрібно зробити, це переглянути дата й час вашої системиВсього кілька хвилин затримки достатньо, щоб деякі, здавалося б, дійсні сертифікати вважалися такими, що прострочені, або «ще недійсними». Увімкнення автоматичної синхронізації дати та часу (у Windows, macOS, Android або iOS) зазвичай вирішує значну кількість помилок SSL-з’єднання одночасно.

Далі, час прибрати в будинку: очистити файли cookie та кеш браузераУ Chrome, Firefox, Safari та інших браузерах ви можете видалити збережені файли cookie та тимчасові файли з меню налаштувань. Це змушує браузер знову запитувати сертифікати та запобігає подальшому перенесенню старих станів або застарілих переадресацій.

На настільних комп'ютерах це гарна ідея видалити SSL-сертифікати «slate» або кешовані сертифікати в системіУ Windows це робиться в розділі «Властивості браузера» на вкладці «Вміст» за допомогою кнопки «Очистити стан SSL». У macOS можна використовувати «Доступ до зв’язки ключів», щоб знайти сертифікати, пов’язані з певним доменом, і видалити їх вручну.

Якщо все залишиться так само, наступним підозрюваним буде програмне забезпечення безпекиДеякі антивірусні програми та брандмауери перехоплюють HTTPS-з’єднання для аналізу, впроваджуючи власні сертифікати. Якщо під час цього процесу щось піде не так, з’являться помилки недійсного авторизації або протоколу. Тимчасове вимкнення антивіруса або брандмауера (лише для тестування) може підтвердити, чи є вони винуватцями.

Ще одна швидка перевірка Спробуйте скористатися іншим браузером або пристроєм, а якщо можливо, навіть іншою мережею (мобільні дані замість Wi-Fi).Якщо це працює в інших браузерах і на інших пристроях, проблема у вашому комп’ютері. Якщо ж помилка не працює всюди, найімовірніше, проблема пов’язана із сервером або доменом.

Найкращі практики запобігання помилкам сертифікатів TLS

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

Перший пункт очевидний, але його легко забути: Поновлюйте сертифікати до закінчення терміну їхньої дії та, якщо можливо, автоматизуйте процесЗа допомогою Let's Encrypt та багатьох сучасних центрів сертифікації легко налаштувати автоматичне поновлення, тому вам не доведеться пам’ятати про це кожні кілька місяців. Тим не менш, гарною ідеєю буде стежити за термінами дії підписки та отримувати сповіщення.

Це також має вирішальне значення Підтримуйте сервер і протоколи безпеки в актуальному станіSSLv3, TLS 1.0 та інші застарілі протоколи необхідно вимкнути, а замість них слід використовувати TLS 1.2 та 1.3, а також сучасні набори шифрів та достатньо надійні ключі. Такі посібники, як «Конфігурація SSL від Mozilla», можна використовувати як орієнтир для налаштування сервера з прийнятним рівнем безпеки.

Не менш важливим є Періодично перевіряйте правила перенаправлення між HTTP та HTTPS, а також між варіантами доменуЗдавалося б, невинна зміна (нове правило в .htaccess, проксі-CDN, вставлений WAF) може призвести до зациклення або перенаправлення трафіку до незахищеної версії. Перевірка переадресацій та виконання повноцінних тестів навантаження після кожної зміни є гарною практикою.

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

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

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

Пов'язана стаття:

Фільтрування критичних подій, попереджень та помилок за допомогою Get-WinEvent

Ісаак

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