Загрузка...
Загрузка...
Подробное руководство по типичным ошибкам SSL: ERR_CERT_AUTHORITY_INVALID, mixed content, истёкший сертификат, проблемы цепочки. Диагностика и исправление для веб-мастеров.
Сравнение типов SSL-сертификатов: DV, OV, EV, Wildcard, Multi-Domain. Как выбрать подходящий сертификат для вашего проекта. Стоимость, сроки выдачи, особенности.
БезопасностьВсё о SSL/TLS сертификатах: типы, получение, настройка, обновление. Let's Encrypt, Wildcard, EV-сертификаты. Практическое руководство для веб-разработчиков.
БезопасностьПошаговая настройка HSTS для принудительного HTTPS. max-age, includeSubDomains, preload. Nginx, Apache, Cloudflare. Проверка и отладка.
БезопасностьПошаговое руководство по установке бесплатных SSL-сертификатов Let's Encrypt на Apache и Nginx. Certbot, автообновление, wildcard. Практический гайд для веб-мастеров.
Поделитесь с коллегами или изучите другие материалы блога
Ошибки SSL — одна из самых частых причин, по которой пользователи не могут открыть сайт. Браузер блокирует соединение, показывает предупреждение, и трафик теряется. В этом руководстве разберём основные типы ошибок, их причины и пошаговые способы исправления.
Перед началом диагностики используйте инструмент проверки SSL — он покажет состояние сертификата, цепочку доверия и совместимость с браузерами. Для анализа заголовков безопасности примените Security Headers.
Браузер не доверяет центру сертификации (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» указывает на неполную цепочку.
Имя в сертификате не совпадает с доменом, который запрашивает пользователь. Сертификат выдан для example.com, а пользователь открывает www.example.com или subdomain.example.com.
example.com, без www1. Включить все нужные домены в сертификат
При получении 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"
Сертификат просрочен: дата на сервере или у пользователя выходит за пределы срока действия (Not Before / Not After).
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
Страница загружена по HTTPS, но запрашивает ресурсы (скрипты, стили, изображения) по HTTP. Браузер блокирует небезопасный контент.
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 — аналогичные запросы или плагины.)
Клиент и сервер не смогли договориться о версии TLS или наборе шифров. Обычно — устаревший протокол (SSLv3, 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 — разумный минимум).
Сертификат был отозван центром сертификации. Причины отзыва: компрометация приватного ключа, смена владельца домена, ошибка при выдаче.
Отозванный сертификат нельзя «починить». Нужно получить новый:
sudo certbot certonly --force-renewal -d example.com
Если отзыв был ошибочным — свяжитесь с CA. Для Let's Encrypt — через форум сообщества.
Сертификат выдан центром сертификации, который больше не доверяется Chrome (и другими браузерами). Касается старых сертификатов Symantec, GeoTrust, Thawte (до определённой даты).
Заменить сертификат на выпущенный доверенным CA. Let's Encrypt, DigiCert, Sectigo — актуальные варианты.
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 содержит:
Для 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 |
При включении Cloudflare между пользователем и вашим сервером встаёт прокси. Возможные проблемы:
Балансировщики и Application Load Balancer могут терминировать SSL. Сертификат загружается в панель облака, а не на веб-сервер. Ошибки цепочки или имени — проверять в настройках балансировщика.
Встроенные WebView (Android, iOS) могут использовать устаревшие версии TLS или ограниченный набор шифров. Если ваше приложение открывает HTTPS-страницы и пользователи получают ошибки:
В разработке часто используют самоподписанные сертификаты. Браузеры показывают предупреждение — это ожидаемо. Решения:
Помимо SSL Checker на rechecker.ru используйте:
При массовых ошибках проверьте логи веб-сервера и TLS:
error_log может содержать SSL handshake errorsssl_error_logБольшинство ошибок SSL решаются корректной настройкой: полная цепочка сертификатов, актуальный срок действия, правильные имена доменов, отсутствие mixed content. Используйте инструменты диагностики, следуйте чек-листу — и проблема будет локализована. Для долгосрочной стабильности настройте автообновление сертификатов и мониторинг срока действия.