Браузер успешно открывает API, но мобильный клиент перестал подключаться сразу после плановой замены сертификата сервера. Как локализовать причину на стороне клиента?
Проверьте, выполняет ли мобильный клиент дополнительную проверку закреплённого сертификата или публичного ключа. Для этого замените сертификат на другой, выданный доверенным центром сертификации, сохранив домен и корректную цепочку доверия: браузер должен продолжить подключение, а приложение при несовпадении закреплённого значения — отклонить TLS-соединение.
Это отличает проблему certificate pinning от ошибки цепочки сертификатов, доменного имени, срока действия или системного времени.
Обычный HTTPS доверяет сертификату, если его цепочка ведёт к доверенному центру сертификации, установленному в системе. Такой подход удобен, но компрометация центра сертификации или ошибочная выдача сертификата могут позволить принять чужой сертификат.
Certificate pinning появился как дополнительное ограничение: приложение ожидает конкретный сертификат или публичный ключ сервера, а не любой сертификат, формально доверенный системой. Цена этой защиты — необходимость заранее учитывать замену сертификатов и ключей.
После ротации сертификата сервер может быть полностью исправен: домен совпадает, срок действия корректен, цепочка полная, браузер подключается. Однако клиент с закреплённым сертификатом продолжит считать новый сертификат недоверенным.
Неверная диагностика приводит к попыткам менять серверную конфигурацию, отключать проверку TLS или ослаблять безопасность клиента. Если же тестировщик ошибочно примет обычную ошибку доверия за pinning, можно пропустить проблему с неполной цепочкой, неверным доменом или устаревшим системным временем.
Сначала зафиксируйте базовые условия: один домен, одинаковая сеть, новый сертификат с корректным именем сервера, действующим сроком и полной цепочкой доверия. Убедитесь, что соединение через браузер действительно проходит именно к нужному окружению, а не через другой прокси или кэшированный маршрут.
Затем используйте контролируемый сертификат, который валиден для домена и доверен системой, но имеет другой сертификат или публичный ключ. Если браузер продолжает работу, а приложение получает ошибку проверки доверия, это сильный признак дополнительной проверки в клиенте.
Подтверждение ищут в диагностических логах тестовой сборки или сетевого слоя: характерным результатом будет несовпадение закреплённого сертификата либо ключа. Отключать pinning следует только в специально подготовленной тестовой сборке; изменение production-поведения ради диагностики создаёт риск ложного результата.
Важно отличать два варианта закрепления. При закреплении сертификата замена самого сертификата обычно ломает соединение, даже если ключ остался прежним. При закреплении публичного ключа сертификат можно заменить без ошибки, пока сохраняется тот же ключ.
У pinning есть компромисс: он снижает зависимость от общей системы доверия, но усложняет ротацию. Надёжная стратегия обычно предусматривает заранее добавленный резервный ключ или согласованный процесс выпуска новой версии клиента; конкретный вариант зависит от реализации и требований безопасности.
Перед релизом сервер заменил сертификат. Браузер и диагностический HTTP-клиент продолжили работать, но мобильное приложение стало получать обобщённую TLS-ошибку.
Рассматривались три варианта. Проверка цепочки сертификатов могла выявить неполную цепочку, но не объясняла бы корректную работу клиента с браузером без различий в маршруте. Перехват трафика через корпоративный прокси позволял сравнить маршруты, но сам прокси мог дополнительно изменять сертификат. Наконец, установка другого валидного сертификата на тестовом домене позволяла изолировать именно реакцию приложения на смену сертификата.
Выбрали третий вариант: сохранили домен и корректную цепочку, но использовали другую ключевую пару. Браузер подключился, а приложение отклонило соединение; журнал тестовой сборки указал на несовпадение закреплённого ключа. Причина была подтверждена как pinning, после чего в клиент заранее добавили резервное значение для плановой ротации.
Нет. Браузер и приложение могут использовать разные прокси, DNS-маршруты, хранилища доверенных сертификатов и настройки TLS. Такой результат только показывает, что один конкретный клиент принимает соединение; нужно сравнить домен, IP, цепочку, время на устройстве и фактический маршрут приложения.
Нет, сама по себе не доказывает. Ту же картину могут вызвать неправильное имя в сертификате, просроченный сертификат, неполная цепочка, недоступный центр сертификации, неверные дата и время устройства или различие окружений. Доказательным становится контролируемый эксперимент: новый сертификат валиден по системным правилам, браузер его принимает, а приложение отклоняет именно из-за дополнительного закреплённого значения.
Закрепление может относиться не к самому сертификату, а к публичному ключу, поэтому результат зависит от того, была ли сохранена ключевая пара. Кроме того, приложение может содержать несколько закреплённых значений для разных окружений, использовать промежуточный сертификат или иметь устаревшую конфигурацию после обновления.
При расследовании нужно определить тип закрепления и проверить полный сценарий ротации: старый сертификат, новый сертификат с прежним ключом, новый сертификат с новым ключом и наличие резервного значения. Иначе команда может либо необоснованно отключить защиту, либо выпустить клиент, который перестанет работать при следующей штатной замене сертификата.