Summary

  • Проект HTTP-группы о дополнительных сертификатах сервера, редакция 03 обновлен 2 ноября 2026 года и остается Internet-Draft. Он предлагает кадр SERVER_CERTIFICATE, которым сервер HTTP/2 или HTTP/3 после установления TLS доказывает владение ключом сертификата еще одного сайта.
  • Обе стороны заранее объявляют поддержку. Экспортируемый аутентификатор из RFC 9261 связывает доказательство с существующей TLS-сессией; клиент отдельно решает, подходит ли сертификат и этот сервер для второго источника.
  • В разделе 7.3 описан риск переезда: новый CNAME направляет новые соединения к преемнику, но прежний провайдер может продолжать предъявлять дополнительный сертификат ушедшего сайта на соединениях для других сайтов. Провайдеру и клиенту придется закрывать этот остаточный путь самим.

Представим издателя, который меняет хостинг. После смены CNAME новые соединения достигают нового провайдера. В браузере читателя, однако, остается соединение HTTP/2 с другим сайтом прежнего хостера. У хостера сохранился сертификат издателя, и он посылает подтверждение владения ключом по существующему соединению. Если браузер сочтет этого достаточно для обслуживания переехавшего сайта, последующий запрос может вернуться на старый маршрут. Это мысленная проверка механизма из проекта.

Польза для сети понятна. HTTP/2 и HTTP/3 позволяют использовать одно соединение для нескольких источников, когда сервер полномочен обслуживать каждый. Сертификат в начальном рукопожатии TLS может охватывать несколько имен. Но хостеру удобнее хранить для клиентов отдельные сертификаты с независимым продлением и отзывом. Проект сохраняет раздельное управление ключами и общий транспорт. За сэкономленное соединение приходится ответить на вопрос: кто сегодня уполномочен обслуживать второе имя?

У соединения появляется вторая личность

Сначала обе стороны явно договариваются. Клиент и сервер посылают SETTINGS_HTTP_SERVER_CERT_AUTH со значением 1; без обоих сообщений использовать дополнительный сертификат нельзя. Затем сервер может в любой момент отправить SERVER_CERTIFICATE: в потоке 0 для HTTP/2 или в управляющем потоке HTTP/3. Кадр содержит экспортируемый аутентификатор — доказательство владения закрытым ключом дополнительного сертификата именно в данной TLS-сессии. Копия файла сертификата сама по себе такого доказательства не дает.

Клиент проверяет аутентификатор, затем пригодность сертификата для нужного источника. Разные неудачи имеют разные последствия. Неверный аутентификатор — ошибка соединения. Истекший, отозванный или неподходящий сертификат — отклоненная учетная запись; проект советует открыть новое соединение с полномочным сервером. Общее соединение может работать исправно, пока второй сайт не допускается. Метрика успешного TLS-соединения не покажет этот разрыв.

Раздел безопасности описывает более острый риск. Если злоумышленник получил дополнительный сертификат и ключ, ему достаточно привести клиента на любой HTTPS-сайт под своим контролем, чтобы предъявить там украденное подтверждение для другого источника. Проект рекомендует проверять DNS для второго имени, когда клиент проверил бы его при исходном TLS-рукопожатии. Если DNS не используется, другое свидетельство полномочий, например кадр ORIGIN, может укрепить решение. Владение ключом и текущий путь доставки — разные обстоятельства.

DNS уехал, соединение осталось

Для раздела 7.3 кража ключа не нужна. Владелец меняет CNAME, новые подключения идут к следующему провайдеру. Предыдущий по-прежнему принимает соединения для других клиентов и может сохранить в конфигурации сертификат ушедшего сайта. На этих общих соединениях он продолжает заявлять полномочие на сайт. Проект признает такое поведение соответствующим настройкам прежнего провайдера, хотя оно, вероятно, противоречит намерению владельца. В предлагаемом протоколе нет встроенной команды, прекращающей эту инерцию; провайдерам советуют заранее объяснять ее заказчикам.

Переезд требует цепочки доказательств. У кого остался закрытый ключ? Какие серверы еще отправляют дополнительный сертификат? Когда запись удалена из конфигурации и когда сертификат отозван? Проверяет ли клиент полномочия второго источника заново? Новый ответ DNS показывает направление новых соединений, но не запросы в уже открытом канале. Перечень старых соединений без трассы запросов тоже не дает полного ответа. Эти записи нужно сопоставлять.

Проект запрещает считать ранее предъявленный дополнительный сертификат проверенным после возобновления TLS-сессии. Сервер вправе предложить его снова, а клиент принимает новое решение. Пока обрабатывается запрос, набор принятых сертификатов может измениться; клиент должен переоценивать право обслуживать источник. Экономия соединений переносит нагрузку на управление подвижным состоянием доверия.

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

Проект HTTP · RFC 9261 · RFC 9113 · RFC 9114 · RFC 8336