Сервис отвечает на Android, но на iOS запрос завершается сетевой ошибкой. Как проверить, что причина — неполная цепочка TLS-сертификатов?
Нужно проверить TLS-цепочку, которую сервер отдаёт клиенту: она должна содержать сертификат сервера и необходимые промежуточные сертификаты до доверенного корневого центра. Диагностику следует повторить на чистых устройствах с одинаковым адресом сервиса, изучить ошибку TLS на клиенте и сопоставить результат с проверкой цепочки на сервере. Если после настройки полной цепочки запрос начинает проходить на iOS без изменения приложения, причина подтверждена.
TLS использует цепочку доверия: сертификат сервера подписан промежуточным центром сертификации, а тот связан с доверенным корневым центром. Такой подход позволяет клиенту проверить не только имя сервера, но и право центра сертификации выпускать соответствующие сертификаты.
Сервер обычно обязан передавать клиенту конечный сертификат и промежуточные сертификаты. Корневой сертификат, как правило, уже находится в системном хранилище доверия устройства. Проблема неполной цепочки стала особенно заметной на мобильных устройствах, потому что разные ОС, версии и сетевые стеки могут по-разному пытаться достроить отсутствующий промежуточный сертификат.
Один и тот же сервис может открываться в браузере, но не работать в мобильном приложении. Браузер иногда уже имеет нужный промежуточный сертификат в кэше или использует собственные механизмы построения цепочки, тогда как сетевой стек приложения не может получить недостающий элемент.
Неверный вывод о недоступности API приводит к лишним изменениям клиента: отключению проверки сертификатов, добавлению исключений безопасности или переходу на небезопасный протокол. Это маскирует дефект конфигурации сервера и создаёт риск атаки типа «человек посередине».
Сначала нужно зафиксировать условия: один и тот же URL, DNS-результат, время проверки, тип сети и версию приложения. Проверку выполняют минимум на проблемной версии iOS, на актуальной iOS и на Android, желательно на чистых физических устройствах без установленных пользовательских сертификатов.
Затем анализируют TLS-сеанс. Важно установить, завершилось ли соединение до отправки HTTP-запроса. Если HTTP-ответа нет, а клиент сообщает ошибку проверки сертификата, проблему следует искать в имени хоста, сроке действия, назначении сертификата, доверии к центру сертификации или полноте цепочки.
На стороне сервера проверяют состав отправляемой цепочки, порядок сертификатов, сроки действия и соответствие имени хоста. Отдельно проверяют, что сервер не отправляет только конечный сертификат и не полагается на загрузку промежуточного сертификата самим клиентом.
Для подтверждения гипотезы сервер временно или штатно настраивают на передачу полной корректной цепочки, после чего повторяют тесты на тех же устройствах. Нельзя считать доказательством простое отключение проверки TLS в приложении: оно устраняет симптом ценой потери защиты и не показывает, какой именно элемент цепочки был некорректен.
Следует учитывать и другие причины похожей ошибки: неверное имя хоста, просроченный сертификат, неподдерживаемый алгоритм, неправильные дата и время на устройстве, корпоративный прокси с подменой сертификатов. Поэтому проверка цепочки должна быть частью дифференциальной диагностики, а не единственным тестом по факту различия между iOS и Android.
После выпуска новой версии сертификата API перестал открываться на части iPhone, хотя Android-клиенты и браузеры продолжили работать. Команда рассмотрела несколько вариантов.
Первый вариант — добавить исключение для домена в мобильный клиент. Он быстро устраняет ошибку, но снижает уровень защиты и создаёт постоянный долг безопасности. Второй — установить промежуточный сертификат на устройствах. Такой подход непрактичен для массовых пользователей, плохо управляется и не исправляет серверную конфигурацию.
Третий вариант — заменить библиотеку сетевого доступа. Он может изменить диагностические сообщения, но не решает проблему, если сервер по-прежнему отдаёт неполную цепочку. Выбрали исправление конфигурации TLS на сервере: конечный сертификат стал передаваться вместе с актуальным промежуточным сертификатом.
После исправления проверили чистые устройства с поддерживаемыми версиями iOS и Android, несколько операторских сетей, Wi-Fi с корпоративным прокси и повторные установки приложения. Запросы стали проходить без отключения проверки сертификатов, а первоначальная гипотеза о неполной цепочке получила подтверждение.
Браузер и приложение могут использовать разные сетевые стеки, хранилища и механизмы построения цепочки. Браузер мог ранее получить промежуточный сертификат или загрузить его самостоятельно, тогда как приложение выполняет проверку только по данным TLS-сеанса и системному хранилищу. Поэтому успешное открытие сайта в браузере не доказывает корректность цепочки для приложения.
Нет. Внешняя проверка полезна, но она может выполняться из другой сети, с другой версией TLS-стека и иным набором доверенных центров. Нужно дополнить её тестом реального мобильного приложения на целевых версиях ОС, включая проблемное устройство и сеть, где воспроизводится ошибка.
Для обычных пользователей — нет. Пользовательский корневой сертификат меняет модель доверия конкретного устройства и не устраняет неполную цепочку для всей аудитории. Такой сценарий допустим только как контролируемый диагностический тест или в специально управляемой корпоративной инфраструктуре, где доверие намеренно администрируется. В публичном приложении правильным решением остаётся корректная серверная цепочка и сохранение стандартной проверки TLS.