Как проверить SSL-сертификат сайта без лишних сервисов

Браузер показывает начало, а не весь аудит

Проверить SSL-сертификат можно без внешних сканеров. Браузер уже показывает много полезного: кому выдан сертификат, для каких имён он подходит, когда истекает, кто выдал, доверяет ли система цепочке. Но браузер скрывает часть технических деталей и не всегда удобно показывает, какой сертификат отдаёт сервер при разных SNI или с разных IP.

Начните с браузера, но не заканчивайте на нём. Откройте сайт, посмотрите сведения о соединении, проверьте имя и срок. Затем сравните результат с тем, что отдаёт сервер через командную строку. Это особенно важно на серверах с несколькими доменами, CDN, балансировщиком или недавно обновлённым сертификатом.

Если нужно понять, какой сертификат вообще подходит проекту, рядом остаётся материал проверка SSL-сертификата. Здесь же речь о фактической проверке того, что уже установлено.

openssl с правильным SNI

Главная ошибка ручной проверки — подключиться к серверу без имени. Команда должна передать SNI, иначе сервер может вернуть default-сертификат. Для базовой проверки используют `openssl s_client -connect example.com:443 -servername example.com -showcerts`. В выводе смотрят цепочку, имя, срок, issuer, verify return code и то, какие сертификаты сервер отдал клиенту.

Если проверяется поддомен, в `-servername` указывают именно его. Если сайт за CDN, ответ будет от edge-сервера, а не обязательно от origin. Если нужно проверить origin, используют прямой IP и Host/SNI, но делают это осторожно, чтобы не спутать публичную и внутреннюю конфигурацию. Важно не просто увидеть сертификат, а понять, для какого имени он был выбран.

SAN-сертификаты требуют внимания к списку имён. После выпуска можно открыть материал SAN-сертификат: что это и когда он лучше wildcard, чтобы проверить не только срок, но и точное покрытие доменов.

curl показывает HTTP-слой поверх TLS

`curl -v https://example.com/` помогает увидеть соединение и HTTP-ответ. Он показывает, какой сертификат проверен, какой протокол использован, какой код вернул сервер, есть ли редирект, куда он ведёт и не появляется ли ошибка до загрузки страницы. Это удобно, когда браузер показывает общую ошибку, а нужно быстро понять, что происходит на транспортном и HTTP-слое.

С помощью `curl -I` можно проверить заголовки без загрузки тела страницы. Это полезно для редиректов с HTTP на HTTPS, HSTS, CDN-кэша и server header. Если редирект уводит на другой домен, нужно отдельно проверить сертификат конечного адреса. Частая ошибка: основной домен защищён, а `www` или поддомен в цепочке редиректа — нет.

OCSP, цепочка и ошибки SSL имеют свои нюансы. Старый разбор OCSP, цепочка сертификатов и ошибки SSL пригодится, если браузер доверяет сайту не у всех пользователей.

Что сохранить для SSL-диагностики

Хорошая запись проверки должна быть короткой: домен, дата, IP или CDN, срок сертификата, список SAN, issuer, результат проверки цепочки, HTTP-код, редирект и вывод. Если есть ошибка, фиксируют точный текст браузера или `openssl`, а не пересказ «SSL не работает». Это ускоряет ремонт и снижает риск перевыпустить сертификат без причины.

Если сайт использует HSTS, проверять нужно осторожнее. После включения HSTS браузер будет жёстко требовать HTTPS, и временные ошибки станут заметнее. Усиление HTTPS лучше делать после базовой проверки сертификата и цепочки. Для этой части подходит материал HSTS, TLS 1.3 и усиление HTTPS без потери скорости.

Практический минимум: браузер, `openssl` с SNI, `curl -v`, проверка SAN и срока, проверка цепочки, проверка редиректа. Этого достаточно, чтобы не зависеть от случайного онлайн-сервиса и понять, что действительно отдаёт ваш сервер.

Кейс: онлайн-проверка была зелёной, а сервер отдавал default

Владелец проверил сайт через внешний сервис и увидел зелёный статус. Но часть пользователей получала ошибку имени. Ручная проверка с `openssl` показала, что при запросе без SNI сервер отдаёт default-сертификат, а при правильном SNI — нужный. Старые клиенты и один внутренний мониторинг ходили без SNI и падали.

Решение было не в перевыпуске сертификата, а в настройке default vhost и мониторинга. На сервер добавили корректный fallback, а мониторинг перевели на проверку с SNI. Вывод: ручная проверка полезна не потому, что она сложнее, а потому что показывает разные режимы ответа сервера.

Как проверить сертификат без передачи приватных данных

Что можно показать

Сертификат VPN сервера содержит публичные сведения о сроке и имени. Сертификат для VPN проверяют по цепочке доверия. Домен для VPN сервера сверяют с профилем. Приватный ключ, пароль и ссылка VPN не прикладывают к обычному вопросу о сертификате.

Сайт и подключение

Сайт VPN сервиса может иметь другой сертификат. VPN и HTTPS не равны одной проверке. Ошибка сертификата VPN в клиенте требует текста ошибки, времени и имени, а не полного секретного профиля. Профиль VPN сохраните локально и передавайте только обезличенные параметры.

Устройства

VPN для Android, VPN для iPhone и VPN для Windows могут различаться по доверенным центрам. Корневой сертификат VPN не устанавливают по совету из случайного чата. Сертификат пользователя VPN не заменяет серверный. Сравнивайте фактическую цепочку и документацию клиента.

Контроль

Проверить VPN соединение нужно после исправления на том же устройстве. DNS через VPN проверяют отдельно от TLS. VPN не подключается может иметь причину в порте или авторизации. Безопасный VPN сохраняет секреты и показывает поддержке только необходимые публичные сведения.

В этой схеме серверная часть — vpn сервер; рядом разобраны vpn для android и клиентские шаги для vpn для iphone и vpn для видео.

FAQ о ручной проверке SSL

Как проверить SAN без онлайн-сервиса?

Откройте сертификат в браузере или используйте `openssl s_client` с правильным `-servername`, затем посмотрите раздел Subject Alternative Name.

Что показывает `openssl s_client`?

Он показывает сертификат, цепочку, SNI-ответ, verify return code и параметры TLS. Это ближе к реальному серверному ответу, чем статус в панели.

Почему браузер и curl могут видеть разные сертификаты?

Из-за SNI, IPv4/IPv6, CDN, балансировщика или разных узлов. Один клиент получает нужный vhost, другой — default-сертификат.

Как проверить срок сертификата?

Посмотреть Not Before и Not After в браузере, через `openssl` или мониторинг. Но срок нужно проверять вместе с SAN, issuer и цепочкой.

Как проверить сертификат VPN, не отправляя закрытый ключ стороннему сервису?

Для TLS-узла проверяют публичный сертификат, который сервер отдаёт при соединении: имя, срок и цепочку доверия. Закрытый ключ для этого не нужен. Убедитесь, что проверяете правильный порт и серверное имя, иначе можете увидеть сертификат другого виртуального сервиса.

Как проверить сертификат VPN, не раскрывая настройки подключения?

Для первичного разбора достаточно имени сервера, времени и текста ошибки без пароля или токена. Сертификат для VPN проверяют по сроку, имени и цепочке. При необычном покрытии изучите сертификат для ВПН с несколькими SAN; успех проверки главной страницы не описывает другой сервер, указанный в профиле.