使用自定义CA时，API 17(JELLY_BEAN)中的SSLHandshakeException [英] SSLHandshakeException in API 17 (JELLY_BEAN) when using custom CA
问题描述
我需要使用 TLS_v1 连接到我的服务器API，该证书是由CA签名的服务器证书，不包含在旧版android中，因此我使用此
中级和根TurkTrust CA(如上所示)已添加到我的 TrustManager 中.
可能的解释是服务器需要服务器名称指示(SNI)可发送回正确的证书，并且如果不使用SNI，则仅发送一些默认证书.因此，客户端将无法获得预期的证书，并且验证将失败.
根据文档OkHTTP应该支持SNI，但是最新的报告表示相反.在变更日志中，我看不到它的添加时间.支持可能还取决于基础库.
基于SSLLabs的报告，该报告已添加到问题中，现在可以清楚地知道问题出在服务器上，缺少中间证书.在报告中显示为
链问题:不完整，额外下载，.... 在这种情况下，如果客户端显式添加了根CA(TürktrustElektronik Sertifika ...)，这将无济于事，因为由于缺少中间CA(TürktrustSSL Sertifikasi Hizmitleri)，因此无法从叶中建立信任链.站点证书到根证书.从报告中还可以看出，服务器不仅无法包括链证书，而且服务器还添加了一些根本不属于链的证书.因此，我的猜测是试图包括一个链式证书，但是使用了错误的证书，并且在错误的位置(根之后，而不是领先证书之后)使用了错误的证书.
尽管某些台式机浏览器可以解决此问题，但大多数移动浏览器无法解决服务器端配置错误，而且python，PHP，Java等的SSL API也会失败.因此，这是一个问题，需要在服务器上解决.
I need connect to my server API with TLS_v1, server certificate signed by CA that not include in older version of android so i use this Google's document to implement custom TrustManager. Everything work on API 18 and above, but throw SSLHandshakeException in JELLY_BEAN(API 17):
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
I have another server URL and certificate (in this case self-signed) that works even in JELLY_BEAN with same TrustManager implementation !!
I'm using OkHttp 2.4 for HTTPS client. I'm confusing what's goes wrong ?
Updated: this is result of SSLLabs :
intermediate and root TurkTrust CA (shown in above) was added to my TrustManager.
A possible explanation is that the server requires Server Name Indication (SNI) to send the proper certificate back and sends only some default certificate if SNI is not used. Thus the client would not get the expected certificate and the validation would fail.
According to the documentation OkHTTP should support SNI, but a recent report indicates otherwise. In the Changelog I cannot see when it was added. It might also be that support depends on the underlying libraries.
EDIT: based on the report from SSLLabs which was added to the question it is now clear that the problem is a missing intermediate certificate at the server. This is shown in the report by
Chain Issues: Incomplete, Extra Download, ....
In this case it will not help if the client has explicitly added the root CA (Türktrust Elektronik Sertifika...), because due to the missing intermediate CA (Türktrust SSL Sertifikasi Hizmitleri) no trust chain can be build from the leaf certificate of the site to the root certificate. From the report can also be seen that the server not only fails to include the chain certificate but that the server also adds some certificate which does not belong to the chain at all. Thus my guess is that there was an attempt to include a chain certificate but the wrong one was used and apart from that at the wrong place (after the root instead of after the lead certificate).
While some desktop browsers work around such problem most mobile browsers will not work around this server side misconfiguration and also the SSL apis for python, PHP, Java,... will also fail. Therefore this is a problem which need to be fixed at the server.
这篇关于使用自定义CA时，API 17(JELLY_BEAN)中的SSLHandshakeException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
