12 Способів Виправити Помилку NET::ERR_CERT_DATE_INVALID (Повний Технічний Посібник)

Помилка NET::ERR_CERT_DATE_INVALID — це збій TLS-рукостискання на рівні браузера, який виникає, коли клієнт не може перевірити часову цілісність SSL/TLS-сертифіката — тобто сертифікат прострочений, ще не дійсний, або системний годинник відхилений настільки, що виходить за межі вікна дійсності сертифіката. Chrome, Edge, Firefox і Safari блокують доступ, коли ця перевірка не проходить, відображаючи жорстке попередження безпеки, а не м’яке сповіщення.

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

Чому NET::ERR_CERT_DATE_INVALID — це більше, ніж просто незручність у браузері

Коли браузер ініціює TLS-рукостискання, він перевіряє сертифікат сервера за трьома критеріями: центр сертифікації, що видав сертифікат, повинен бути довіреним, домен повинен відповідати альтернативним іменам суб’єкта (SAN) сертифіката, а поточна мітка часу повинна знаходитися між полями `notBefore` та `notAfter` сертифіката. Якщо перевірка мітки часу не проходить — на стороні клієнта або сервера — рукостискання переривається, і браузер відображає `NET::ERR_CERT_DATE_INVALID`.

Наслідки цього є значними. Окрім очевидного порушення взаємодії з користувачем, сканери Google також відхиляють HTTPS-ресурси з недійсними сертифікатами, що може знизити позиції в пошуку. Сайти, що працюють у середовищі VPS Хостингу, мають повний контроль над управлінням життєвим циклом сертифікатів, що робить вирішення проблем на стороні сервера простим — але причини на стороні клієнта вимагають структурованого підходу до діагностики.

Клієнт або сервер: діагностична схема

Перш ніж застосовувати будь-яке виправлення, визначте, яка сторона відповідальна. Це заощадить значний час.

Виправлення 1: Синхронізуйте системну дату та час

Це найпоширеніша причина на стороні клієнта. Якщо системний годинник відхилений більш ніж на кілька хвилин, бібліотека TLS відхилить сертифікати, вікно дійсності яких не охоплює неправильну локальну мітку часу. Сертифікат, дійсний з 1 січня по 31 грудня, виглядатиме «простроченим» для пристрою, годинник якого показує наступний січень.

Windows:

• Клацніть правою кнопкою миші на годиннику в системному треї та виберіть Налаштування дати/часу
• Увімкніть Встановлювати час автоматично та правильно встановіть часовий пояс
• Натисніть Синхронізувати зараз у розділі «Синхронізація годинника»
• Або примусово виконайте синхронізацію NTP через командний рядок (запустіть від імені адміністратора):

“`

w32tm /resync /force

“`

macOS:

• Перейдіть до Системні налаштування > Загальні > Дата та час
• Увімкніть Встановлювати час і дату автоматично та виберіть надійний NTP-сервер (наприклад, `time.apple.com`)

Linux (на стороні сервера):

“`bash

timedatectl set-ntp true

systemctl restart systemd-timesyncd

timedatectl status

“`

Важливий нюанс: На віртуальних машинах і контейнерах годинник гостьової системи може значно відхилятися від хостової. Якщо ви керуєте VPS, завжди перевіряйте вивід `timedatectl` після перезавантажень і налаштовуйте надійне джерело NTP, наприклад `pool.ntp.org`.

Виправлення 2: Очистіть кеш браузера та стан SSL

Браузери агресивно кешують відповіді сертифікатів і політики HSTS (HTTP Strict Transport Security). Кешована відповідь з недійсним сертифікатом може зберігатися навіть після усунення основної проблеми.

Очищення даних перегляду в Chrome:

• Перейдіть до `chrome://settings/clearBrowserData`
• Встановіть часовий діапазон За весь час
• Позначте Файли cookie та інші дані сайтів і Кешовані зображення та файли
• Натисніть Видалити дані

Очищення стану SSL у Windows (окремо від кешу браузера):

• Відкрийте Панель керування > Мережа та Інтернет > Властивості браузера
• Перейдіть на вкладку Вміст
• Натисніть Очистити стан SSL і підтвердіть

Очищення кешу HSTS у Chrome (часто ігнорується):

• Перейдіть до `chrome://net-internals/#hsts`
• У розділі «Видалити політики безпеки домену» введіть домен і натисніть Видалити

Цей крок особливо важливий, якщо домен раніше мав дійсний заголовок HSTS з довгим `max-age`. Браузер примусово використовуватиме HTTPS, навіть якщо сертифікат недійсний, і запис HSTS необхідно очистити окремо.

Виправлення 3: Оновіть браузер до останньої версії

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

Оновлення Chrome:

• Натисніть меню з трьома крапками > Довідка > Про Google Chrome
• Chrome автоматично виявить і застосує очікувані оновлення
• Перезапустіть браузер для завершення оновлення

Чому це важливо технічно: Chrome 117+ застосовує суворіші вимоги до журналів прозорості сертифікатів (CT). Сертифікати, не занесені до визнаного журналу CT, будуть відхилені незалежно від дат їх дійсності. Підтримання браузера в актуальному стані забезпечує сумісність із сучасними практиками PKI.

Виправлення 4: Тимчасово вимкніть перевірку HTTPS в антивірусі

Багато корпоративних і споживчих антивірусних продуктів — включаючи Kaspersky, ESET, Avast і Bitdefender — виконують перехоплення SSL/TLS (також зване скануванням HTTPS або перевіркою типу «людина посередині»). Вони роблять це, встановлюючи локальний кореневий сертифікат CA та повторно підписуючи весь HTTPS-трафік. Якщо внутрішній сертифікат антивірусу прострочений або він не може правильно повторно підписати сертифікат з точними датами дійсності, браузер отримує недійсний сертифікат і видає `NET::ERR_CERT_DATE_INVALID`.

Кроки:

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

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

Виправлення 5: Перевірте та вимкніть розширення браузера

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

Процес систематичної ізоляції:

• Відкрийте `chrome://extensions/`
• Одночасно вимкніть усі розширення
• Перевірте проблемну URL-адресу
• Якщо помилка зникла, вмикайте розширення по одному, щоб визначити винуватця
• Перевірте налаштування проблемного розширення на наявність параметрів проксі або перехоплення HTTPS

Розширення, що реалізують власний DNS-over-HTTPS (DoH) або маршрутизацію через проксі, є найпоширенішими порушниками. Перехід на чистий профіль браузера (`chrome://settings/manageProfile`) є швидшим методом ізоляції, ніж почергове вимкнення розширень.

Виправлення 6: Очистіть кеш DNS

Хоча пошкодження кешу DNS безпосередньо не спричиняє збоїв перевірки сертифікатів, воно може перенаправити трафік на неправильну IP-адресу — яка може обслуговувати інший (і недійсний) сертифікат для домену. Це особливо актуально в середовищах CDN, де IP-адреси часто змінюються.

Windows:

“`

ipconfig /flushdns

“`

macOS:

“`bash

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for older systems:

sudo service nscd restart

“`

Після очищення перевірте, чи ви отримуєте правильну IP-адресу за допомогою `nslookup yourdomain.com` або `dig yourdomain.com`, і підтвердіть, що IP відповідає записам вашого хостинг-провайдера.

Виправлення 7: Перевірте та налаштуйте параметри протоколу TLS

Сучасні браузери відмовилися від TLS 1.0 і TLS 1.1. Якщо сервер налаштований на підтримку лише застарілих протоколів, браузер може повністю відмовити у з’єднанні. І навпаки, деякі корпоративні мережеві пристрої видаляють заголовки TLS 1.3, примушуючи до пониження версії, що може спричинити помилки перевірки.

Перевірка прапорців TLS у Chrome:

• Перейдіть до `chrome://flags/`
• Знайдіть «TLS» і переконайтеся, що жодні експериментальні прапорці не примушують до пониження версії

Перевірка конфігурації TLS на стороні сервера (для власників сайтів):

Використовуйте SSL Labs Server Test за адресою `ssllabs.com/ssltest/` для аудиту підтримки протоколів вашого сервера. Правильно налаштований сервер повинен підтримувати TLS 1.2 і TLS 1.3, з явно вимкненими TLS 1.0/1.1.

Приклад Nginx — застосування сучасного TLS:

“`nginx

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

ssl_prefer_server_ciphers off;

“`

Еквівалент для Apache:

“`apache

SSLProtocol -all +TLSv1.2 +TLSv1.3

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

“`

Виправлення 8: Перевірте та поновіть SSL-сертифікат (для власників серверів)

Якщо ви керуєте сервером, це найпряміше виправлення на стороні сервера. Прострочений сертифікат є найочевиднішою причиною `NET::ERR_CERT_DATE_INVALID` на стороні сервера.

Перевірка сертифіката через браузер:

• Натисніть на значок замка (або значок попередження) в адресному рядку
• Виберіть З’єднання не захищене > Сертифікат недійсний
• Перевірте поля Дійсний з та Дійсний до

Перевірка через командний рядок (надійніший спосіб):

“`bash

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

“`

Це виводить мітки часу `notBefore` та `notAfter` безпосередньо з діючого сертифіката, що обслуговується.

Поновлення сертифіката Let’s Encrypt за допомогою Certbot:

“`bash

certbot renew –force-renewal

systemctl reload nginx # or apache2

“`

Автоматизація поновлення (правильне довгострокове рішення):

“`bash

Add to crontab or systemd timer

0 3 * * * certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Сертифікати Let’s Encrypt закінчуються кожні 90 днів. Автоматичне поновлення слід налаштовувати під час розгортання, а не після першого закінчення терміну дії. Якщо ви використовуєте VPS з cPanel, AutoSSL обробляє це автоматично — але переконайтеся, що він увімкнений і що завдання поновлення не завершується з помилкою непомітно.

Поширені підводні камені на стороні сервера:

• Неповний ланцюжок сертифікатів: Сервер обслуговує кінцевий сертифікат, але не проміжний сертифікат CA. Браузери, які не мають кешованого проміжного сертифіката, не зможуть виконати перевірку. Завжди об’єднуйте повний ланцюжок: `cat yourdomain.crt intermediate.crt > fullchain.crt`
• Неправильний сертифікат, прив’язаний до віртуального хоста: У Nginx або Apache з кількома віртуальними хостами для домену може бути активна неправильна директива `ssl_certificate`. Перевірте за допомогою `nginx -T | grep ssl_certificate`
• Сертифікат виданий для неправильного домену: Wildcard-сертифікат `*.example.com` не охоплює `example.com` (кореневий домен) — обидва повинні бути явно вказані як SAN

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

Виправлення 9: Перевірте в режимі інкогніто / приватного перегляду

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

Chrome: `Ctrl + Shift + N` (Windows/Linux) або `Command + Shift + N` (macOS)

Firefox: `Ctrl + Shift + P`

Edge: `Ctrl + Shift + N`

Інтерпретація результату:

• Помилка зникає в режимі інкогніто: причина — кешована відповідь, збережена політика HSTS або розширення браузера. Перейдіть до виправлень 2 і 5.
• Помилка зберігається в режимі інкогніто: причина на стороні сервера або мережі. Перейдіть до виправлень 8, 10 і 12.

Виправлення 10: Перевірте в різних мережах

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

Методологія тестування:

1. Перевірте в поточній мережі (наприклад, офісний Wi-Fi)
2. Перевірте через мобільні дані (повністю обходить локальну мережу)
3. Перевірте через VPN (змінює як мережевий шлях, так і DNS-резолвер)
4. Перевірте, використовуючи інший DNS-резолвер: встановіть DNS на `1.1.1.1` (Cloudflare) або `8.8.8.8` (Google) і повторіть тест

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

Для власників сайтів: Якщо користувачі корпоративних мереж повідомляють про цю помилку, тоді як інші — ні, ваш сертифікат може використовувати CA, якого немає в корпоративному сховищі довірених сертифікатів, або корпоративний проксі не може правильно повторно підписати ваш сертифікат. Перехід на широко довірений CA (DigiCert, Sectigo, Let’s Encrypt) вирішує більшість проблем із корпоративними сховищами довірених сертифікатів.

Виправлення 11: Очистіть стан SSL у Windows

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

Кроки:

• Відкрийте Панель керування (знайдіть її в меню «Пуск»)
• Перейдіть до Мережа та Інтернет > Властивості браузера
• Натисніть вкладку Вміст
• Натисніть Очистити стан SSL
• Натисніть OK
• Перезапустіть усі екземпляри браузера

Це впливає на всі браузери, що використовують стек SSL/TLS Windows (Internet Explorer, Edge Legacy і деякі браузери на основі Chromium у певних конфігураціях). Chrome і Firefox підтримують власні сховища сертифікатів незалежно, тому це виправлення найбільш актуальне для корпоративних середовищ на основі Edge та IE.

Виправлення 12: Зверніться до адміністратора веб-сайту

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

Що включити до звіту:

• Точний код помилки (`NET::ERR_CERT_DATE_INVALID`)
• Деталі сертифіката з інспектора браузера (видавець, дати дійсності, SAN)
• Вивід `openssl s_client -connect domain.com:443`, якщо ви можете його виконати
• Чи з’являється помилка в кількох браузерах і на різних пристроях
• Чи є помилка постійною або переривчастою (переривчасті помилки часто вказують на балансувальник навантаження, що обслуговує кілька сертифікатів, лише деякі з яких прострочені)

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

Якщо ви керуєте середовищем Виділеного сервера або VPS, налаштуйте сповіщення моніторингу про закінчення терміну дії сертифіката за допомогою таких інструментів, як `check_ssl_cert`, плагінів Nagios або сервісу на кшталт SSL-моніторингу UptimeRobot — який надсилає сповіщення за 30, 14 і 7 днів до закінчення терміну дії.

Управління сертифікатами на стороні сервера: найкращі практики для власників сайтів

Для адміністраторів, які керують власною інфраструктурою, реактивне поновлення сертифікатів є ризиком. Наступні практики усувають `NET::ERR_CERT_DATE_INVALID` як повторювану проблему.

Проактивне управління життєвим циклом сертифікатів:

• Автоматизуйте поновлення: Використовуйте Certbot з таймером systemd або завданням cron. Для комерційних сертифікатів використовуйте ACME-клієнти, сумісні з API вашого CA
• Відстежуйте дати закінчення терміну дії: Інтегруйте перевірки закінчення терміну дії сертифікатів у ваш стек моніторингу. Prometheus з `blackbox_exporter` може збирати метрики закінчення терміну дії TLS
• Використовуйте сертифікати з довшим терміном дії для критичної інфраструктури: Хоча 90-денний цикл Let’s Encrypt підходить для більшості випадків використання, OV і EV сертифікати з 1-річним терміном дії зменшують частоту поновлення для доменів з високими ставками
• Перевіряйте повний ланцюжок: Після кожного поновлення запускайте `openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted intermediate.crt yourdomain.crt` для підтвердження цілісності ланцюжка
• Тестуйте із зовнішньої перспективи: Використовуйте `curl -v https://yourdomain.com` з пристрою, який не є вашим сервером, щоб змоделювати те, що бачать браузери

Для середовищ, що використовують Панелі керування VPS: Більшість сучасних панелей керування (cPanel, Plesk, DirectAdmin) включають вбудоване управління SSL з AutoSSL або еквівалентом. Переконайтеся, що завдання AutoSSL заплановане, і щомісяця переглядайте його журнали.

Міркування щодо мультидоменних та wildcard-сертифікатів:

• Wildcard-сертифікати (`*.example.com`) не охоплюють кореневий домен (`example.com`), якщо він явно не доданий як SAN
• Мультидоменні (SAN) сертифікати необхідно перевидавати — а не просто поновлювати — при додаванні нових піддоменів
• Прив’язка сертифікатів (HPKP) є застарілою і не повинна використовуватися; вона може спричинити постійне блокування, якщо прив’язаний сертифікат закінчиться

Порівняння: виправлення на стороні клієнта та сервера — короткий огляд

Матриця рішень і технічний контрольний список

Використовуйте цей контрольний список для систематичного вирішення `NET::ERR_CERT_DATE_INVALID`, а не для випадкового застосування виправлень.

Крок 1 — Визначте масштаб:

• [ ] Чи з’являється помилка в режимі інкогніто?
• [ ] Чи з’являється помилка на другому пристрої (телефон, інший комп’ютер)?
• [ ] Чи з’являється помилка при використанні мобільних даних?

Крок 2 — Якщо проблема лише на стороні клієнта (помилка зникає на інших пристроях):

• [ ] Перевірте та синхронізуйте системний годинник (NTP)
• [ ] Очистіть кеш браузера, файли cookie та записи HSTS
• [ ] Очистіть стан SSL у Windows (лише для Windows)
• [ ] Вимкніть усі розширення та повторіть тест
• [ ] Вимкніть сканування HTTPS антивірусом та повторіть тест
• [ ] Очистіть кеш DNS

Крок 3 — Якщо проблема на стороні сервера (помилка зберігається на всіх пристроях/мережах):

• [ ] Запустіть `openssl s_client -connect domain.com:443` і перевірте `notAfter`
• [ ] Переконайтеся, що сервер обслуговує повний ланцюжок сертифікатів (а не лише кінцевий сертифікат)
• [ ] Підтвердіть, що правильний сертифікат прив’язаний до правильного віртуального хоста
• [ ] Поновіть сертифікат і перезавантажте веб-сервер
• [ ] Перевірте, що SAN включають усі необхідні імена хостів (кореневий домен + www + піддомени)
• [ ] Запустіть тест SSL Labs для підтвердження рейтингу A або A+ після поновлення

Крок 4 — Запобігання повторенню:

• [ ] Налаштуйте автоматичне поновлення сертифікатів з хуком перезавантаження сервера
• [ ] Налаштуйте зовнішній моніторинг закінчення терміну дії сертифікатів зі сповіщеннями за 30/14/7 днів
• [ ] Задокументуйте процедури поновлення сертифікатів у вашому регламенті

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

Часті запитання

Питання: Чи може NET::ERR_CERT_DATE_INVALID з’являтися, навіть якщо сертифікат не прострочений?

Так. Ця помилка виникає щоразу, коли бібліотека TLS браузера не може перевірити часове вікно сертифіката — що відбувається, якщо системний годинник встановлений на дату поза діапазоном `notBefore`–`notAfter` сертифіката, навіть якщо сам сертифікат технічно дійсний. Годинник, встановлений на два роки вперед, змусить поточний дійсний сертифікат виглядати простроченим.

Питання: Чому помилка з’являється в одному браузері, але не в іншому на тому самому пристрої?

Chrome, Firefox і Edge підтримують частково незалежні сховища сертифікатів і стеки TLS. Firefox використовує власну бібліотеку NSS і сховище кореневих сертифікатів, тоді як Chrome використовує сховище сертифікатів ОС у Windows і macOS. Розширення, встановлене в одному браузері, або кешована політика HSTS у сховищі одного браузера може спричинити появу помилки лише в одному браузері, тоді як інші працюватимуть нормально.

Питання: Чи безпечно натискати «Продовжити все одно», коли з’являється ця помилка?

Ні. На відміну від деяких інших помилок сертифікатів, `NET::ERR_CERT_DATE_INVALID` вказує на справжній збій у криптографічному ланцюжку довіри. Продовження означає, що ваше з’єднання не перевірено — ви не можете підтвердити, що спілкуєтеся з легітимним сервером, і з’єднання може бути перехоплено. Продовжуйте лише якщо ви є власником сайту і тестуєте власний сервер під час технічного обслуговування.

Питання: Як запобігти закінченню терміну дії SSL-сертифіката на сервері, яким я керую?

Налаштуйте автоматичне поновлення за допомогою Certbot або еквівалентного ACME-клієнта та додайте хук після поновлення, який перезавантажує ваш веб-сервер. Крім того, налаштуйте зовнішній моніторинг (UptimeRobot, Datadog або власний скрипт `check_ssl_cert`) для сповіщення за 30 днів до закінчення терміну дії. Покладатися на ручне поновлення є операційно ненадійним — автоматизація є єдиним надійним рішенням.

Питання: Чи впливає ця помилка на позиції в пошуку?

Прямо і опосередковано. Googlebot не індексуватиме HTTPS-ресурси, що обслуговуються з недійсним сертифікатом, що повністю видаляє ці сторінки з індексу. Крім того, якщо на вашому сайті налаштований HSTS, браузери відмовляться завантажувати його через HTTP як запасний варіант, роблячи сайт повністю недоступним для користувачів і сканерів до виправлення сертифіката. Справність сертифіката є передумовою для підтримання видимості в пошуку, а не необов’язковою проблемою.