Возможно, вам не хватает промежуточного сертификата CA на стороне вашего сервера.
Попробуйте прочитать это
Большинство общедоступных центров сертификации не подписывают сертификаты серверов напрямую. Вместо этого они используют свой основной сертификат ЦС, называемый корневым ЦС, для подписи промежуточных ЦС. Они делают это, чтобы корневой ЦС можно было хранить в автономном режиме, чтобы снизить риск компрометации. Однако операционные системы, такие как Android, обычно напрямую доверяют только корневым центрам сертификации, что оставляет небольшой разрыв в доверии между сертификатом сервера, подписанным промежуточным центром сертификации, и верификатором сертификата, который знает корневой центр сертификации. Чтобы решить эту проблему, сервер отправляет клиенту не только свой сертификат во время рукопожатия SSL, а цепочку сертификатов от ЦС сервера через любые промежуточные звенья, необходимые для достижения доверенного корневого ЦС.
Чтобы увидеть, как это выглядит на практике, вот цепочка сертификатов mail.google.com, просмотренная командой openssl s_client:
$ openssl s_client -подключить mail.google.com:443
Цепочка сертификатов 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN= Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Первичный общедоступный центр сертификации класса 3
Это показывает, что сервер отправляет сертификат для mail.google.com, выданный ЦС Thawte SGC, который является промежуточным ЦС, и второй сертификат для ЦС Thawte SGC, выданный ЦС Verisign, который является основным ЦС, которому доверяют Андроид.
Однако нередко настроить сервер так, чтобы он не включал необходимый промежуточный ЦС. Например, вот сервер, который может вызывать ошибку в браузерах Android и исключения в приложениях Android:
$ openssl s_client -connect egov.uscis.gov:443
Цепочка сертификатов 0 s:/C=US/ST=Округ Колумбия/L=Вашингтон/O=U.S. Министерство внутренней безопасности/OU=Служба гражданства и иммиграции США/OU=Условия использования на сайте www.verisign.com/rpa (c)05/CN=egov.uscis.gov
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Условия использования на https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA — G3
Интересно отметить, что посещение этого сервера в большинстве настольных браузеров не приводит к ошибке, которую может вызвать полностью неизвестный ЦС или самозаверяющий сертификат сервера. Это связано с тем, что большинство настольных браузеров со временем кэшируют доверенные промежуточные центры сертификации. После того как браузер посетил и узнал о промежуточном ЦС с одного сайта, ему не нужно будет включать промежуточный ЦС в цепочку сертификатов в следующий раз.
Некоторые сайты делают это намеренно для вторичных веб-серверов, используемых для обслуживания ресурсов. Например, их основная HTML-страница может обслуживаться сервером с полной цепочкой сертификатов, но серверы для ресурсов, таких как изображения, CSS или JavaScript, не включают ЦС, предположительно для экономии полосы пропускания. К сожалению, иногда эти серверы могут предоставлять веб-службу, которую вы пытаетесь вызвать из своего приложения для Android, что не так щадяще.
Существует два подхода к решению этой проблемы:
Настройте сервер для включения промежуточного ЦС в цепочку серверов. Большинство ЦС предоставляют документацию о том, как это сделать для всех распространенных веб-серверов. Это единственный подход, если вам нужно, чтобы сайт работал с браузерами Android по умолчанию хотя бы через Android 4.2. Или относитесь к промежуточному ЦС как к любому другому неизвестному ЦС и создайте TrustManager, чтобы доверять ему напрямую, как это было сделано в предыдущих двух разделах.
person
Suhail Mehta
schedule
26.11.2014