Диагностика TLS-рукопожатия: версии, сертификаты, время

Прямой ответ

Согласование TLS выполняется до передачи данных, поэтому задержка согласования добавляется к времени первого запроса по соединению. Диагностика охватывает версию, шифронабор и сертификат.

# Версия, шифронабор и сертификат
openssl s_client -connect example.com:443 -servername example.com \
  -brief -tls1_3 < /dev/null

# Срок действия сертификата
openssl s_client -connect example.com:443 -servername example.com \
  < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Параметр указания имени сервера обязателен при размещении нескольких сертификатов на одном адресе, поскольку сертификат выбирается по имени. Об устройстве рукопожатия — в статье про TLS простыми словами.

Время согласования и возобновление сессии

Два аспекта определяют влияние согласования на время запроса.

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

Возобновление сессии. Параметры прежней сессии переиспользуются, поэтому обмен сокращается. Возобновление возможно, если сервер сохраняет параметры и клиент предъявляет идентификатор сессии.

Практическое следствие: повторное использование соединения исключает согласование, поэтому время запроса сокращается.

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

Три признака проблемы с согласованием.

Ошибка подтверждения сертификата. Цепочка неполна либо срок истёк, поэтому клиент отклоняет сертификат.

Согласование более ранней версии. Сервер не поддерживает требуемую версию, поэтому согласуется ранняя версия с иными свойствами.

Отсутствие возобновления сессии. Каждое соединение выполняет полное согласование, поэтому время первого запроса растёт.

О продлении сертификатов — в статье про Let's Encrypt; о распределении задержек — в статье про диагностику задержек.

Влияние промежуточных узлов на согласование

Промежуточный узел может завершать согласование самостоятельно, поэтому параметры соединения отличаются от настроенных на сервере.

Завершение согласования на промежуточном узле. Прокси выполняет согласование с клиентом и устанавливает отдельное соединение с сервером, поэтому клиент согласует параметры с промежуточным узлом, а не с сервером.

Различие версий и наборов. Перечень версий и шифронаборов на промежуточном узле может отличаться от перечня на сервере, поэтому результат согласования определяется промежуточным узлом.

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

Практическое следствие: при наличии промежуточного узла, завершающего согласование, диагностика охватывает и параметры промежуточного узла, и параметры соединения с сервером.

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

Проверка согласования после изменения сертификата

Замена сертификата изменяет параметры согласования, поэтому проверка выполняется после каждого изменения.

Полнота цепочки. Новый сертификат передаётся с промежуточными, поэтому клиент строит цепочку подтверждения без обращения к собственному хранилищу.

Соответствие имени. Имя в сертификате соответствует имени, по которому обращается клиент, поэтому подтверждение выполняется.

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

Практическое следствие: проверка согласования выполняется после замены сертификата, поскольку неполная цепочка либо несоответствие имени обнаруживаются только при фактическом подключении.

Практика: диагностика согласования TLS

1. Проверьте согласованную версию и шифронабор. Результат показывает фактические параметры, а не настроенные.

2. Указывайте имя сервера при подключении. Сертификат выбирается по имени, поэтому без параметра возвращается иной сертификат.

3. Проверьте срок и цепочку сертификата. Истёкший срок либо неполная цепочка приводят к ошибке подтверждения.

4. Измерьте время согласования. Тайминг этапа показывает долю согласования в общем времени запроса.

5. Проверьте возобновление сессии. Повторное подключение выполняется быстрее при переиспользовании параметров.

6. Используйте повторное использование соединения. Переиспользование исключает согласование, поэтому время запроса сокращается.

7. Проверяйте после изменения сертификата. Замена сертификата изменяет цепочку, поэтому подтверждение проверяется повторно.

Рекомендации:

1. Различайте согласование и передачу данных. Согласование выполняется до передачи, поэтому задержка добавляется к первому запросу.
2. Учитываем влияние промежуточного сертификата. Отсутствие промежуточного сертификата в цепочке приводит к ошибке у части клиентов.
3. Проверяйте фактические параметры. Настроенные версии и наборы могут не совпадать с согласованными.
4. Фиксируйте срок продления сертификата. Истёкший сертификат приводит к отказу подключения у всех клиентов.
5. Пересматривайте при изменении конфигурации сервера. Изменение перечня версий и наборов изменяет результат согласования.

Практический сценарий: часть клиентов не подключалась к сервису

Контекст: подключение к сервису завершалось ошибкой подтверждения сертификата у части клиентов, при этом остальные подключались успешно.

1. Диагностика. Проверка цепочки показала, что сервер передаёт конечный сертификат без промежуточного. Клиенты, имеющие промежуточный сертификат в собственном хранилище, подтверждали цепочку, остальные — отклоняли.
2. Причина. Промежуточный сертификат не был включён в передаваемую цепочку при установке. Часть клиентов получала промежуточный сертификат из собственного хранилища либо кэша, поэтому подтверждение выполнялось.
3. Действия. (а) Собрали полную цепочку, включающую промежуточный сертификат; (б) обновили конфигурацию сервера для передачи полной цепочки; (в) проверили подтверждение на клиенте без промежуточного сертификата в хранилище; (г) добавили проверку цепочки в процедуру установки сертификата; (д) зафиксировали контроль срока действия как регулярную проверку.
4. Результат. Все клиенты подтверждают цепочку, поскольку промежуточный сертификат передаётся сервером.

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

FAQ

Зачем указывать имя сервера при диагностике? Сертификат выбирается по имени, поэтому при размещении нескольких сертификатов на одном адресе без параметра возвращается иной сертификат.

Что сокращает время согласования? Возобновление сессии и повторное использование соединения. Полное согласование требует нескольких циклов обмена.

Почему часть клиентов отклоняет сертификат? Цепочка неполна либо срок действия истёк. Клиент без промежуточного сертификата в хранилище не может построить цепочку подтверждения.

Как проверить фактические параметры согласования? Утилитой подключения, которая показывает согласованную версию и шифронабор. Настроенные параметры могут не совпадать с фактическими.

Источники: openssl s_client, RFC 8446, Let's Encrypt docs — ссылки в шапке.