There are 2 Websphere servers. First is Client and Second is Server (8.5.5.13).
An End-User makes a SOAP request to Client. Client receives the request, do some processing and then makes a REST request to the Server.
When the Server receives the request from Client it throws the below exception.
ERROR 22304 --- [ebContainer : 2]
c.i.w.s.c.impl.SSLHandshakeErrorTracker : SSLC0008E: Unable to
initialize SSL connection. Unauthorized access was denied or security
settings have expired. Exception is
javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1
not enabled or not supported
We have tested after enabling TLSv1.2 and then TLSv1 at the our Server level. We have exported the certificate from the Server and added in the Client trust store as well. But still we are not able to resolve the error.
Questions:
1. Do we need to keep the same TLS version at our Server which is present in the Client WebSphere?
2. We have deployed our application is java7. Is it due to Java version we are facing the issue?
3. Is it due to Certificate only, or something else?
When we disable the Global security at our Server then the request is processing correctly.
This error was due to the TLS version incompitability at Server. The client was sending the request using TLSv1 and server has TLSv1.2 enabled in it. For SSL handshake, the first thing is TLS compitability. The client and server should have same TLS versions.
After this if you are using one way SSL handshake, then the certificate from the server machine needs to extract and the same should be installed in the Client machine. This way SSL Handshake will happen.
Related
Neo4J server configuration allows to set up a server-side policy to secure both HTTPS and BOLT connections.
In my installation I secured the BOLT connection by setting up a policy with PEM public and private key and settings:
dbms.connector.bolt.enabled=true
dbms.connector.bolt.tls_level=REQUIRED
bolt.ssl_policy=my_policy
dbms.ssl.policy.my_policy..base_directory=...
...
The set up works with a browser client. When I connect to the server through HTTPS, I am able to log in using ":server connect" command and use Neo4J browser with my server.
What I cannot do is figure out how other client can connect to Neo4J with secure BOLT protocol. Specifically, I tried connecting from cypher-shell and from a Java client (using Java Driver v 1.6). When TLS for BOLT is disabled, both connect without a hitch. Enabling TLS causes bad_certificate error in both clients.
I tried starting both cypher-shell and my Java client by passing JVM properties pointing to my trust store and key store
(-Djavax.net.ssl.keyStore=...
-Djavax.net.ssl.keyStorePassword=...
-Djavax.net.ssl.trustStore=...
-Djavax.net.ssl.trustStorePassword=...)
These properties have no effect on either Neo4J client. I am getting a bad_certificate exception.
I tried enabling SSL debugging (-Djavax.net.debug=ssl,handshake). Calling the Java client or cypher-shell with keystore and truststore parameters has no effect on the SSL debug output.
How do I connect to the server with TLS for BOLT enabled from cypher-shell or a Java client?
Thank you.
I am trying to connect a java client with a JMX server using SSL certificate.
But unfortunately this connection gives a SSL Handshake error. When I tried to debug this, using -Djavax.net.debug=all flag, I get the following error message on the java client.
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], READ: TLSv1.2 Alert, length = 2
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], RECV TLSv1 ALERT: fatal, handshake_failure
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], called closeSocket()
2016-07-15T13:29:50.02-0700 [APP/0] OUT RMI RenewClean-[10.200.0.27:44445,javax.rmi.ssl.SslRMIClientSocketFactory#305a99f7], handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
When I change the client to something else, like a JConsole, the connection works fine using the same SSL certificate and the truststore, which indicates that there is nothing wrong with the SSL certificate or the domain its connecting to.
It seems that the handshake was failing due to incorrect TLS version types.
My client was running on Java7 which was using TLS version 1, while the server was running Java8 which was using TLS version 1.2.
Check this oracle blog, which mentions that Java8 will default use TLS version 1.2
So, when I upgraded my client to use Java8, the issue got resolved.
Hope, this helps someone else as well.
We have a process use HttpClient to make https connection with different URLs. Our JDK version is 1.7. We found some URLs, if we use default JSSE SIN extension flag, which is turn on, we got the following exception:
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
If we set -Djsse.enableSNIExtension=false, some other URLs throw this exception:
javax.net.ssl.SSLException: Received fatal alert: unrecognized_name
Does anybody have idea about this?
The SNI extension will add the server_name(hostname) in the client hello message at the SSL handshake stage.
It may be needed by a server that serves requests for different hostnames or virtual hosts. It is used to resolve the Certificate for the hostname the client intend to communicate with. The server may be configured with a default certificate if the host name is not added or not found. The default certificate may be a multisigned certificate for all the hosts it serves.
The first warning you get may be a server responding with a default certificate but that also warns that the hostname is not recognized. The server probably does not recognize the hostname simply because it is not included in the configuration. Instead of ignoring the warning and use the default certificate, Java seems to throw an exception.
In the other case where you disabled SNI, you do not include the hostname anymore and the request is sent to a server that does not have a default certificate. It will respond with a fatal error because it cannot resolve any certificate for you.
I had the following error when calling a service that requests at least TLS (no SSL3 for you Poodle!).
com.ibm.websphere.sca.ServiceUnavailableException: Could not obtain a connection to the destination or Exception was happened on the connection. Failed to process the request. Unsupported record version Unknown-0.0
at com.ibm.ws.http.imprt.handler.HTTPImportService.sendHTTPRequest(HTTPImportService.java:254)
at com.ibm.ws.http.imprt.handler.HTTPImportHandler.processMessage(HTTPImportHandler.java:261)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessageWithPCI(MessageDispatcherImpl.java:785)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:1626)
at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedMessageImpl.java:999)
at com.ibm.ws.sca.uow.handler.UOWNativeWASStrategyImpl.transactionImportExport(UOWNativeWASStrategyImpl.java:455)
at com.ibm.ws.sca.uow.handler.JoinUOWNativeHandler.processMessage(JoinUOWNativeHandler.java:168)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessageWithPCI(MessageDispatcherImpl.java:785)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:1626)
at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedMessageImpl.java:990)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.SCAInvocationAction.invokeSync(SCAInvocationAction.java:554)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.RetryControl.invokeByStyle(RetryControl.java:379)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.RetryControl.invokeWithRetry(RetryControl.java:253)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.ServiceInvocation.complete(ServiceInvocation.java:127)
at com.ibm.ws.sibx.mediation.flowaction.impl.sca.FlowActionFactoryImpl.create(FlowActionFactoryImpl.java:750)
at com.ibm.ws.sibx.mediation.primitives.serviceinvoke.ServiceInvokeMediation.invokeFlowAction(ServiceInvokeMediation.java:651)
at com.ibm.ws.sibx.mediation.primitives.serviceinvoke.ServiceInvokeMediation.mediate(ServiceInvokeMediation.java:564)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocation(JavaMediationPrimitive.java:741)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocationWithCatch(JavaMediationPrimitive.java:577)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.invoke(JavaMediationPrimitive.java:397)
at com.ibm.ws.sibx.scax.mediation.engine.SIBXJavaMediationPrimitive.invoke(SIBXJavaMediationPrimitive.java:108)
at com.ibm.ws.sibx.scax.mediation.engine.MediationPrimitive.invokeConnections(MediationPrimitive.java:344)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.fireOutputTerminals(JavaMediationPrimitive.java:843)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocation(JavaMediationPrimitive.java:763)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocationWithCatch(JavaMediationPrimitive.java:577)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.invoke(JavaMediationPrimitive.java:397)
at com.ibm.ws.sibx.scax.mediation.engine.MediationPrimitive.invokeConnections(MediationPrimitive.java:344)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.fireOutputTerminals(JavaMediationPrimitive.java:843)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocation(JavaMediationPrimitive.java:763)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.performInvocationWithCatch(JavaMediationPrimitive.java:577)
at com.ibm.ws.sibx.scax.mediation.engine.JavaMediationPrimitive.invoke(JavaMediationPrimitive.java:397)
at com.ibm.ws.sibx.scax.mediation.engine.MediationPrimitive.invokeConnections(MediationPrimitive.java:344)
at com.ibm.ws.sibx.scax.mediation.engine.Input.invoke(Input.java:245)
The config was Websphere 8.0.0.7 with Websphere Process Server 8.0.1.2 and I was calling to an HTTP service using an HTTP import through https, the WAS was already using a SSL configuration with TLS (tried several options, all same error) and the ssl.client.props file is already following the IBM recommendations (tried several combinations).
Then we moved to FIPS with transitional support but another issue appeared
com.ibm.websphere.sca.ServiceUnavailableException: Could not obtain a
connection to the destination or Exception was happened on the
connection. Failed to process the request. SSL protocol cannot be
enabled in FIPS/SP800_131/suiteb mode
at com.ibm.ws.http.imprt.handler.HTTPImportService.sendHTTPRequest(HTTPImportService.java:254)
at com.ibm.ws.http.imprt.handler.HTTPImportHandler.processMessage(HTTPImportHandler.java:261)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessageWithPCI(MessageDispatcherImpl.java:785)
at com.ibm.ws.sca.internal.message.impl.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:1626)
at com.ibm.ws.sca.internal.message.impl.ManagedMessageImpl.process(ManagedMessageImpl.java:999)
at com.ibm.ws.sca.uow.handler.UOWNativeWASStrategyImpl.transactionImportExport(UOWNativeWASStrategyImpl.java:455)
at com.ibm.ws.sca.uow.handler.JoinUOWNativeHandler.processMessage(JoinUOWNativeHandler.java:168)
The problem was within the HTTP import internal component (was using SSL as a hardcoded configuration) so I wrote my own HTTP client in a custom Java and called it a day. No fix pack at that moment.
I am using https to connect to an https server.
Specifically I am using apache httpclient and I configure the ssl context to use my keystore and truststore.
The https server I am using is IIS7 and is configured to require client authentication.
I think I have set it up properly.
Anyway, if I configure the httpClent's ssl context with a keystore (i.e. with client certificates) valid for IIS then there is no problem connecting.
Now my problem is the following:
If I do not configure the ssl context with any client certificate to send to IIS, there is no connection with the server. What makes me think though, is the fact that I was expecting to see some java exception in the code as a result of a hanshake failure alert.
Monitoring what is happening with wireshark, I could not see a certificate request from IIS to my application, but I noticed that after ServerHelloDone everything was encrypted.
I did not expect that. I think the handshake is usually in cleartext.
I used private key to decrypt traces and i saw a certificate request from IIS but after many starting and opening of new connections.
My app send back as a response a certificate of length 0 and IIS replies with a TLSv1 Finished.
After that the packets stop (i.e. seems that the communication ends).
I was expecting a handshake alert.
My question is, is this how it is supposed to work or at least how IIS works?
Or if I do not see the alert something is wrong with my use case?
Thanks
It sounds like IIS is only requiring client certificates for certain URLs (ie, for example.com/foo, but not example.com/bar).
In the initial handshake, it does not know which url you are requesting, so it does not require a certificate. When it sees that you are requesting a restricted resource (/foo), it then rehandshakes, requiring a certificate.
However, I would still expect a handshake_failure to occur.
As I was saying in an answer to this question, as far as I remember, IIS uses re-negotiation to get the client certificate. You should be able to change this behaviour using netsh and clientcertnegotiate=enable (depending on the version of IIS you're using).
You might also be interest in this similar question.
Failing to supply a certificate in response to a CertificateRequest isn't an SSL protocol error, so there is no handshake_error. 'Requiring' instead of just 'needing' client certificates is added-in by SSL libraries, and all they can do if you don't send one is just close the connection.