Если SSL не работает, сначала нужно определить симптом. Разные ошибки выглядят похоже для пользователя, но чинятся в разных местах: DNS, сертификат, веб-сервер, редиректы, CMS, CDN или цепочка сертификатов.
Таблица диагностики:
| Симптом | Вероятная причина | Чем проверить |
| certificate expired | Сертификат истёк или автообновление не сработало, сбились часы на клиентском устройстве | certbot certificates, openssl s_client, проверить время |
| Сайт открывается без HTTPS | Нет редиректа, SSL не подключён к virtual host, открыт только HTTP | curl -I, конфиг Nginx/Apache, фаервол |
| Бесконечный редирект | Редиректы включены сразу в панели, CMS, веб-сервере и CDN | curl -I -L, настройки CDN и CMS |
| Mixed content | Страница на HTTPS, но ресурсы грузятся по HTTP | DevTools в браузере, исходный код страницы |
| ERR_SSL_PROTOCOL_ERROR | На 443 порту не настроен SSL, сломан конфиг или сервер отдаёт не тот протокол | nginx -t, apachectl configtest, логи |
| Сертификат другого домена | Неправильный server block, DNS ведёт не туда, www не включён в сертификат | openssl s_client, certbot certificates, DNS |
| Нет доверия к сертификату | Сертификат самоподписаный, проблема с корневыми центрами, неполная цепочка доверия | openssl s_client, конфиг Nginx/Apache, trusted CA |
| Ошибка после Cloudflare/CDN | Неверный SSL-режим, конфликт редиректов, старый сертификат на origin-сервере | настройки CDN, curl -I, проверка origin |
Главное — не начинать с CMS. WordPress, Bitrix или другая CMS может хранить адрес сайта, делать редиректы и отдавать ссылки на ресурсы, но SSL работает ниже: на уровне DNS, веб-сервера, сертификата и HTTPS-соединения.
Базовый порядок проверки такой:
- Проверить время на компьютере, убедится что проблема именно серверная.
- Проверить, куда указывает домен:
dig +short example.com
dig +short www.example.com
- Посмотреть, какие сертификаты знает Certbot, если он используется: sudo certbot certificates
- Проверить конфигурацию веб-сервера: sudo nginx -t или sudo apachectl configtest
- Проверить HTTP- и HTTPS-ответы:
curl -I http://example.com
curl -I https://example.com
- Посмотреть, какой сертификат реально отдаёт сервер: openssl s_client -connect example.com:443 -servername example.com
- Проверить логи веб-сервера, если ошибка не видна по внешним симптомам.
Частые ошибки при исправлении SSL — чинить только настройки CMS, забывать про www и non-www, не проверять цепочку сертификатов и одновременно включать редиректы в панели, CMS, веб-сервере и CDN.
Правильный подход проще: сначала определить симптом, потом проверить DNS, сертификат, веб-сервер, редиректы и только после этого менять настройки сайта или CDN.
Как быстро диагностировать проблему с SSL
Когда SSL ломается, первая реакция часто неправильная: зайти в CMS, поменять адрес сайта, включить ещё один редирект или заново нажать кнопку выпуска сертификата в панели.
Так можно случайно усложнить проблему. Лучше идти по порядку: сначала определить симптом, затем проверить DNS, сертификат и веб-сервер, и только после этого трогать CMS, CDN или плагины.
Сначала определить симптом
Фраза “SSL не работает” слишком общая. Под ней могут скрываться разные проблемы: истёкший сертификат, неверный домен, редирект по кругу, mixed content, ошибка протокола или конфликт с CDN.
Поэтому сначала нужно зафиксировать, что именно видит пользователь:
- Браузер пишет certificate expired;
- Сайт открывается только по HTTP;
- При переходе на HTTPS появляется ошибка;
- Страница бесконечно перенаправляется;
- Браузер показывает mixed content;
- Сертификат выпущен для другого домена;
- Отсутствует доверие к сертификату;
- Ошибка появилась после включения Cloudflare или другого CDN.
Это важно, потому что разные симптомы ведут к разным проверкам. Например, certificate expired чаще связан с автообновлением, а redirect loop — с конфликтом редиректов в веб-сервере, CMS, панели или CDN.
Mixed content вообще не означает, что сертификат не установлен. В этом случае HTTPS может работать корректно, но часть ресурсов на странице всё ещё загружается по HTTP.
Поэтому первый шаг — не “переустановить SSL”, а точно назвать симптом. После этого диагностика становится намного проще.
Первым делом проверить клиентское устройство
Чаще всего с сервером и сертификатом всё в порядке, а проблема сугубо локальная. Короткий чек-лист
- Проверить время на устройстве;
- Проверить, корректно ли открывается сайт на другом устройстве, желательно с другим провайдером;
- Почистить cookies и кэш браузера, или использовать другой браузер, затем повторить проверку.
Если же проблема всё же остаётся, проявляется на разных устройствах с разных провайдеров - нужно приступать к диагностике серверной части.
Затем проверить DNS, сертификат и веб-сервер
После определения симптома нужно проверить базовую цепочку: домен, сертификат и веб-сервер.
Сначала смотрят DNS. Домен должен указывать на тот VPS или CDN, который действительно обслуживает сайт:
dig +short example.com
dig +short www.example.com
Если example.com и www.example.com указывают на разные IP, ошибка может проявляться только на одной версии сайта.
Затем проверяют сертификаты, которые знает Certbot: sudo certbot certificates
Эта команда помогает увидеть, для каких доменов выпущен сертификат, где лежат его файлы и когда он истекает.
После этого нужно проверить конфигурацию веб-сервера. Для Nginx: sudo nginx -t
Для Apache: sudo apachectl configtest
Если конфигурация сломана, HTTPS может не подняться даже при действующем сертификате.
Дальше проверяют ответы сайта:
curl -I http://example.com
curl -I https://example.com
Так можно увидеть статус-коды, редиректы и заголовок Location. Если есть бесконечный редирект, curl быстро покажет, куда сервер пытается перенаправить запрос.
Для проверки сертификата, который реально отдаёт сервер, используют: openssl s_client -connect example.com:443 -servername example.com
Это особенно полезно, если браузер показывает сертификат другого домена или ошибку цепочки сертификатов.
Если внешние проверки не дают ответа, переходят к логам веб-сервера. У Nginx обычно смотрят access/error logs, у Apache — соответствующие журналы virtual host или общие error logs.
Такой порядок помогает не гадать. Сначала DNS, затем сертификат, затем конфиг, ответы сервера и логи.
Почему не стоит чинить SSL только в CMS
CMS может участвовать в проблеме, но она редко является единственным уровнем, где работает SSL.
WordPress, Bitrix, Drupal или другая CMS могут хранить адрес сайта, формировать ссылки, включать редиректы, отдавать изображения, подключать стили и скрипты. Но сам HTTPS работает ниже: на уровне DNS, веб-сервера, сертификата и TLS-соединения.
Если сертификат истёк, изменение адреса сайта в CMS не поможет. Если домен указывает не на тот IP, плагин для HTTPS тоже ничего не исправит. Если на 443 порту не настроен SSL, CMS может быть полностью рабочей, но браузер всё равно покажет ошибку.
CMS имеет смысл проверять после базовой диагностики. Например, когда сертификат действующий, HTTPS открывается, редирект работает, но внутри страниц остались HTTP-ссылки. Тогда проблема может быть в настройках сайта, базе данных, шаблоне, плагинах или кэше.
Также CMS часто становится источником redirect loop. Например, редирект включён в панели, в Nginx, в плагине WordPress и ещё в CDN. Каждый слой пытается “помочь”, но вместе они создают бесконечное перенаправление.
Поэтому правильная логика такая: сначала проверить инфраструктуру, потом CMS. SSL нужно чинить не с верхнего слоя, а с основы: DNS, сертификат, веб-сервер, редиректы, CDN и только затем настройки сайта.
Диагностическое дерево по симптомам
SSL-проблемы удобнее разбирать не с вопроса “что переустановить”, а с вопроса “что именно видит пользователь”. Один симптом обычно сужает круг причин до нескольких проверок.
Ниже — основные сценарии: от истёкшего сертификата до ошибок после подключения CDN.
Браузер пишет certificate expired
Сообщение certificate expired означает, что браузер видит сертификат с истёкшим сроком действия. Если сертификат платный и устанавливался вручную, необходимо его заменить. При использовании бесплатных сертификатов LE чаще всего это происходит, когда автообновление Certbot не сработало или веб-сервер продолжает отдавать старый сертификат.
Сначала проверьте сертификаты на сервере: sudo certbot certificates
Команда покажет домены, пути к сертификатам и дату окончания. Если сертификат действительно истёк, нужно проверить, почему он не обновился.
Затем выполните тест автообновления: sudo certbot renew --dry-run
Если dry-run завершается ошибкой, причина может быть в DNS, закрытом 80 порте, сломанном virtual host, конфликте редиректов или проблеме с DNS challenge для wildcard-сертификата.
Также стоит проверить, какой сертификат реально отдаёт сервер:
openssl s_client -connect example.com:443 -servername example.com
Иногда Certbot уже обновил сертификат, но Nginx или Apache не был перезагружен и продолжает отдавать старый файл. Тогда нужно проверить конфиг и reload веб-сервера.
Для Nginx:
sudo nginx -t
sudo systemctl reload nginx
Для Apache:
sudo apachectl configtest
sudo systemctl reload apache2
Если после reload браузер всё ещё показывает старый сертификат, проверьте CDN, reverse proxy и кэш. Пользователь может видеть не сертификат origin-сервера, а сертификат промежуточного слоя.
Сайт открывается без HTTPS
Если сайт открывается по HTTP, но не переходит на HTTPS, это не всегда значит, что SSL “не установлен”. Иногда сертификат есть, но редирект не настроен или подключён не к тому virtual host.
Сначала проверьте HTTP-ответ: curl -I http://example.com
Если сервер возвращает 200, значит сайт отдаётся по HTTP без редиректа. Для постоянного перенаправления обычно ожидают 301 или 302 с заголовком Location: https://....
Затем проверьте HTTPS: curl -I https://example.com
Если HTTPS работает, но HTTP не перенаправляет, проблема в редиректе. Его нужно настроить в Nginx, Apache, панели управления или CDN — но лучше выбрать один основной слой, а не включать редирект везде сразу.
Если HTTPS не работает вообще, нужно проверить, подключён ли сертификат к нужному server block или virtual host.
Для Nginx проверьте конфигурацию: sudo nginx -t
И найдите блок для домена: grep -R "server_name example.com" /etc/nginx/sites-enabled /etc/nginx/conf.d
Для Apache проверьте virtual host: sudo apachectl -S
Если домен обслуживается не тем конфигом, сервер может открывать сайт по HTTP, но не иметь корректной HTTPS-настройки для этого имени.
Бесконечный редирект HTTP ↔ HTTPS
Redirect loop появляется, когда запрос ходит по кругу: сервер, CMS, панель или CDN постоянно перенаправляют пользователя, но не приходят к финальному адресу.
Частая причина — редиректы включены сразу в нескольких местах. Например, HTTPS включён в панели, плагине CMS, конфиге Nginx и Cloudflare. Каждый слой пытается исправить схему URL, но вместе они создают цикл.
Проверить цепочку редиректов можно так: curl -I -L http://example.com
Флаг -L покажет переходы по редиректам. Если адреса повторяются или сайт прыгает между http и https, проблема в конфликте правил.
Отдельно проверьте, куда ведут разные версии домена:
curl -I http://example.com
curl -I http://www.example.com
curl -I https://example.com
curl -I https://www.example.com
Редирект должен быть единым и предсказуемым. Например:
http://example.com → https://example.com
http://www.example.com → https://example.com
https://www.example.com → https://example.com
Или наоборот, если основной домен выбран с www.
Если используется CDN, проверьте SSL-режим и настройки принудительного HTTPS. При неправильной связке CDN может обращаться к origin-серверу по HTTP, а origin-сервер будет требовать HTTPS обратно. Так появляется цикл.
Лучше оставить главный редирект в одном месте: на веб-сервере или в CDN. CMS должна хранить правильный адрес сайта, но не всегда должна быть основным механизмом HTTPS-редиректа.
Браузер показывает mixed content
Mixed content — это ситуация, когда основная страница открывается по HTTPS, но часть ресурсов загружается по HTTP.
Например: https://example.com
А внутри страницы есть ресурс: http://example.com/uploads/banner.jpg
В этом случае сертификат может быть полностью рабочим. Проблема не в выпуске SSL, а в ссылках внутри сайта.
Проверять mixed content удобнее через DevTools в браузере. Откройте вкладку Console или Network и найдите ресурсы, которые загружаются по http://.
Чаще всего это:
- Изображения;
- CSS-файлы;
- JavaScript;
- Шрифты;
- iframe;
- Видео;
- API-запросы;
- Внешние виджеты.
В CMS нужно проверить адрес сайта, шаблон, плагины, кэш и старые ссылки в базе данных. В WordPress, например, mixed content часто остаётся после переезда с HTTP на HTTPS, если старые абсолютные ссылки не были заменены.
Также проверьте внешние ресурсы. Если сторонний скрипт или виджет не поддерживает HTTPS, браузер может заблокировать его или показать предупреждение.
Mixed content исправляется не перевыпуском сертификата, а переводом всех внутренних и внешних ресурсов на HTTPS.
Появляется ERR_SSL_PROTOCOL_ERROR
ERR_SSL_PROTOCOL_ERROR обычно означает, что браузер попытался подключиться по HTTPS, но сервер не смог корректно установить TLS-соединение.
Причины могут быть разные: на 443 порту не настроен SSL, веб-сервер отдаёт обычный HTTP на HTTPS-порту, конфиг сломан, сертификат подключён неправильно или CDN конфликтует с origin-сервером.
Сначала проверьте, отвечает ли HTTPS: curl -I https://example.com
Затем проверьте конфигурацию веб-сервера.
Для Nginx: sudo nginx -t
Для Apache: sudo apachectl configtest
Если конфиг корректный, проверьте, что слушает порт 443: sudo ss -tulpn | grep :443
Также полезно посмотреть сертификат через OpenSSL: openssl s_client -connect example.com:443 -servername example.com
Если OpenSSL не может установить соединение, проблема находится ниже уровня CMS: в веб-сервере, TLS-конфигурации, firewall, CDN или сетевых правилах.
После этого стоит смотреть логи.
Для Nginx: sudo tail -n 50 /var/log/nginx/error.log
Для Apache: sudo tail -n 50 /var/log/apache2/error.log
ERR_SSL_PROTOCOL_ERROR не стоит лечить заменой URL в CMS. Сначала нужно убедиться, что 443 порт действительно отдаёт HTTPS.
Сертификат выпущен для другого домена
Если браузер показывает, что сертификат выдан для другого домена, значит сервер отдаёт не тот сертификат или пользователь попадает не на тот virtual host.
Частая причина — забыли добавить www, поддомен или альтернативное имя при выпуске сертификата.
Проверьте, какие домены есть в сертификате, при использовании certbot: sudo certbot certificates
Затем проверьте, какой сертификат реально отдаёт сервер: openssl s_client -connect example.com:443 -servername example.com
Если проблема только на www, проверьте отдельно: openssl s_client -connect www.example.com:443 -servername www.example.com
Также нужно проверить DNS:
dig +short example.com
dig +short www.example.com
Если example.com и www.example.com указывают на разные IP, браузер может получать сертификаты с разных серверов.
На стороне веб-сервера проверьте, что для нужного домена есть отдельный server block или virtual host, а в нём подключён правильный сертификат.
Для Nginx полезно найти все упоминания домена: grep -R "example.com" /etc/nginx/sites-enabled /etc/nginx/conf.d
Для Apache: sudo apachectl -S
Если сервер отдаёт дефолтный сертификат, значит запрос не попадает в нужный virtual host или в конфиге не указан правильный server_name/ServerName.
Нет доверия к сертификату
Если браузер не открывает сайт с ошибкой доверия, а curl не работает без ключа -k - скорее всего проблема с построением цепочки доверия.
Необходимо посмотреть сертификат, который реально отдаёт сайт - openssl s_client -connect www.example.com:443 -servername www.example.com
Можно даже сохранить его отдельным файлом и открыть в системных приложениях. Чаще всего ошибка доверия возникает при неполной установке сертификата на сервер (когда устанавливается только 1 сертификат, а не fullchain), и если в системе нет доверия центрам сертификации, выпустившим сертификат, если сертификат самоподписанный (не платный, не выпущенный через certbot, а сгенерированный вручную).
Более редкая ошибка - если центр сертификации отозвал сертификат по каким-либо причинам.
В любом случае необходимо проверить настройки вебсервера, при необходимости - перевыпустить сертификат.
Ошибка появилась после Cloudflare или CDN
Если SSL сломался после подключения Cloudflare или другого CDN, проблема может быть не на VPS, а между CDN и origin-сервером.
CDN добавляет ещё один слой: пользователь подключается к CDN, а CDN отдельно подключается к вашему VPS. Поэтому важно, какой SSL-режим выбран и есть ли действующий сертификат на origin-сервере.
Типовые причины:
- Выбран неправильный SSL-режим;
- CDN обращается к origin по HTTP, а сервер требует HTTPS;
- origin-сертификат истёк;
- Сертификат на VPS выпущен не для того домена;
- Включены редиректы и в CDN, и на сервере;
- DNS-записи проксируются, но сервер настроен как для прямого доступа.
Проверку лучше начать с CDN-настроек: SSL mode, Always Use HTTPS, Automatic HTTPS Rewrites, Page Rules или Redirect Rules.
Затем проверьте origin-сервер напрямую, если есть возможность обратиться к нему без CDN. Иногда для этого используют временную запись, hosts-файл или прямой запрос на IP с нужным SNI.
Также проверьте стандартные ответы:
curl -I http://example.com
curl -I https://example.com
И сертификат: openssl s_client -connect example.com:443 -servername example.com
Если при отключении CDN ошибка исчезает, значит проблема почти наверняка в связке CDN ↔ origin: SSL-режим, редиректы, сертификат на сервере или проксирование DNS.
При использовании CDN особенно важно не включать редиректы одновременно везде. Лучше выбрать один основной слой для принудительного HTTPS и убедиться, что origin-сервер тоже имеет корректный сертификат.
После такого диагностического дерева можно переходить к инструментам. Они помогают не только понять симптом, но и подтвердить причину: DNS покажет, куда ведёт домен, Certbot — какие сертификаты есть на сервере, curl — как работают редиректы, а openssl s_client — какой сертификат реально отдаётся пользователю.
Какие команды помогают найти причину
Когда симптом понятен, дальше нужно подтвердить причину. Для этого не обязательно сразу менять конфиги или перевыпускать сертификат. Часто достаточно нескольких проверок: DNS, Certbot, веб-сервер, HTTP-ответы, реальный сертификат и логи.
Эти команды помогают понять, где именно ломается цепочка: домен → сервер → сертификат → веб-сервер → редирект → браузер.
Куда сейчас указывает домен
DNS показывает, куда сейчас указывает домен. Это первая проверка, если сайт открывается не с того сервера, сертификат не выпускается или ошибка появляется только на www либо только на основной версии домена.
Проверить A-запись можно так: dig +short example.com
Для www: dig +short www.example.com
Если используется IPv6, дополнительно стоит проверить AAAA-запись: dig +short AAAA example.com
Важно сравнить результат с IP вашего VPS или CDN. Если домен указывает на другой IP, SSL нужно чинить не в Certbot и не в CMS, а в DNS-зоне.
Также нужно проверять обе версии домена. Частая ситуация: example.com указывает на новый VPS, а www.example.com остался на старом сервере. В итоге одна версия сайта работает, а другая отдаёт чужой или истёкший сертификат.
Какие сертификаты видит Certbot
Если сертификат выпускался через Certbot, список сертификатов можно посмотреть командой:
sudo certbot certificates
Она показывает:
- Имя сертификата;
- Домены, для которых он выпущен;
- Дату окончания;
- Путь к fullchain.pem;
- Путь к privkey.pem.
Эта команда полезна при ошибках certificate expired, неправильном домене в сертификате и проблемах с автообновлением.
Если в списке нет нужного домена, значит сертификат для него не выпускался через этот Certbot или был удалён. Если домен есть, но дата окончания прошла, нужно проверять автообновление: sudo certbot renew --dry-run
Если dry-run падает, причина может быть в DNS, закрытом порте 80, сломанном virtual host, redirect loop или DNS challenge для wildcard-сертификата.
Правильно ли настроен Nginx или Apache
Даже действующий сертификат не поможет, если веб-сервер настроен неправильно. Поэтому после DNS и Certbot нужно проверить конфигурацию Nginx или Apache.
Для Nginx: sudo nginx -t
Если тест успешный, конфигурацию можно перезагрузить: sudo systemctl reload nginx
Для Apache: sudo apachectl configtest
И затем: sudo systemctl reload apache2
Эти проверки особенно важны при ERR_SSL_PROTOCOL_ERROR, ошибках после ручного редактирования конфига и ситуации, когда сертификат есть, но HTTPS не открывается.
Также полезно найти, какой конфиг обслуживает домен.
Для Nginx: grep -R "server_name example.com" /etc/nginx/sites-enabled /etc/nginx/conf.d
Для Apache: sudo apachectl -S
Так можно увидеть, попадает ли домен в нужный server block или virtual host.
Как сервер отвечает на HTTP и HTTPS
curl помогает понять, как сервер отвечает на HTTP- и HTTPS-запросы. Это основной инструмент для проверки редиректов.
Проверка HTTP: curl -I http://example.com
Проверка HTTPS: curl -I https://example.com
Если HTTP должен перенаправлять на HTTPS, в ответе обычно ожидается 301 или 302 и заголовок Location:
Location: https://example.com/
Для анализа цепочки редиректов можно использовать: curl -I -L http://example.com
Если есть redirect loop, команда покажет повторяющиеся переходы или слишком длинную цепочку.
Отдельно стоит проверять все версии домена:
curl -I http://example.com
curl -I http://www.example.com
curl -I https://example.com
curl -I https://www.example.com
Так проще поймать ошибку, когда www и non-www ведут себя по-разному.
Какой сертификат получает браузер
Браузер показывает ошибку, но не всегда удобно понять, какой сертификат реально отдаёт сервер. Для этого используют openssl s_client.
Базовая команда: openssl s_client -connect example.com:443 -servername example.com
Параметр -servername важен, потому что на одном IP может быть несколько сайтов. Он передаёт SNI, чтобы сервер выбрал сертификат именно для нужного домена.
Через openssl можно увидеть:
- Какой сертификат отдаёт сервер;
- Для какого домена он выпущен;
- Кто его выпустил;
- Когда он истекает;
- Есть ли проблемы с цепочкой сертификатов.
Если нужно быстро посмотреть даты сертификата, можно использовать такую команду: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
Для проверки доменов в сертификате: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
Это помогает при ошибках “сертификат другого домена”, certificate expired и подозрении, что CDN или reverse proxy отдаёт не тот сертификат.
Проверка логов веб-сервера
Если DNS, Certbot, curl и openssl не дают полного ответа, нужно смотреть логи. Они помогают найти ошибки веб-сервера, проблемы с virtual host, TLS-конфигурацией, правами на файлы сертификата и редиректами.
Для Nginx обычно начинают с error log: sudo tail -n 50 /var/log/nginx/error.log
И access log: sudo tail -n 50 /var/log/nginx/access.log
Для Apache: sudo tail -n 50 /var/log/apache2/error.log
И: sudo tail -n 50 /var/log/apache2/access.log
Если у сайта настроены отдельные логи virtual host, нужно смотреть именно их. В панелях управления путь к логам может отличаться, но обычно он указан в настройках сайта или в конфиге веб-сервера.
Логи особенно полезны при ERR_SSL_PROTOCOL_ERROR, ошибках 502/503 после включения HTTPS, проблемах с reverse proxy и ситуациях, когда браузер показывает общую ошибку без понятных деталей.
После проверки логов обычно становится ясно, где продолжать диагностику: в DNS, Certbot, Nginx/Apache, CMS, CDN или конкретном правиле редиректа. Дальше важно не вносить исправления сразу во все места, а менять по одному слою и проверять результат.
Типовые ошибки при исправлении SSL
Когда HTTPS ломается, хочется быстро нажать “исправить SSL” в панели, поменять адрес сайта в CMS или заново выпустить сертификат. Иногда это помогает, но часто создаёт новые проблемы.
Лучше сначала понять, где находится ошибка: в DNS, сертификате, веб-сервере, CMS, CDN или редиректах. И только потом менять конкретный слой.
Чинить SSL только в CMS
CMS может влиять на HTTPS, но она не управляет всей SSL-цепочкой. WordPress, Bitrix, Drupal или другая система могут хранить адрес сайта, формировать ссылки, делать редиректы и подключать ресурсы. Но сам сертификат работает на уровне веб-сервера и TLS.
Если сертификат истёк, изменение адреса сайта в CMS не продлит его. Если домен указывает не на тот IP, плагин для HTTPS не заставит Let’s Encrypt пройти проверку. Если на 443 порту не настроен SSL, CMS тоже не исправит соединение.
CMS стоит проверять, когда базовый HTTPS уже работает, но внутри сайта остаются проблемы:
- Старые HTTP-ссылки в базе;
- mixed content;
- Неправильный site URL;
- Конфликтующий плагин редиректа;
- Кэш старых адресов;
- Абсолютные ссылки в шаблоне.
Правильный порядок такой: сначала DNS, сертификат, веб-сервер и редиректы. Потом CMS, база, шаблон, плагины и кэш.
Забывать про www и non-www
Для пользователя example.com и www.example.com могут выглядеть как один сайт. Для SSL это разные доменные имена.
Если сертификат выпущен только для example.com, он не будет автоматически подходить для www.example.com. И наоборот: сертификат для www.example.com не всегда покрывает основную версию без www.
Поэтому при диагностике нужно проверять обе версии:
curl -I https://example.com
curl -I https://www.example.com
И отдельно смотреть, какие домены включены в сертификат: sudo certbot certificates
Частая ошибка — настроить редирект с www на non-www, но не включить www в сертификат. Тогда пользователь заходит на https://www.example.com, получает ошибку сертификата ещё до редиректа и не доходит до основной версии сайта.
Лучше заранее выбрать основной вариант домена и привести всё к нему:
http://example.com → https://example.com
http://www.example.com → https://example.com
https://www.example.com → https://example.com
Или наоборот — если основная версия сайта должна быть с www.
Главное, чтобы сертификат покрывал все домены, с которых пользователь может начать переход.
Не проверять цепочку сертификатов
Иногда сертификат вроде бы выпущен правильно, но браузер всё равно показывает предупреждение. Причина может быть не в самом домене, а в цепочке сертификатов.
Для корректной работы сервер должен отдавать не только сертификат сайта, но и промежуточные сертификаты. Обычно для этого используют файл fullchain.pem, а не только отдельный сертификат домена.
Если в конфиге указан неполный файл, часть браузеров и клиентов может не доверять соединению.
Для Nginx путь обычно должен указывать на fullchain:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
Для Apache логика такая же: сервер должен использовать полную цепочку, а не случайный файл сертификата.
Для этого необходимо проверить настройки SSLCertificateFile и SSLCertificateKeyFile соответственно, для старых версий apache также важно добавить промежуточные сертификаты отдельно в директиву SSLCertificateChainFile.
Проверить, что реально отдаёт сервер, можно через OpenSSL: openssl s_client -connect example.com:443 -servername example.com -showcerts
Если цепочка неполная, проблема может проявляться не у всех пользователей сразу. В одном браузере сайт откроется, в другом появится предупреждение, а API-клиент или мобильное приложение может отказать в соединении.
Поэтому после ручной настройки SSL важно проверять не только дату сертификата и домен, но и то, что сервер отдаёт корректную цепочку.
Включать редиректы сразу в панели, CMS и CDN
Бесконечные редиректы часто появляются не из-за отсутствия SSL, а из-за слишком большого количества “помощников”.
Например, редирект HTTP → HTTPS включён:
- в панели управления VPS;
- в конфиге Nginx или Apache;
- в CMS;
- в плагине безопасности;
- в Cloudflare или другом CDN.
Каждый слой пытается перенаправить пользователя на “правильный” адрес. Но если правила отличаются, сайт начинает ходить по кругу: HTTP → HTTPS → HTTP, www → non-www → www, CDN → origin → CDN.
Проверить цепочку можно так: curl -I -L http://example.com
И отдельно для всех версий домена:
curl -I http://example.com
curl -I http://www.example.com
curl -I https://example.com
curl -I https://www.example.com
Лучше выбрать один основной уровень для редиректа. Обычно это веб-сервер или CDN. CMS должна знать правильный адрес сайта, но не обязательно должна управлять всей схемой HTTPS-переходов.
Если сайт за CDN, сначала нужно понять, как CDN подключается к origin-серверу: по HTTP или HTTPS, какой SSL-режим включён и не конфликтует ли он с правилами на сервере.
Исправлять redirect loop лучше постепенно: отключить лишние редиректы, оставить один понятный маршрут, проверить curl, затем вернуть только те правила, которые действительно нужны.
После исправления SSL не стоит оценивать результат только по главной странице. Нужно проверить обе версии домена, HTTP и HTTPS, внутренние страницы, формы, API-запросы и ресурсы. Так проще убедиться, что проблема исправлена, а не просто скрылась на одном URL.
Что проверить после исправления
После исправления SSL важно не ограничиваться фразой “в браузере замок появился”. Ошибка может исчезнуть на главной странице, но остаться на www, поддомене, внутренней странице, API или в автообновлении сертификата.
Сначала проверьте основные версии домена:
curl -I http://example.com
curl -I https://example.com
curl -I http://www.example.com
curl -I https://www.example.com
Нужно убедиться, что все варианты ведут к правильной финальной версии сайта. Например, если основной адрес — https://example.com, остальные версии должны аккуратно перенаправляться на него.
Затем проверьте, какой сертификат отдаёт сервер: openssl s_client -connect example.com:443 -servername example.com
Если используется www, проверьте и его: openssl s_client -connect www.example.com:443 -servername www.example.com
Сертификат должен быть действующим, выпущенным для нужного домена и с корректной цепочкой.
После этого проверьте список сертификатов Certbot: sudo certbot certificates
И автообновление: sudo certbot renew --dry-run
Если dry-run не проходит, SSL ещё нельзя считать исправленным. Сертификат может работать сейчас, но не продлится автоматически.
Также нужно открыть сайт в браузере и проверить DevTools. Во вкладках Console и Network не должно быть mixed content, заблокированных HTTP-ресурсов, ошибок загрузки скриптов, стилей, изображений, шрифтов, iframe и API-запросов.
Отдельно стоит проверить:
- Главную страницу;
- Несколько внутренних страниц;
- Формы авторизации и отправки заявок;
- Личный кабинет, если он есть;
- API-запросы;
- Изображения и файлы из медиатеки;
- Поддомены;
- CDN, если он используется;
- Мобильную версию сайта.
Если сайт работает через Cloudflare или другой CDN, нужно проверить не только публичный адрес, но и связку CDN → origin. Ошибка может исчезнуть для пользователя, но остаться между CDN и VPS.
После всех проверок полезно зафиксировать результат: какой домен выбран основным, где настроен редирект, как выпущен сертификат, работает ли автообновление и кто отвечает за дальнейшую поддержку SSL.
Заключение
Проблемы с SSL почти всегда проще решать по симптомам. certificate expired, mixed content, redirect loop, ошибка другого домена и ERR_SSL_PROTOCOL_ERROR выглядят похоже для владельца сайта, но возникают на разных уровнях.
Поэтому не стоит сразу перевыпускать сертификат, менять настройки CMS или включать новые редиректы. Сначала нужно понять, что именно сломалось: DNS, сертификат, веб-сервер, цепочка сертификатов, редирект, CMS или CDN.
Базовая диагностика строится вокруг нескольких проверок: dig показывает, куда указывает домен, certbot certificates — какие сертификаты есть на сервере, curl -I — как работают HTTP, HTTPS и редиректы, openssl s_client — какой сертификат реально отдаётся браузеру, а логи Nginx или Apache помогают найти скрытые ошибки.
Самые частые проблемы появляются из-за простых вещей: забыли про www, не проверили автообновление, оставили mixed content, включили редиректы сразу в панели, CMS и CDN или пытались чинить SSL только через настройки сайта.
Правильный подход — двигаться снизу вверх: DNS, веб-сервер, сертификат, HTTPS, редиректы, CDN и только потом CMS. Так меньше риск случайно усугубить проблему и проще понять, где именно находится причина.
SSL можно считать исправленным только после полной проверки: сайт открывается по HTTPS, все версии домена ведут куда нужно, сертификат действующий, цепочка корректная, mixed content не осталось, а автообновление проходит через certbot renew --dry-run.
FAQ
Почему браузер пишет, что сертификат истёк?
Браузер показывает certificate expired, когда сервер отдаёт сертификат с истёкшим сроком действия или при некорректном времени на устройстве. Обычно это значит, что автообновление не сработало или веб-сервер продолжает использовать старый сертификат. Если Certbot не используется, проверьте сертификат вручную, если же используется:
Сначала проверьте сертификаты Certbot: sudo certbot certificates
Затем проверьте автообновление: sudo certbot renew --dry-run
Если Certbot обновил сертификат, но браузер всё ещё видит старый, проверьте reload Nginx или Apache, CDN и то, какой сертификат реально отдаётся через openssl s_client.
Почему сайт открывается по HTTP, хотя SSL установлен?
SSL-сертификат сам по себе не всегда включает редирект на HTTPS. Сертификат может быть установлен, но сервер продолжает отдавать сайт по HTTP без перенаправления.
Проверьте ответ:
curl -I http://example.com
curl -I https://example.com
Если HTTP возвращает 200, а не 301 или 302, значит редирект не настроен. Его можно настроить на уровне Nginx, Apache, панели управления или CDN, но лучше не включать редиректы сразу в нескольких местах.
Что делать при redirect loop после включения HTTPS?
Redirect loop обычно появляется, когда несколько слоёв одновременно пытаются перенаправить сайт: веб-сервер, панель, CMS, плагин безопасности и CDN.
Сначала проверьте цепочку: curl -I -L http://example.com
Затем временно упростите схему: оставьте один основной редирект, например на уровне Nginx, Apache или CDN. После этого проверьте www и non-www, HTTP и HTTPS.
Если используется Cloudflare или другой CDN, отдельно проверьте SSL-режим и правила HTTPS. Cloudflare управляет двумя соединениями: между пользователем и Cloudflare, а также между Cloudflare и origin-сервером, поэтому ошибка может быть именно в этой связке.
Почему после SSL остаётся mixed content?
Mixed content появляется, когда страница открывается по HTTPS, но часть ресурсов загружается по HTTP. Это могут быть изображения, стили, скрипты, шрифты, iframe, видео или API-запросы.
Сам сертификат при этом может быть корректным. Проблема находится в ссылках внутри сайта, шаблоне, CMS, базе данных, кэше, CDN или внешних виджетах.
MDN описывает mixed content как ситуацию, когда защищённая страница использует ресурсы, которые загружаются через HTTP или другой небезопасный протокол.
Проверять нужно DevTools в браузере: вкладки Console и Network. Все внутренние ресурсы, формы, скрипты и API должны использовать HTTPS.
Как понять, какой сертификат реально отдаёт сервер?
Для этого используют openssl s_client: openssl s_client -connect example.com:443 -servername example.com
Параметр -servername важен, потому что на одном IP может быть несколько доменов. Он передаёт SNI и помогает серверу выбрать сертификат для нужного сайта.
Если нужно посмотреть даты сертификата: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
Если нужно проверить домены в сертификате: echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
Так можно понять, отдаёт ли сервер новый сертификат, не истёк ли он и подходит ли он для нужного домена.
Может ли Cloudflare сломать SSL?
Да, если неправильно настроить SSL-режим, редиректы или сертификат на origin-сервере.
Например, при режиме Flexible Cloudflare принимает HTTPS от пользователя, но подключается к origin-серверу по HTTP. Это может создавать конфликты с редиректами и ощущение, что сайт “вроде на HTTPS”, но между CDN и сервером схема другая.
При режиме Full Cloudflare использует HTTPS-соединение между посетителем и Cloudflare, а также подключается к origin-серверу по схеме, которую запросил посетитель.
Если ошибка появилась после включения CDN, нужно проверить SSL-режим, правила редиректа, сертификат на origin, DNS-проксирование и настройки “Always Use HTTPS” или похожих функций.
Нужно ли перевыпускать сертификат после смены IP?
Сам по себе сертификат выпускается как правило для домена, а не для IP-адреса. Поэтому после смены IP сертификат не всегда нужно перевыпускать. Если в SAN добавлен IP, то необходимо будет перевыпустить.
Но в любом случае нужно обновить DNS-записи, чтобы домен указывал на новый VPS или новый origin-сервер. После этого важно проверить, что на новом сервере есть корректный сертификат и веб-сервер отдаёт его для нужного домена.
Если вы перенесли сайт на новый VPS, проще не копировать старую SSL-настройку вслепую, а проверить:
dig +short example.com
curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com
Если сертификат на новом сервере отсутствует, истёк или выпущен не для того домена, его нужно выпустить заново.
Список источников
1. Let’s Encrypt — Challenge Types
