tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: SSL issue in tomcat
Date Mon, 02 Feb 2015 15:17:44 GMT
Hash: SHA256


On 2/2/15 4:46 AM, Jason Y wrote:
> Thanks for your reply, Chris.
> I am providing solr search service on Linux server. My java version
> is 1.7_67(64bit) and tomcat version is 7.0.55 and tomcat Connector
> is: <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="500"
> SSLEnabled="true" scheme="https" secure="true" clientAuth="false"
> sslProtocol="TLS" keystoreFile="/path/**.keystore"
> keystorePass="password" /> In my service I provide both REST and
> WSDL servie to call solr search by https. Everything worked well
> until one day(about in Nov, 2014) we found we could not open wsdl
> URL in any browsers while our clients' codes that calls solr search
> are always working fine.
> In the coming days, two clients' developers(.NET) raised some
> tickets complaining that they could not call solr service on their
> local machines(while their code on PROD running well and never
> failed). They said they could not even load wsdl in Visual Studio.
> At this time I realized that I should test it by myself so I
> tested(with java code) to call the service both by REST and by
> WSDL, and both worked fine.
> *My code to call WSDL is:* 
> System.setProperty("", certificationPath); 
> XXXXService service = new XXXXService(); XXXX port =
> service.getXXXXPort(); // start add soap header Binding binding =
> ((BindingProvider) port).getBinding(); List<Handler> handlerList =
> binding.getHandlerChain(); if (handlerList == null) handlerList =
> new ArrayList<Handler>();
> handlerList.add(new SecurityHandler(username, password)); 
> binding.setHandlerChain(handlerList); String query =
> "q=Id:123456"; long offset = 0; long limit = 100; Holder<Long>
> numFound = new Holder<Long>(); Holder<Long> start = new
> Holder<Long>(); Holder<List<XXXXSolrDocument>> doc=new 
> Holder<List<XXXXSolrDocument>>();
> System.out.println(doc.value.size()); *My code to call REST service
> is:* SolrQuery query = new SolrQuery(); query.setQuery("*:*"); 
> System.setProperty("", certificationPath); 
> HttpSolrServer server = new HttpSolrServer(" 
> https://server_ip:8443/solr/solr_test"); 
> query.setHighlight(true).setStart(1); query.setRows(15); 
> ModifiableSolrParams paramsDemo = new ModifiableSolrParams(); 
> paramsDemo.add("wt", "json"); paramsDemo.add("indent", "true"); 
> paramsDemo.add("q", "Id:123456"); query.add(paramsDemo); 
> QueryResponse queryResponse = server.query(query);
> Then I tried to disable SSL 3.0 on server by adding ​ 
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" to the Connector in
> server.xml. After a restart, my service was running OK and my test
> code running OK and https wsdl URLs OK to open in browsers. But,
> about one hour later, all above test failed.
> *Error message when calling wsdl:* Exception in thread "main"
> Failed to access the WSDL at:
> https://server_ip:8443/solr_test_name?wsdl. It failed with: 
> Received fatal alert: handshake_failure. at 
> at com.xxxx.webservice.XXXXService.<init>( at
> com.xxxx.client.Test.main( Caused by:
> Received fatal alert: 
> handshake_failure
> *​Error message then calling REST:* ​IOException occured when
> talking to server at: [MY_REST_SERVICE_ADDRESS]
> *Error message when trying to open WSDL URL in browser:* SSL
> connection errorUnable to make a secure connection to the server.
> This may be a problem with the server, or it may be requiring a
> client authentication certificate that you don't have. Error code:
> ERR_SSL_PROTOCOL_ERROR ​My question is, after adding ​
> sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" to the *Connector *in
> server.xml, is there anything else that I need to do? Such as: i)
> on server side JDK settings with "-D xxxx=xxxx"; ii) on client side
> with System.setProperties("xxxx","xxxx")? iii) or anything else?

You should not have to do anything else.

The one thing I can think of is that some clients are trying to use an
SSLv2hello handshake and you are not supporting one. I would imagine
that most modern clients would try SSLv2hello and then switch to TLS
if that didn't work (or, better yet, the other way around). Your Java
1.7 client will certainly be able to connect to either. I'm not sure
about .NET clients, but they are probably smart, too.

I'd like to know what changes between when it works and when it
doesn't. What does a protocol trace look like? What happens if you run
my SSL/TLS-support tester against it (look in the recent list archives
for it). Is Tomcat still running? What does a Tomcat thread dump look

- -chris
Version: GnuPG v1
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message