Проверка TLS-сертификата

Зачем нужен сертификат

Когда браузер подключается к https://example.com, ему кто-то отвечает. Принадлежит ли этот кто-то example.com, это уже другой вопрос. Ответить вместо сайта мог любой, кто находится в сети посередине.

Поэтому сервер должен предъявить документ. Сертификат: это небольшой файл, в котором есть открытый ключ, список имён хостов, от имени которых этот ключ может выступать, дата начала, дата окончания и подпись удостоверяющего центра (CA), проверившего, кто управляет этими именами. Браузер идёт по своему списку. Имя в адресной строке должно быть в сертификате. Сегодняшняя дата должна лежать между двумя датами. Подпись должна вести к центру, которому устройство уже доверяет. И сервер должен доказать, что владеет соответствующим закрытым ключом. Не выполнено хоть одно условие, и посетитель видит предупреждение во весь экран.

Шифрование начинается только после того, как всё это проверено. Замок означает, что сервер доказал, кто он, и шифрование опирается на это доказательство.

Что проверяет инструмент

Он подключается к порту 443 дважды. В первый раз он принимает что угодно, чтобы прочитать сертификат в любом состоянии. Во второй раз он проверяет всё по стандартному списку доверенных корневых сертификатов, как это сделал бы строгий клиент.

Затем он запрашивает четыре формы адреса (http и https, с www и без) и показывает, куда приводит каждая и присылает ли сайт заголовок HSTS. Если нужна эта часть по шагам, это делает трассировка перенаправлений.

В Chrome работает, везде остальном нет

Удостоверяющие центры не подписывают ваш сертификат корневым ключом. Они подписывают его промежуточным сертификатом, который в свою очередь подписан корневым. Устройства хранят только корневые, поэтому ваш сервер должен отправлять промежуточный вместе со своим сертификатом. Вместе они образуют цепочку.

Когда сервер отправляет только свой сертификат, Chrome и Edge на компьютере к этому снисходительны. Они часто скачивают недостающий промежуточный или берут тот, что видели на другом сайте. Firefox с новым профилем, старые телефоны на Android, curl, платёжные вебхуки, почтовые серверы и большинство библиотек в языках программирования такой услуги не окажут. Так и получается сайт, который владельцу кажется идеальным, а у API-клиента не работает. Инструмент называет это Неполная цепочка и сообщает о ней, когда проверка не прошла, а прислан был только один сертификат.

Как исправить типичные неполадки

• Срок истёк. Автоматические сертификаты продлеваются примерно за 30 дней до конца, так что если ваш закончился, задание продления не срабатывает уже несколько недель. С Certbot запустите certbot renew --dry-run и прочитайте ошибку. Обычно это переехавшая DNS-запись, брандмауэр, закрывший порт 80, или перенаправление, которое проглатывает /.well-known/acme-challenge/.
• Имя не покрыто. Запросите сертификат заново и перечислите все имена хостов: certbot -d example.com -d www.example.com. Wildcard *.example.com покрывает один уровень поддоменов. Сам example.com он не покрывает, и на этом попадаются многие.
• Неполная цепочка. Укажите серверу файл с полной цепочкой. В nginx: ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;. В Apache 2.4.8 и новее SSLCertificateFile принимает тот же файл.
• Самоподписанный. Замените его сертификатом от публичного центра. Let’s Encrypt, ZeroSSL и Google Trust Services выдают их бесплатно.
• Старый протокол. Включите TLS 1.2 и 1.3. В nginx: ssl_protocols TLSv1.2 TLSv1.3;

То же самое можно увидеть в терминале командой openssl s_client -connect example.com:443 -servername example.com.