Может ли цепочка сертификатов сервера переопределить хранилище доверия клиента?

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

Проверка выполняется на клиенте, с якорями клиента

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

Итак, полная цепочка доказывает, что у сервера есть части. Она не доказывает, что клиент их примет.

Чтобы увидеть, что сервер действительно отправляет, выполните openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts и посчитайте сертификаты в выводе. Неполная цепочка там — это исправление на стороне сервера. Полная цепочка переносит вопрос к клиенту и его якорям, где у сервера нет голоса.

Что на самом деле меняет проверка TLS

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

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

Завершение VPN — это не расшифровка HTTPS

Уровень VPN переносит пакеты между клиентом и шлюзом. Его удаление или чтение его конфигурации не раскрывает HTTPS-нагрузку внутри.

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

Задайте ожидания в компоненте, который вы контролируете

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

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

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