Коротко. HTTPS ломается по двум разным классам причин, и лечатся они по-разному. Если сайт не открывается только у вас — почти всегда виноваты часы устройства, антивирус с перехватом TLS, корпоративный прокси или кэш браузера. Если не открывается у всех — проблема на сервере: истёкший сертификат, неполная цепочка, чужое имя, закрытый порт 443 или петля редиректов. Начните с этой развилки.
Эта статья — маршрутизатор. Она не разбирает каждую ошибку до последнего флага конфига: под частые случаи у нас есть отдельные разборы, и в нужный момент вы получите ссылку. Задача здесь другая — за несколько минут понять, где сломано, и не потратить вечер на настройку сервера, когда на ноутбуке просто сбились часы.
С чего начать: сломано у всех или только у вас
Это единственный вопрос, на который нужно ответить до того, как вы откроете конфиг веб-сервера. Он делит все дальнейшие действия на две непересекающиеся ветки. Ошибка в этом месте стоит дороже всего: люди перевыпускают нормальный сертификат, потому что у них на рабочей машине стоял корпоративный шлюз с перехватом трафика.
Четыре способа получить ответ, от самого быстрого к самому надёжному:
- Мобильный интернет. Выключите Wi-Fi на телефоне и откройте сайт с сотовых данных. Это другой канал, другой DNS-резолвер, другое устройство и другое хранилище корневых сертификатов. Если там открывается — проблема в вашей сети или на вашем компьютере.
- Приватное окно другого браузера. Снимает влияние кэша, части расширений и сохранённых записей HSTS. Не снимает влияние антивируса и системных часов.
- Другое устройство в другой сети. Самая честная локальная проверка: меняются сразу все переменные, кроме самого сайта.
- Внешняя проверка. Откройте проверку SSL-сертификата и посмотрите на сайт глазами постороннего сервера. Инструмент видит ровно то, что отдаёт ваш сервер, без вашего антивируса, прокси и часов.
| Что наблюдаете | Скорее всего | Куда смотреть |
|---|---|---|
| Внешняя проверка показывает валидный сертификат, у вас — ошибка | Локальная причина | Часы, антивирус, прокси, кэш |
| Внешняя проверка тоже ругается | Причина на сервере | Сертификат, цепочка, имя, порт |
| Не открывается на всех устройствах в одной сети, но открывается с мобильного | Сеть или шлюз | Прокси, DPI, DNS, фильтрация |
| Не открывается только в одном браузере | Состояние браузера | Кэш, расширения, запись HSTS |
| Ошибка «плавает»: то открывается, то нет | Балансировка | Разные бэкенды с разным сертификатом |
Последняя строка таблицы — недооценённый случай. Если за одним доменом стоит несколько серверов, а сертификат обновили не на всех, сайт будет ломаться «через раз», и внешняя разовая проверка легко покажет зелёный результат. Прогоните проверку несколько раз подряд.
Что говорит браузер: расшифровка кодов ошибок
Браузер почти всегда называет причину — просто не человеческим языком. Код ошибки виден на странице предупреждения (в Chrome его нужно раскрыть по кнопке «Дополнительно», в Firefox он в блоке с подробностями). Ниже — коды, которые встречаются чаще всего, и куда идти дальше по каждому.
| Код | Что произошло на самом деле | У всех или у вас | Куда дальше |
|---|---|---|---|
| NET::ERR_CERT_DATE_INVALID | Текущее время не попадает в интервал действия сертификата. Либо сертификат истёк, либо врут часы клиента | Оба варианта | Истёкший сертификат |
| NET::ERR_CERT_AUTHORITY_INVALID | Цепочку не удалось достроить до доверенного корня: не отданы промежуточные, самоподписанный сертификат или подмена на пути | Оба варианта | Разбор ошибки, неполная цепочка |
| NET::ERR_CERT_COMMON_NAME_INVALID | Имя, которое вы набрали, не входит в список имён сертификата (SAN) | У всех | Раздел про имя ниже |
| NET::ERR_CERT_REVOKED | Удостоверяющий центр отозвал сертификат до окончания срока | У всех | Перевыпуск, разбор причины отзыва |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | У клиента и сервера нет ни одной общей версии TLS или общего набора шифров | У всех либо у старых клиентов | Несовпадение версии или шифра |
| ERR_SSL_PROTOCOL_ERROR | Рукопожатие оборвалось: сервер ответил не по TLS, оборвал соединение или вернул мусор | У всех | Разбор ошибки, сбой рукопожатия |
| ERR_CONNECTION_REFUSED / ERR_CONNECTION_TIMED_OUT | До 443-го порта дело не дошло: никто не слушает или пакеты режет фильтр | Зависит от места фильтра | Проверка открытых портов |
| ERR_TOO_MANY_REDIRECTS | Петля перенаправлений, чаще всего HTTP ↔ HTTPS | У всех | Слишком много редиректов |
| SEC_ERROR_EXPIRED_CERTIFICATE (Firefox) | То же, что ERR_CERT_DATE_INVALID | Оба варианта | Истёкший сертификат |
| SEC_ERROR_UNKNOWN_ISSUER (Firefox) | Издатель неизвестен: чаще всего не отданы промежуточные сертификаты | Оба варианта | Неполная цепочка |
| MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT (Firefox) | Сертификат подписан сам собой, доверенного издателя нет | У всех | Самоподписанный сертификат |
| MOZILLA_PKIX_ERROR_MITM_DETECTED (Firefox) | Firefox распознал перехват трафика антивирусом или шлюзом | Только у вас | Раздел про антивирус и прокси |
| SSL_ERROR_NO_CYPHER_OVERLAP (Firefox) | Firefox-аналог несовпадения шифров | У всех либо у старых клиентов | Несовпадение версии или шифра |
Safari кодов не показывает — там будет только «Это соединение не является частным». В этом случае откройте тот же адрес в Chrome или Firefox: код нужен, чтобы не гадать. Общий каталог сообщений по SSL собран в разделе ошибок SSL.
MOZILLA_PKIX_ERROR_MITM_DETECTED — самое полезное сообщение из всех. Firefox не просто говорит «не доверяю»: он прямо утверждает, что соединение кто-то расшифровывает по пути. Ни один конфиг веб-сервера этого не чинит — искать нужно на клиенте.
Не работает только у вас: время, антивирус, прокси
Сбитые часы устройства
Самая частая и самая неочевидная причина. Механика простая, но её редко проговаривают: сертификат содержит два поля — notBefore и notAfter. При проверке клиент берёт своё системное время и смотрит, попадает ли оно в этот интервал. Никакого обращения к эталонному времени нет — сравнение идёт с часами вашего устройства.
Отсюда два симметричных сбоя. Часы отстали на месяцы назад — свежий сертификат «ещё не начал действовать». Часы убежали вперёд — сертификат «уже истёк». Оба случая браузер покажет одинаково: ошибкой про дату. Сертификаты Let's Encrypt по умолчанию живут около трёх месяцев (документация Let's Encrypt), поэтому окно действия узкое, и сбой времени ловится почти мгновенно.
Классические источники сбоя: разряженная батарейка CMOS на старом системном блоке (после каждого выключения дата уезжает в далёкое прошлое), виртуальная машина после долгой паузы, устройство без синхронизации времени в изолированной сети, ручная правка даты ради обхода лицензии.
# Linux: что считает система и синхронизировано ли время
date -u
timedatectl status
# Windows (командная строка от администратора)
w32tm /query /status
# macOS: текущее время в UTC
date -uНа Linux в выводе timedatectl status нужны строки про системные часы и про синхронизацию — если синхронизация выключена, включите её и перепроверьте сайт. На macOS автоматическая установка времени включается в системных настройках, в разделе даты и времени. На Windows после включения синхронизации имеет смысл принудительно обновить время и заново открыть браузер.
Проверка срока действия локальными средствами наследует ту же ошибку. Команда openssl x509 -checkend сравнивает даты сертификата с часами той машины, на которой запущена. Если часы врут, она соврёт вместе с ними. Именно поэтому первую проверку стоит делать внешним сервисом, а не своей консолью.
Антивирус и корпоративный прокси с перехватом TLS
Многие антивирусы и почти все корпоративные шлюзы безопасности умеют «заглядывать» в HTTPS. Делают они это единственным возможным способом: терминируют соединение у себя, а вам отдают свой сертификат, выписанный их собственным локальным центром сертификации. Работает это ровно до тех пор, пока их корневой сертификат лежит в вашем хранилище доверия и пока браузер этим хранилищем пользуется.
Сломаться может в трёх местах. Корень не установился после переустановки системы. Браузер ведёт собственное хранилище и не смотрит в системное. Сайт применяет закрепление ключей, и подмена намеренно не проходит. Результат — ошибка про недоверенного издателя, хотя с сертификатом сайта всё в порядке.
Проверяется за один шаг: посмотрите, кто выдал сертификат. Если в поле издателя стоит публичный удостоверяющий центр — перехвата нет. Если там имя вашего антивируса, названия шлюза или что-то вроде «local root» — вы видите не сертификат сайта.
# Кто выдал сертификат, который реально доходит до этой машины
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer
# Пример нормального вывода для публичного сайта:
# subject=CN=example.com
# issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3Сравните этот вывод с тем, что показывает внешняя проверка сертификата. Разные издатели у одного домена — прямое доказательство перехвата на вашей стороне. Дальше решение административное: добавить корень шлюза в доверенные, вывести домен из-под перехвата или временно отключить проверку HTTPS в антивирусе, чтобы подтвердить диагноз.
Кэш браузера, запись HSTS и устаревшее хранилище корней
Браузер помнит про сайт больше, чем кажется. Он кэширует не только страницы, но и решение «этот домен ходит только по HTTPS» — запись HSTS. Если вы чинили сайт, а браузер продолжает вести себя по-старому, состояние надо сбросить. В Chrome есть служебная страница chrome://net-internals/#hsts, где домен можно удалить из списка политик безопасности. Полная очистка кэша и куки за всё время решает большинство остальных случаев.
Отдельная категория — устройства, которые давно не получают обновлений. Хранилище корневых сертификатов пополняется вместе с системой; когда обновления прекращаются, устройство рано или поздно перестаёт узнавать издателей, выпущенных после последнего апдейта. Симптом характерный: свежие устройства открывают сайт нормально, а старый телефон или давно не обновлявшийся компьютер выдаёт ошибку про недоверенного издателя на половине интернета сразу. Чинится это только обновлением системы.
Не работает у всех: проблема в сертификате
Сертификат истёк
Самая простая причина и самая обидная: автопродление сломалось, письмо об истечении ушло в спам, и в ближайшую ночь сайт перестал открываться у всех сразу. Проверяется одной командой; поле notAfter — это и есть дата смерти.
Неполная цепочка
Случай, который выглядит мистикой: «в моём Chrome открывается, а на телефоне и в curl — нет». Механика такая. Сервер обязан отдать не только сертификат сайта, но и промежуточные сертификаты, которые связывают его с корнем. Если их не отдать, клиенту придётся достраивать цепочку самостоятельно. Часть клиентов это умеет — они дозагружают недостающее звено по ссылке из сертификата, а потом ещё и кэшируют его. Другие клиенты не умеют вовсе.
Отсюда фирменный признак: сайт работает у тех, кто раньше уже заходил на другой сайт того же издателя, и не работает у всех остальных. Считать звенья цепочки проще всего по количеству блоков сертификата в ответе сервера.
# Сколько сертификатов сервер реально отдаёт
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
| grep -c "BEGIN CERTIFICATE"
# 1 — цепочка неполная, отданы только сертификат сайта
# 2+ — отданы промежуточные, это нормальная ситуацияЕдиница в ответе — почти всегда диагноз. Лечится сборкой полного файла цепочки на стороне веб-сервера; в nginx за это отвечает файл, указанный в директиве сертификата, куда промежуточные дописываются после сертификата сайта (документация nginx). Подробный разбор — в статье про неполную цепочку сертификатов.
Имя в сертификате не совпадает с доменом
Сертификат действует не «для сервера», а для конкретного списка имён. Список лежит в расширении SAN. Современные браузеры проверяют только его и игнорируют устаревшее поле CN, поэтому сертификат, выписанный на example.com, не подойдёт для www.example.com, если второго имени в списке нет. Правила сопоставления имени описаны в RFC 6125.
Здесь же прячется ловушка, на которой спотыкаются даже опытные админы: команда openssl s_client по умолчанию имя не проверяет вообще. Она подтвердит доверие к цепочке и вернёт нулевой код, а браузер на том же адресе покажет ошибку имени. Чтобы проверка совпала с браузерной, нужен явный флаг.
# Список имён, на которые действует сертификат
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -ext subjectAltName
# Проверка имени так, как её делает браузер
echo | openssl s_client -connect example.com:443 -servername example.com \
-verify_hostname example.com 2>&1 | grep "Verify return code"
# При несовпадении имени вывод будет таким:
# Verify return code: 62 (hostname mismatch)На адресе отдаётся сертификат чужого сайта
Когда на одном IP-адресе живёт несколько сайтов, сервер понимает, чей сертификат отдавать, из имени, которое клиент присылает в начале рукопожатия — это механизм SNI (RFC 6066). Если для вашего домена не описан отдельный виртуальный хост или в нём не указан сертификат, сервер отдаст сертификат сайта по умолчанию — то есть чужой. Браузер честно сообщит про несовпадение имени, хотя сертификат для вашего домена на сервере лежит и он валиден.
# Что отдаётся, если имя не сообщать (сайт по умолчанию)
echo | openssl s_client -connect 203.0.113.10:443 2>/dev/null \
| openssl x509 -noout -subject
# Что отдаётся, если сообщить имя явно
echo | openssl s_client -connect 203.0.113.10:443 -servername shop.example.com 2>/dev/null \
| openssl x509 -noout -subjectРазные значения в двух командах — нормально и означает, что SNI работает. Одинаковые, причём чужое имя в обеих — виртуальный хост для вашего домена не подхватился. Адрес 203.0.113.10 в примере взят из диапазона, зарезервированного для документации (RFC 5737) — подставьте свой.
Не работает у всех: сертификат в порядке, а сайт не открывается
Порт 443 закрыт или слушает не тот процесс
До проверки сертификата дело доходит не всегда. Если 443-й порт не отвечает, браузер покажет отказ в соединении или таймаут — про сертификаты речи вообще не будет. Типичные причины: веб-сервер слушает только 80-й, правило межсетевого экрана не открыто, у провайдера или хостинга закрыт порт, сервис упал после перезагрузки.
# Отвечает ли порт снаружи
nc -z -w 5 example.com 443 && echo "443 open" || echo "443 closed"
# Что слушает 443 на самом сервере (Linux)
ss -ltnp | grep ':443'
# Диагностика подключения целиком
curl -sS --connect-timeout 5 -o /dev/null -w '%{http_code}\n' https://example.comЕсли curl отвечает ошибкой седьмого класса (не удалось подключиться), значит проблема сетевая, а не сертификатная. Быстро проверить порт снаружи можно сканером портов, не заходя на сервер.
Петля редиректов HTTP ↔ HTTPS
Схема, которая ломает сайты после подключения балансировщика или CDN. Внешний узел принимает HTTPS и идёт к вашему серверу по обычному HTTP. Сервер видит незашифрованный запрос и честно перенаправляет его на HTTPS. Внешний узел снова принимает HTTPS и снова идёт по HTTP. Браузер отдаёт ERR_TOO_MANY_REDIRECTS, хотя сертификат идеален.
Ключ к решению — заголовок, которым внешний узел сообщает исходную схему запроса. Правило перенаправления должно смотреть на него, а не на локальную схему соединения. Тот же класс ошибок даёт правило «всегда на www» вместе с правилом «всегда без www» в другом месте конфига.
# Полная цепочка перенаправлений и итоговый адрес
curl -sSIL -o /dev/null \
-w 'redirects=%{num_redirects} final=%{url_effective} code=%{http_code}\n' \
http://example.com
# Пошагово, с кодами и заголовками Location
curl -sSIL http://example.com | grep -iE '^HTTP/|^location:'Число перенаправлений больше трёх-четырёх — уже повод разбираться. Наглядно цепочку показывает проверка редиректов, а разбор частных случаев — в статье про слишком большое количество перенаправлений.
Смешанный контент
Отдельный случай «HTTPS не работает» — когда он формально работает. Страница открывается по HTTPS, а картинки, скрипты и стили на ней прописаны с адресами по HTTP. Браузер блокирует активные ресурсы, замок пропадает или превращается в предупреждение, вёрстка разъезжается, кнопки перестают отвечать. Пользователь описывает это ровно словами «после перехода на HTTPS сайт не работает».
Найти такие ресурсы вручную тяжело: часть адресов приходит из базы, часть — из тем и плагинов, часть — из сторонних виджетов. Проще прогнать страницу через проверку смешанного контента. Пошаговое исправление разобрано в статье про смешанный контент.
HSTS после отката на HTTP
Механизм HSTS (RFC 6797) устроен так: сервер один раз присылает заголовок с длительностью, и браузер на весь этот срок запоминает, что к домену можно обращаться только по HTTPS. Причём запоминает жёстко — он не просто перенаправляет, он отказывается открывать HTTP и не показывает кнопку «всё равно перейти».
Отсюда сценарий, который выглядит как катастрофа. Сайт перевели на HTTPS, заголовок выставили с большим сроком, потом что-то пошло не так и HTTPS откатили. Для нового посетителя сайт работает. Для всех, кто заходил раньше, домен недоступен полностью — до истечения запомненного срока или до ручной очистки записи в каждом браузере.
# Присылает ли сервер заголовок HSTS и на какой срок
curl -sSI https://example.com | grep -i 'strict-transport-security'
# Пример реального ответа:
# strict-transport-security: max-age=31536000Единственный настоящий выход из этой ситуации — вернуть работающий HTTPS. Убрать заголовок со стороны сервера недостаточно: браузеры, которые его уже получили, продолжат действовать по старой записи весь оставшийся срок. Если домен успел попасть в предзагруженный список, удаление занимает месяцы. Подробности — в разборе HSTS и preload-списка.
Как проверить: команды, которые дают ответ за минуту
Ниже — прогон, который закрывает почти все описанные выше случаи. Выполняйте по порядку и останавливайтесь на первом шаге, который дал неожиданный результат. Подставьте свой домен вместо example.com.
# 1. Отвечает ли порт 443
nc -z -w 5 example.com 443 && echo "443 open" || echo "443 closed"
# 2. Кому выдан сертификат, кем, до какого числа и на какие имена
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
# 3. Доверяет ли цепочке система и совпадает ли имя
echo | openssl s_client -connect example.com:443 -servername example.com \
-verify_hostname example.com 2>&1 | grep "Verify return code"
# 4. Полная ли цепочка (1 = неполная)
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
| grep -c "BEGIN CERTIFICATE"
# 5. Куда ведут перенаправления
curl -sSIL -o /dev/null \
-w 'redirects=%{num_redirects} final=%{url_effective} code=%{http_code}\n' \
http://example.comТретий шаг — самый информативный. Итоговый код проверки прямо называет причину:
| Verify return code | Что означает | Что чинить |
|---|---|---|
| 0 (ok) | Цепочка доверенная, имя совпало | Проблема не в сертификате |
| 10 (certificate has expired) | Срок действия закончился — или врут часы машины, где запущена команда | Перевыпуск, автопродление, часы |
| 18 (self-signed certificate) | Сертификат подписан сам собой | Выпустить сертификат в публичном центре |
| 19 (self-signed certificate in certificate chain) | Корень цепочки не доверенный: свой центр сертификации или перехват | Проверить издателя, искать перехват |
| 21 (unable to verify the first certificate) | Не отданы промежуточные сертификаты | Собрать полную цепочку |
| 62 (hostname mismatch) | Домен не входит в список имён сертификата | Добавить имя, проверить виртуальный хост |
Не используйте флаг, отключающий проверку сертификата, чтобы «убедиться, что сайт жив». С ним запрос пройдёт всегда, и вы получите ложное подтверждение работоспособности. Такой флаг годится ровно для одного: доказать, что проблема именно в проверке сертификата, а не в самом сервисе.
Как проверить онлайн, без консоли
Внешняя проверка ценна не удобством, а точкой обзора: она смотрит на сайт с постороннего сервера, где нет ваших часов, антивируса, прокси и кэша. Именно поэтому её стоит делать первой — она сразу закрывает половину развилки.
- Проверка SSL-сертификата — издатель, срок действия, список имён, полнота цепочки. Первый инструмент при любой ошибке про сертификат.
- Проверка безопасности сайта — заголовки ответа, включая HSTS, и общая картина по защите.
- Проверка редиректов — вся цепочка перенаправлений с кодами, петли видно сразу.
- Проверка смешанного контента — ресурсы по HTTP на странице, отданной по HTTPS.
- Сканер портов — отвечает ли 443-й снаружи, не заходя на сервер.
- Просмотр HTTP-заголовков — что именно сервер отвечает на запрос.
- Мониторинг сайта — чтобы об истечении сертификата вы узнавали заранее, а не от клиента. Как это устроить, разобрано в статье про мониторинг SSL-сертификатов.
Частые вопросы
Почему HTTPS не работает только на одном компьютере?
Потому что проверка сертификата целиком происходит на клиенте. Три главных подозреваемых по порядку: системные часы, антивирус или шлюз с перехватом TLS, сохранённое состояние браузера. Проверьте дату, посмотрите издателя сертификата и сравните его с внешней проверкой. Если издатели разные — трафик расшифровывают на вашей стороне.
Почему сразу все сайты перестали открываться по HTTPS?
Одновременный отказ на всех доменах — это никогда не проблема сайтов. Так выглядят сбитые часы, отвалившийся корневой сертификат перехватывающего шлюза или устройство, которое давно не обновлялось и не знает новых издателей. Начните с даты и времени, затем проверьте, не появился ли в поле издателя посторонний центр сертификации.
Я искал, как сделать ссылку HTTPS, — это про то же самое?
Нет, это другая задача. Вопросы «как сделать ссылку, фото или видео по HTTPS» — про то, как вставить материал в статью или сообщение так, чтобы адрес начинался с https://. Поломка HTTPS на сайте с этим не связана. Если ваш вопрос о том, как устроен сам протокол, начните с разбора, что такое HTTPS. Если же вставленный по HTTP материал ломает вёрстку на HTTPS-странице — это смешанный контент, ему посвящён отдельный разбор.
Можно ли просто нажать «Перейти на сайт (небезопасно)»?
Для чужого сайта — нет. Кнопка снимает единственную защиту от того, что между вами и сервером кто-то сидит и читает трафик, включая пароли и куки. Для своего сайта на этапе отладки это допустимо как разовая проверка гипотезы. Учтите, что при действующей политике HSTS кнопки не будет вовсе — браузер откажется открывать домен.
Сайт открывается по HTTP, но не по HTTPS. Почему?
Значит, сервис жив, а именно HTTPS-часть не настроена или сломана. Проверьте три вещи по порядку: слушает ли сервер 443-й порт, подхватился ли виртуальный хост с сертификатом для этого домена, не отдаётся ли на этом адресе сертификат другого сайта. Команды для всех трёх проверок — в разделе выше.
Поможет ли переустановка браузера?
Обычно нет, и время потратите зря. Системные часы, хранилище корневых сертификатов и настройки антивируса переустановка не трогает — а это три причины из четырёх. Осмысленно только очистить кэш и удалить запись HSTS для конкретного домена; всё остальное лечится за пределами браузера.
Чеклист
- Ответьте на главный вопрос: не открывается у всех или только у вас. Мобильный интернет и внешняя проверка дают ответ за минуту.
- Раскройте подробности ошибки и запишите код — по нему видно причину.
- Если проблема локальная: проверьте дату и время, затем издателя сертификата, затем очистите кэш и запись HSTS.
- Если проблема серверная: проверьте срок действия, полноту цепочки и список имён в SAN.
- Убедитесь, что сервер отдаёт больше одного сертификата — единица означает неполную цепочку.
- Проверяйте имя явным флагом: без него
openssl s_clientвернёт «ok» там, где браузер покажет ошибку. - Проверьте, что 443-й порт открыт и слушает нужный процесс.
- Прогоните цепочку перенаправлений — петля HTTP ↔ HTTPS даёт ошибку, не связанную с сертификатом.
- Проверьте страницу на смешанный контент, если сайт открывается, но ведёт себя неправильно.
- Не откатывайте сайт на HTTP при действующем HSTS — вернуть посетителей будет нечем.
- Поставьте мониторинг срока действия сертификата, чтобы следующий раз не начинался со звонка клиента.