#Что происходит и когда применима инструкция
Сайт открывается по HTTPS в обычном браузере, но мобильное приложение завершает подключение ошибкой TLS или сообщает о недоверенном сертификате. Браузер и приложение могут использовать разные хранилища доверия, TLS-библиотеки, закрепление сертификата и сетевые настройки.
#Основные причины и их признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Устаревшая система доверенных корнейВерсии ОС могут различаться по поддержке корневых УЦ и TLS. | Старый Android/iOS не распознаёт цепочку, новый браузер работает | Проверьте версию системы и полную цепочку. |
| Закрепление ключа в приложенииПриложение может сверять заранее закреплённый открытый ключ/хеш. | Ошибка началась сразу после плановой ротации сертификата | Проверьте конфигурацию certificate pinning у разработчика. |
| Приложение использует другой хост APIПриложение часто обращается к отдельному поддомену либо к устаревшему адресу. | Сайт доступен, вызовы API отвечают ошибкой SSL | Определите реальный API-хост и его сертификат. |
#Пошаговая диагностика и устранение
- Соберите воспроизводимый случайЗапишите версию приложения, модель устройства, Android/iOS, точный текст ошибки, время и работает ли через Wi-Fi и мобильную сеть. Не просите пользователей присылать логины и снимать проверку сертификата на телефоне.
- Установите фактический адрес подключенияУ разработчика или в собственной конфигурации найдите API base URL. Если веб-сайт работает на
www, а приложение обращается кapi, это два различных TLS-имени. Проверьте, не остался ли в приложении адрес от предыдущего сервера.
- Проверьте API-хост с правильным именемНа внешней машине выполните диагностику именно того имени, куда обращается мобильное приложение. Проверьте SAN, цепочку и срок: браузер, открывающий другой хост, не подтверждает корректность API.
- Терминал с OpenSSL, заменить имя APILinux · Терминал (Bash)КомандаТерминал с OpenSSL, заменить имя API. Проверка по SAN выполняется отдельно либо параметром
-verify_hostnameв совместимой версии.openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts -verify_return_error </dev/null
- Сравните устройства на поддерживаемых ОСПопробуйте ту же версию приложения на другом устройстве и актуальной ОС в контролируемой среде. Если сбой только на старой ОС, изучите поддержку TLS и доверенных корней у производителя приложения, а не ослабляйте веб-сервер сразу для всех.
- Проверьте корпоративный прокси и VPNЕсли ошибка появляется только в определённой сети, выясните, не вмешивается ли система HTTPS-инспекции или VPN. Не предлагайте устанавливать неизвестный корневой сертификат. Для корпоративных устройств используйте официальную политику администратора.
- Проверьте закрепление сертификата безопасноЕсли разработчик использует certificate pinning, сравните план обновления ключей с датой замены сертификата. Подготовьте новое приложение с допустимыми резервными ключами и безопасным сроком перехода. Не отключайте проверку TLS в продакшене, чтобы убрать сообщение.
- Исправьте цепочку или конфигурацию клиентаЕсли сервер отдаёт неполный intermediate — установите правильную полную цепочку; если приложение зовёт старый API-хост — обновите его конфигурацию. Для старой ОС используйте предусмотренное обновление приложения или явно объявленную минимальную поддерживаемую версию.
- Проверьте не только главную страницуНа двух мобильных системах выполните тестовый вход, чтение данных и безопасный запрос записи. Убедитесь, что все нужные поддомены проходят TLS, конфиденциальные данные не логируются и нет отката на HTTP.
#Проверка результата
Проблемные поддерживаемые устройства подключаются к правильному API-хосту через валидный TLS, предупреждения исчезли, операции приложения работают без снижения требований проверки сертификата.
#Если решить проблему не удалось
Если сертификаты и API-хост верны, запросите у разработчика обезличенную ошибку TLS-библиотеки, версию SDK и сведения о pinning. Не диагностируйте проблему исключительно на браузере.