Длина цепи сертификата не действительна

Question

У нас странная ситуация. При настройке соединения наше приложение выполняет кучу проверок безопасности. Один из них - проверить правильность длины цепи. Мы знаем, что это должно быть 3: Корень, промежуточный и сервер.

Когда мы подключаемся к серверу с помощью приложения для Android, мы получаем в качестве ответа только два промежуточных сертификата и сервера - без root. Но когда мы проводим проверку веб-браузера, мы придумали исследование на Android 5.0, которое мы видим 3, а на Android 4.3 мы видим два из них. Форма подключения iOS дает 3 сертификата.

Это сервер или Android? Что мы можем сделать, чтобы получить также корневой сертификат?

EDIT: Мы загружаем сертификаты (root и intermediate) из браузера и создаем хранилище ключей из них и помещаем его в активы приложения. Затем в нашем CustomTrustManager мы сравниваем сертификаты из хранилища ключей с сертификатами, которые поступают с подключаемого нами сервера.

В основном наше сравнение основано на сертификатах отпечатков пальцев. Проблема в том, что корневой сертификат не поступает с сервера, и нет возможности его сравнить.

Но мы вышли с идеей.

Мы можем сравнить, что промежуточный ceritifcate, который пришел с сервера, подписан корневым сертификатом, который кодируется в приложении.

Я думаю, что это достаточно безопасно.

И мы будем сравнивать только промежуточные отпечатки пальцев.

Answer 1

Я не имею ни малейшего представления о том, как вы делаете проверку точно, но в целом:

• Сервер должен отправлен сертификат серверов и все промежуточные сертификаты, ведущие от сертификата сервера к встроенному в корневой CA. Если отсутствуют сертификаты цепей, некоторые браузеры (например, Chrome на рабочем столе) пытаются заполнить отсутствующие сертификаты, в то время как другие (как и большинство приложений, которые не являются браузерами) завершают проверку, поскольку цепочка доверия не может быть создана.
• Сервер не должен отправлять корневой ЦС самостоятельно, но некоторые серверы все равно. В этом случае корневой ЦС, отправленный сервером, будет проигнорирован.
• В зависимости от корневого центра сертификации, хранящегося в браузере/системе, может быть другой путь доверия, который также обычно имеет разную длину. Это особенно верно, когда речь идет о кросс-подписи, что обычно происходит при введении нового корневого-CA. Поскольку они изначально не находятся в хранилище САПР браузера/системы, они подписываются другим ЦС, который находится в хранилище доверия, но позже новый корневой-CA находится в хранилище доверия, поэтому цепочка короче. Этот процесс также используется в настоящее время для замены различных корневых-CA, которые использовали 1024-битный RSA с корневым CA с использованием более сильных клавиш (то есть 4096 бит).

Это означает, что длина цепи вы видите, зависит от многих факторов:

• Как вы смотрите: вы смотрите на цепи, отправленного сервером или цепи, построенной системой? Последний будет содержать root-CA, в то время как первый не должен, но может.
• Какие корневые ЦС существуют в системе: более старые системы могут создавать более длинные цепочки, потому что новый корневой-CA или еще нет в системе.