I'm trying web sevice security with Java and Glassfish 3.1: I configured an Hello World web service to run on https listener of Glassfish (on port 8181) by setting "Transport Guarantee" of endpoint of web service to CONFIDENTIAL.
After this I edited web service Attributes and I enabled Secure Service with Transport Security (SSL) Mechanism. I'm using a trusted certificate signed by Comodo.
In web service client creation I have no errors, but when I launch my test application, I get this error:
%% Cached client session: [Session-1, TLS_DHE_RSA_WITH_AES_128_CBC_SHA]
main, WRITE: TLSv1 Application Data, length = 320
main, WRITE: TLSv1 Application Data, length = 32
main, WRITE: TLSv1 Application Data, length = 1328
main, READ: TLSv1 Application Data, length = 768
main, READ: TLSv1 Application Data, length = 32
main, READ: TLSv1 Application Data, length = 320
main, READ: TLSv1 Application Data, length = 32
main, READ: TLSv1 Application Data, length = 32
main, called close()
main, called closeInternal(true)
main, SEND TLSv1 ALERT: warning, description = close_notify
main, WRITE: TLSv1 Alert, length = 32
main, called closeSocket(selfInitiated)
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Invalid Security Header
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:189)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy43.helloWorld(Unknown Source)
at wss_test.WSS_Test.helloWorld(WSS_Test.java:31)
at wss_test.WSS_Test.main(WSS_Test.java:19)
Java Result: 1
I tried to manage urls and certificate but the result doesn't change. Which is my error? How can I resolve my issue?
Thanks in advance.
Mephysto
Related
I cannot determine how my TLS version is being overwritten running Java 8 on an AIX machine. Have tried every parameter on the on the command to force it to TLSv1.2.
Every time I execute and look at the "debug" output I get the same ...
*** ClientHello, TLSv1; main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1.2 ALERT: fatal, protocol_version.
I added TLSv1 to the "java_security" file - received a "no protocol available error".
Any suggestions would be greatly appreciated.
I have a problem connecting from my .Net client to Java server, both were changed from TLS1 to TLS1.2.
Both client and server in the same machine, Windows10 64bits.
.Net client created under .Net Framework 4.5, using HttpWebRequest.
Previous the request call I set
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
.Net Error "The request was aborted: Could not create SSL/TLS secure channel."
Java using jdk1.8.0_25
Java Error log:
P-86, received EOFException: error
P-86, handling exception: javax.net.ssl.SSLHandshakeException: Remote host
closed connection during handshake
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA256]
P-86, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
P-86, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 02 28 ......(
P-86, called closeSocket()
P-86, called close()
P-86, called closeInternal(true)
I have changed to different ciphers with no success. Any suggestion to follow ?
thanks
My problem was the certificate.I was using a very old one, I changed it and It works. I'm not clear why, I'm investigating.
Thanks to all.
On server I've got a certificate which I am using to connect to other webservice.
Certificate is correctly installed on server, because when I am using curl to make a request, everything works fine. The problem is when I am using rest request through my webservice in Spring.
I've got exception:
handling exception: javax.net.ssl.SSLHandshakeException:
I was trying changing tls protocols and it didn't help.
What may cause the problem?
There is a code of a debugger:
https-jsse-nio-8080-exec-4, WRITE: TLSv1 Handshake, length = 120
https-jsse-nio-8080-exec-4, received EOFException: error
https-jsse-nio-8080-exec-4, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
https-jsse-nio-8080-exec-4, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
https-jsse-nio-8080-exec-4, WRITE: TLSv1.2 Alert, length = 2
https-jsse-nio-8080-exec-4, called closeSocket()
https-jsse-nio-8080-exec-4, called close()
https-jsse-nio-8080-exec-4, called closeInternal(true)
I have a CXF web services server running with embedded jetty.
A client connects and send several successful requests to the server.
After 5-10 seconds suddenly the client hangs.
The client / server reuse the same connection for all requests.
After running the server with -Djavax.net.debug=all I've noticed the following message before the connection hangs.
Keep-Alive-Timer, called close()
Keep-Alive-Timer, called closeInternal(true)
Keep-Alive-Timer, SEND TLSv1 ALERT: warning, description = close_notify
Keep-Alive-Timer, WRITE: TLSv1 Alert, length = 22
Any idea what should be fixed to disable this Keep-Alive-Timer to close the connection?
After upgrading to cxf 3.1.0 the problem disappeared.
I'm using:
not-yet-commons-ssl-0.3.9.jar
opensaml-2.3.1.jar
I'm getting the following error in my logs:
SSLException: Received fatal alert: unexpected_message
Turning on SSLDebug gives the following:
TP-Processor2, READ: TLSv1 Alert, length = 2
TP-Processor2, RECV TLSv1 ALERT: fatal, unexpected_message
TP-Processor2, called closeSocket()
TP-Processor2, handling exception: javax.net.ssl.SSLException: Received fatal alert: unexpected_message
%% Client cached [Session-40, SSL_RSA_WITH_RC4_128_MD5]
%% Try resuming [Session-40, SSL_RSA_WITH_RC4_128_MD5] from port 2903
*** ClientHello, TLSv1
The behaviour is that SSL connections work for five minutes - and then they fail with the message above. My guess is that this is an SSL session cache issue.
Has anyone resolved this?
So it turned out that bouncy-castle (a jar dependency of opensaml) adds a bunch of extra ciphers into the SSL negotiation. The TIBCO server has a spew at these extra ciphers. Rolling back the Bouncy Castle Jar to 1.3.5 (pre-elliptic SLL Ciphers) solved this issue.