Ошибки SSL — одна из самых частых причин, по которой пользователи не могут открыть сайт. Браузер блокирует соединение, показывает предупреждение, и трафик теряется. В этом руководстве разберём основные типы ошибок, их причины и пошаговые способы исправления.
Перед началом диагностики используйте инструмент проверки SSL — он покажет состояние сертификата, цепочку доверия и совместимость с браузерами. Для анализа заголовков безопасности примените Security Headers.
ERR_CERT_AUTHORITY_INVALID
Суть ошибки
Браузер не доверяет центру сертификации (CA), выдавшему сертификат. Цепочка доверия прервана: сертификат либо самоподписанный, либо выпущен неизвестным CA, либо промежуточные сертификаты не переданы.
Типичные причины
| Причина | Описание |
|---|---|
| Самоподписанный сертификат | Сертификат создан на сервере, не подписан доверенным CA |
| Отсутствует цепочка | На сервер загружен только конечный сертификат, без промежуточных |
| Устаревший корневой CA | Браузер не содержит корневого сертификата старого CA |
| Неправильный порядок цепочки | Промежуточные сертификаты в неверном порядке |
Как исправить
1. Использовать сертификат от доверенного CA
Самоподписанные сертификаты подходят только для разработки. В продакшене используйте Let's Encrypt, Comodo, DigiCert или другого доверенного провайдера. Подробнее в руководстве по Let's Encrypt.
2. Добавить полную цепочку сертификатов
Сервер должен отдавать не только cert.pem, но и цепочку промежуточных сертификатов. В Nginx и Apache используется fullchain.pem (сертификат + цепочка).
Nginx:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
Apache:
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
3. Проверить порядок в цепочке
Порядок должен быть: сертификат сервера → промежуточный(е) → корневой. Обычно fullchain.pem уже содержит правильный порядок. Для ручной сборки:
cat cert.pem intermediate.pem root.pem > fullchain.pem
4. Проверка через OpenSSL
openssl s_client -connect example.com:443 -showcerts
Убедитесь, что вывод содержит несколько сертификатов (сервер + промежуточные). Ошибка «unable to get local issuer certificate» указывает на неполную цепочку.
ERR_CERT_COMMON_NAME_INVALID
Суть ошибки
Имя в сертификате не совпадает с доменом, который запрашивает пользователь. Сертификат выдан для example.com, а пользователь открывает www.example.com или subdomain.example.com.
Причины
- Сертификат выдан только для
example.com, безwww - Пользователь заходит по IP вместо домена
- Сертификат для другого домена (например, после переноса)
- Wildcard-сертификат не покрывает используемый поддомен
Как исправить
1. Включить все нужные домены в сертификат
При получении Let's Encrypt:
sudo certbot certonly --nginx -d example.com -d www.example.com
2. Редирект на покрытый домен
Если сертификат только для example.com, настройте редирект с www:
server {
listen 443 ssl;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
3. Wildcard для поддоменов
Для множества поддоменов используйте wildcard:
sudo certbot certonly --dns-cloudflare -d example.com -d "*.example.com"
ERR_CERT_DATE_INVALID (истёкший сертификат)
Суть ошибки
Сертификат просрочен: дата на сервере или у пользователя выходит за пределы срока действия (Not Before / Not After).
Причины
- Сертификат не обновлён (Let's Encrypt — 90 дней)
- Сбой автообновления (certbot renew)
- Неправильное время на сервере
- Разница часовых поясов
Как исправить
1. Обновить сертификат
sudo certbot renew
sudo systemctl reload nginx
2. Проверить время на сервере
date
sudo timedatectl
Если время неверное, синхронизировать с NTP:
sudo timedatectl set-ntp true
3. Настроить мониторинг
Используйте SSL Monitor для отслеживания срока действия. Получайте уведомления за 14–30 дней до истечения.
4. Проверить cron/systemd timer
sudo systemctl status certbot.timer
sudo certbot renew --dry-run
Mixed Content (смешанный контент)
Суть ошибки
Страница загружена по HTTPS, но запрашивает ресурсы (скрипты, стили, изображения) по HTTP. Браузер блокирует небезопасный контент.
Типичные сообщения
- «Mixed Content: The page was loaded over HTTPS, but requested an insecure script»
- «Blocked loading mixed active content»
- Часть страницы не отображается (изображения, шрифты)
Как исправить
1. Заменить абсолютные HTTP-URL на относительные или HTTPS
Плохо:
<img src="http://example.com/image.jpg">
<script src="http://cdn.example.com/script.js"></script>
Хорошо:
<img src="/image.jpg">
<script src="https://cdn.example.com/script.js"></script>
Или протокол-относительные URL:
<img src="//cdn.example.com/image.jpg">
2. Content Security Policy
Если контент генерируется динамически, настройте CSP с upgrade-insecure-requests:
Content-Security-Policy: upgrade-insecure-requests
Браузер автоматически заменит http:// на https:// для запросов на той же странице.
3. Поиск смешанного контента
Проверьте в DevTools (Console): браузер выводит предупреждения о blocked mixed content. Или используйте расширения типа «Why No Padlock» для поиска HTTP-ресурсов на HTTPS-странице.
4. База данных и CMS
Часто контент с HTTP хранится в базе. Нужна массовая замена:
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://', 'https://');
(Пример для WordPress; для других CMS — аналогичные запросы или плагины.)
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Суть ошибки
Клиент и сервер не смогли договориться о версии TLS или наборе шифров. Обычно — устаревший протокол (SSLv3, TLS 1.0) или слабые шифры отключены на сервере.
Причины
- Сервер принимает только TLS 1.2+, а клиент (старый браузер/система) поддерживает только TLS 1.0
- Ошибка в конфигурации шифров
- Прокси или балансировщик переписывает протокол
Как исправить
1. Проверить поддерживаемые протоколы
nmap --script ssl-enum-ciphers -p 443 example.com
Или:
openssl s_client -connect example.com:443 -tls1
openssl s_client -connect example.com:443 -tls1_2
2. Настроить совместимую конфигурацию Nginx
Минимально безопасная конфигурация с поддержкой старых клиентов:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
Не включайте SSLv3, TLS 1.0, TLS 1.1 — они небезопасны.
3. Проверить прокси и CDN
Cloudflare, AWS ALB и другие прокси имеют свои настройки TLS. Убедитесь, что «Minimum TLS Version» не выше, чем поддерживают ваши клиенты (обычно TLS 1.2 — разумный минимум).
ERR_CERT_REVOKED
Суть ошибки
Сертификат был отозван центром сертификации. Причины отзыва: компрометация приватного ключа, смена владельца домена, ошибка при выдаче.
Как исправить
Отозванный сертификат нельзя «починить». Нужно получить новый:
sudo certbot certonly --force-renewal -d example.com
Если отзыв был ошибочным — свяжитесь с CA. Для Let's Encrypt — через форум сообщества.
NET::ERR_CERT_SYMANTEC_LEGACY
Суть ошибки
Сертификат выдан центром сертификации, который больше не доверяется Chrome (и другими браузерами). Касается старых сертификатов Symantec, GeoTrust, Thawte (до определённой даты).
Как исправить
Заменить сертификат на выпущенный доверенным CA. Let's Encrypt, DigiCert, Sectigo — актуальные варианты.
Проблемы с цепочкой (chain issues)
Симптомы
- Ошибка в одних браузерах, в других — нет (разные встроенные хранилища корневых сертификатов)
- Мобильные устройства показывают ошибку, десктоп — нет
- Старые версии ОС не доверяют сертификату
Диагностика
SSL Labs (Qualys):
https://www.ssllabs.com/ssltest/analyze.html?d=example.com
Показывает полную цепочку, предупреждения, совместимость.
OpenSSL:
openssl s_client -connect example.com:443 -servername example.com
Проверьте вывод: количество сертификатов, наличие «Verify return code: 0 (ok)».
Исправление
Убедитесь, что fullchain.pem содержит:
- Сертификат сервера
- Промежуточный(е) сертификат(ы) CA
- Корневой сертификат (опционально, но некоторые старые клиенты требуют)
Для Let's Encrypt fullchain.pem уже корректен. Для платных CA — скачайте bundle с сайта провайдера.
Ошибки на стороне клиента
Устаревшие браузеры
Windows XP, старые Android — не поддерживают TLS 1.2. Решение: либо включить старые протоколы (не рекомендуется из соображений безопасности), либо смириться с потерей доли трафика. Статистика: менее 1% в 2026 году.
Корпоративные прокси и антивирусы
Корпоративные файрволы перехватывают HTTPS и подставляют свой сертификат. Пользователь видит предупреждение. Это не ошибка вашего сервера — проблема на стороне клиентской сети.
Кэш браузера
Иногда браузер кэширует старый (битый) сертификат. Решение для пользователя: очистить кэш, перезапустить браузер, попробовать режим инкогнито.
Чек-лист диагностики
| Шаг | Действие |
|---|---|
| 1 | Проверить сертификат через SSL Checker |
| 2 | Проверить срок действия (Not After) |
| 3 | Проверить имена в сертификате (CN, SAN) |
| 4 | Проверить цепочку (openssl s_client) |
| 5 | Проверить протоколы и шифры (SSL Labs) |
| 6 | Проверить mixed content в коде страницы |
| 7 | Проверить время на сервере |
| 8 | Проверить конфигурацию Nginx/Apache |
Ошибки при использовании CDN и прокси
Cloudflare
При включении Cloudflare между пользователем и вашим сервером встаёт прокси. Возможные проблемы:
- SSL mode Full (Strict) — Cloudflare проверяет ваш origin. Нужен валидный сертификат на origin (можно самоподписанный для Cloudflare, но лучше Let's Encrypt).
- Ошибка 526 — Invalid SSL certificate на origin. Проверьте цепочку и срок действия.
- Mixed content — Cloudflare не исправляет HTTP-ресурсы в контенте. Нужно править на стороне сайта.
AWS, Azure, другие облака
Балансировщики и Application Load Balancer могут терминировать SSL. Сертификат загружается в панель облака, а не на веб-сервер. Ошибки цепочки или имени — проверять в настройках балансировщика.
Диагностика через браузер
Chrome DevTools
- F12 → вкладка Security
- Просмотр сертификата, цепочки, протокола
- При mixed content — вкладка Console с фильтром «Mixed Content»
Firefox
- Клик по замку в адресной строке → «Подключение защищено» → «Подробнее»
- Просмотр сертификата и сведений о соединении
Ошибки в мобильных приложениях
Встроенные WebView (Android, iOS) могут использовать устаревшие версии TLS или ограниченный набор шифров. Если ваше приложение открывает HTTPS-страницы и пользователи получают ошибки:
- Обновите WebView / системные компоненты
- Проверьте минимальную версию TLS на сервере (TLS 1.2 — разумный минимум)
- Используйте системный браузер для критичных страниц вместо WebView
Ошибки при использовании самоподписанных сертификатов
В разработке часто используют самоподписанные сертификаты. Браузеры показывают предупреждение — это ожидаемо. Решения:
- Добавить сертификат в доверенные на локальной машине (только для разработки)
- Использовать mkcert для локальных доверенных сертификатов
- В продакшене — только сертификаты от доверенных CA
Проверка через онлайн-инструменты
Помимо SSL Checker на rechecker.ru используйте:
- SSL Labs (Qualys) — детальный отчёт по цепочке, протоколам, шифрам, совместимости с браузерами. Рекомендуется для глубокой диагностики.
- WhyNoPadlock — поиск mixed content на странице.
- Проверка с разных географических точек — иногда ошибки проявляются только в определённых регионах из-за CDN или локальных кэшей.
Серверные логи
При массовых ошибках проверьте логи веб-сервера и TLS:
- Nginx:
error_logможет содержать SSL handshake errors - Apache:
ssl_error_log - Ищите по «SSL», «certificate», «handshake»
Дополнительные материалы
Заключение
Большинство ошибок SSL решаются корректной настройкой: полная цепочка сертификатов, актуальный срок действия, правильные имена доменов, отсутствие mixed content. Используйте инструменты диагностики, следуйте чек-листу — и проблема будет локализована. Для долгосрочной стабильности настройте автообновление сертификатов и мониторинг срока действия.