Что такое SSL-сертификат?
SSL/TLS-сертификат — это цифровой документ, подписанный доверенным удостоверяющим центром (CA), который связывает открытый ключ с одним или несколькими именами хостов. При подключении сервер предъявляет сертификат в ходе TLS-рукопожатия, а клиент проверяет подпись CA, срок действия сертификата и совпадение одного из перечисленных имён с запрошенным хостом.
Несмотря на историческое название, современные сертификаты используют TLS (сегодня TLS 1.2 и 1.3), а не устаревший SSL. Формат X.509 и цепочка PKI определены в RFC 5280, специфика HTTPS — в RFC 2818.
Зачем проверять SSL-сертификат?
1Предотвратите внезапное истечение
Любой современный браузер и почтовый клиент сломается, как только сертификат истечёт — отслеживайте оставшиеся дни заранее
2Подтвердите покрытие имён хостов
Сертификат действителен только для имён в списке SAN — проверьте каждый поддомен, который вы обслуживаете
3Выявите недоверенные цепочки
Самоподписанные или выданные неизвестным CA сертификаты вызывают предупреждения браузера — обнаружьте их раньше пользователей
4Проверьте STARTTLS для почты
Почтовые провайдеры ожидают, что MX-точки чисто согласуют TLS — сломанный сертификат тихо снижает доставляемость
Как работает проверка SSL — шаг за шагом
Клиент открывает TLS-соединение с вашим доменом и отправляет ClientHello.
Ваш сервер возвращает цепочку сертификатов: листовой сертификат + любые промежуточные сертификаты CA.
Клиент идёт по цепочке вверх до доверенного корневого CA в своём хранилище.
Он проверяет каждую подпись, что каждый сертификат в пределах срока действия и что ни один не отозван.
Наконец, он проверяет, что список SAN листового сертификата содержит запрошенное имя хоста.
Если все проверки пройдены, рукопожатие завершается и обменивается сеансовый ключ.
Поля сертификата кратко
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
| openssl x509 -noout -textКлючевые поля сертификата
Issuer— центр сертификации, подписавший сертификатSubject CN— устаревшее основное имя хостаSAN— современный список действительных имён хостовNot Before / After— период действияKey Usage— разрешённые операции (аутентификация сервера и т.д.)Типичные сбои SSL и их решения
Истёкший сертификат
Немедленно обновите и настройте мониторинг — большинство команд оповещают за 30 дней
Несовпадение имени хоста
Проверяемое имя отсутствует в SAN — перевыпустите сертификат с нужным именем или корректным wildcard
Самоподписанный сертификат
Браузеры их отклоняют — перейдите на бесплатный сертификат Let's Encrypt или управляемый сертификат вашего CDN
Неполная цепочка
Если промежуточные сертификаты отсутствуют, некоторые клиенты не смогут проверить цепочку — включите их вместе с листовым в конфигурации сервера
Часто задаваемые вопросы
SSL/TLS-чекер подтверждает, что домен отдаёт действительный сертификат от доверенного удостоверяющего центра, что поля Subject и Subject Alternative Names покрывают проверяемое имя хоста, что сертификат находится в пределах срока действия и что он не самоподписан. Эти проверки вместе доказывают, что браузер или почтовый клиент будет доверять соединению.
Как только сертификат истекает, любой браузер показывает предупреждение безопасности, и большинство современных почтовых клиентов отказывают в STARTTLS. Истечение SSL ломает и веб-трафик, и аутентифицированную отправку почты. Мониторинг оставшихся дней даёт запас на обновление — большинство команд оповещают при значении ниже 30.
Несовпадение имени хоста возникает, когда список SAN сертификата не содержит точно проверяемое имя. Частые причины — проверка www-поддомена против сертификата только для apex, отсутствие wildcard для под-поддоменов или случайная отдача неверного виртуального хоста на общем IP. Перевыпустите сертификат с правильными SAN-записями.
Да, косвенно. Почтовые провайдеры ожидают, что MX, отправка SMTP и трекинг-домены успешно согласуют TLS. Сломанный или истёкший сертификат вынуждает перейти в текстовый режим или приводит к ошибке доставки, что со временем снижает репутацию. Поддержание всех связанных с почтой доменов с действующим SSL — часть здоровой стратегии аутентификации.
Перевыпустите сертификат через вашего хостинг-провайдера или удостоверяющий центр либо включите автопродление с помощью сервиса вроде Let's Encrypt, чтобы избежать просрочек в будущем. После установки нового сертификата запустите проверку SSL, чтобы подтвердить, что дата истечения и цепочка сертификатов действительны.
Просроченный сертификат на вашей инфраструктуре отправки может нарушить TLS-соединения и подорвать сигналы доверия, которые ищут получатели, что способно навредить доставляемости. Поддержание действительности сертификатов на вашем почтовом сервере и на сайтах, на которые ведут ссылки в письмах, помогает защитить и вашу репутацию, и доверие получателей.