but my problem is, this callback function is being executed after execution of “SSL_accept” function, but I have to choose and use the appropriate certificate before using “SSL_new” command, which is way before execution of SSL_accept. When you start your server, you provide a default SSL_CTX. This is used for non-SNI clients, like SSLv3 clients … Read more
This answer comes late, but we just have hit the problem (I can’t believe it, it seems a very big bug). All what it said seems true, but it’s not default HostnameVerifier the culprit but the troubleshooter. When HttpsClient do afterConnect first try to establish setHost (only when socket is SSLSocketImpl): SSLSocketFactory factory = sslSocketFactory; … Read more
As mentioned, the cause is related to the JDK bug where using setHostnameVerifier() breaks SNI (Extension server_name). https://bugs.openjdk.java.net/browse/JDK-8144566 Our workaround: After testing we found that setting a connection’s SSLSocketFactory to just about anything from the default seems to fix the issue. This does not work: HttpsURLConnection.setSSLSocketFactory((SSLSocketFactory) SSLSocketFactory.getDefault()); This does work: HttpsURLConnection.setSSLSocketFactory(new SSLSocketFactoryFacade()); So, to fix … Read more
As far as I know, there is a partial support in Android SDK. The current situation is the following: Since the Gingerbread release TLS connection with the HttpsURLConnection API supports SNI. Apache HTTP client library shipped with Android does not support SNI The Android web browser does not support SNI neither (since using the Apache … Read more
On the client side, you use SSL_set_tlsext_host_name(ssl, servername) before initiating the SSL connection. On the server side, it’s a little more complicated: Set up an additional SSL_CTX() for each different certificate; Add a servername callback to each SSL_CTX() using SSL_CTX_set_tlsext_servername_callback(); In the callback, retrieve the client-supplied servername with SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name). Figure out the right SSL_CTX … Read more
The current version of Requests should be just fine with SNI. Further down the GitHub issue you can see the requirements: pyOpenSSL ndg-httpsclient pyasn1 Try installing those packages and then give it another shot. EDIT: As of Requests v2.12.1, ndg-httpsclient and pyasn1 are no longer required. The full list of required packages is now: pyOpenSSL … Read more