connection reset by peer calling soap webservice - java

Currently trying to invoke a web service, however i am getting a connection reset/connection reset by peer, below is the stack trace:
WRITE: TLSv1 Handshake, length = 81
WRITE: SSLv2 client hello message, length = 110
waiting for close_notify or alert: state 1
Exception while waiting for close java.net.SocketException: Connection reset
handling exception: java.net.SocketException: Connection reset
SEND TLSv1 ALERT: fatal, description = unexpected_message
WRITE: TLSv1 Alert, length = 2
Exception sending alert: java.net.SocketException: socket write error: Connection reset by peer.
called closeSocket()
called close()
called closeInternal(true)
called close()
called closeInternal(true)
called close()
called closeInternal(true)

It was an SSL issue, as per the trace, there was only a Client Hello, but no Server Hello Response, (http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html) after import of server public key to client keystore it is now working

Related

Mutual SSL handshake failing after Client CertificateVerify step

While calling an external Api secured using Mutual SSL, getting the javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Went through the ssl debug logs and seems like client and server are able to exchange and validate the certificate and communication is failing after that step.
Putting relevant SSL debug logs :
^^^ClientHello, TLSv1.2
^^^List of CipherSuites
^^^ServerHello, TLSv1.2
^^^Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256
** Certificate chain
..............................
................................
^^^CertificateRequest
............
^^^ServerHelloDone
^^^Certificate chain
..................
....................
no IV derived for this protocol
CertificateVerify
Signature Algorithm SHA256withRSA
main, WRITE: TLSv1.2 Handshake, length = 264
main, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data: { 46, 243, 175, 158, 127, 112, 161, 153, 5, 195, 3, 35 }
main, WRITE: TLSv1.2 Handshake, length = 80
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Communication is failing after certificateverify step, not sure if it is due to "no IV derived for this protocol". Can someone throw some light on this, what could be possible reason for failure after client certificateverify step. Also for the client I am using Java 8 with Java Cryptography Extension (JCE) Unlimited Strength

fatal, handshake_failure javax.net.ssl.SSLHandshakeException

I am trying to connect to WebService client using HttpApiClient. I am specifying
truststore = <path to Java cacerts>
truststore password = <default pass>
keystore = <custom JKS properties with all certs>
keystore password = <default pass>
When I debug the SSL using Java, I dont even see the "Server Hello message" directly the fatal, handshake error like below:
http-bio-8080-exec-9, WRITE: TLSv1 Handshake, length = 122
http-bio-8080-exec-9, READ: TLSv1 Alert, length = 2
http-bio-8080-exec-9
, RECV TLSv1 ALERT:
fatal,
handshake_failure
http-bio-8080-exec-9, called closeSocket()
http-bio-8080-exec-9, handling exception: javax.net.ssl.SSLHandshakeException:
Received fatal alert: handshake_failure
http-bio-8080-exec-9, called close()
http-bio-8080-exec-9, called closeInternal(true)
I cant debug further because there are no clues as to what is wrong. Error message does not describe anything. I have double checked all the certs are present. Any ideas on how can I debug this / what is missing ?

Amazon S3 SDK for Java - Can't get listbuckets to work for https

I have this code snippet which simply lists the buckets. However, I am not able to get this working with https.
This is what I do.
Generate the latest root certificate for my OS (RHEL 5.3).
Do a keytool import to my trust store.
Use the following flags
-Djavax.net.ssl.trustStore=path_to_key_store
-Djavax.net.ssl.trustStorePassword=password_to_key_store
BasicAWSCredentials credentials = new BasicAWSCredentials(username, password);
ClientConfiguration clientConfig = new ClientConfiguration();
clientConfig.setConnectionTimeout(timeout);
AmazonS3 s3 = new AmazonS3Client(credentials, clientConfig);
s3.setEndpoint(url);
for (Bucket bucket: s3.listBuckets()) {
System.out.println("Bucket name::" + bucket.getName());
}
What am I doing wrong? How can I get https to work?
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, IOException in getSession(): javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
Jan 22, 2015 2:55:40 PM com.amazonaws.http.AmazonHttpClient executeHelper
INFO: Unable to execute HTTP request: peer not authenticated
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:397)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at com.amazonaws.http.conn.ssl.SdkTLSSocketFactory.connectSocket(SdkTLSSocketFactory.java:118)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at com.amazonaws.http.AmazonHttpClient.executeOneRequest(AmazonHttpClient.java:685)
at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:460)
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:295)
at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3714)
at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3664)
at com.amazonaws.services.s3.AmazonS3Client.listBuckets(AmazonS3Client.java:685)
at com.amazonaws.services.s3.AmazonS3Client.listBuckets(AmazonS3Client.java:693)
at AmazonS3ClientTester.main(AmazonS3ClientTester.java:23)

Trying to connect to EJBCA Web Service and getting bad_certificate at ServerHelloDone

I apologize for the really newbie quality of this question.
I have a EJBCA server set up and two CA's on it. One is the default one I created the server instance with.
I took the wsdl from EJBCA and generated Java code with it.
Using the generated java client code, I'm trying to open a connection to the EJBCA server.
According to EJBCA here: http://ejbca.sourceforge.net/ws/org/ejbca/core/protocol/ws/client/gen/package-summary.html
This the way to initialize a connection to the server.
I took the truststore.jks file from the EJBCA server as well as the superadmin.jks file from the server and put it on my local machine and made it available for my app as a resource.
val truststore = this.getClass.getClassLoader.getResource("pathto/wsTrustStore")
System.setProperty("javax.net.ssl.trustStore", truststore.getFile)
System.setProperty("javax.net.ssl.trustStorePassword","wsTrustStorePassword")
val keystore = this.getClass.getClassLoader.getResource("pathto/superadminKeyStore")
System.setProperty("javax.net.ssl.keyStore", keystore.getFile)
System.setProperty("javax.net.ssl.keyStorePassword", "superadminKeyStorePassword")
val qname = new QName(componentConfig.getString("http://ws.protocol.components.ejbca.org/"), "EjbcaWSService")
val service = new EjbcaWSService(new URL("https://myejbcaserver.com:8443/ejbca/ejbcaws/ejbcaws?wsdl"), qname)
service.getEjbcaWSPort
this is the java ssl debug logs
* CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
ServerHelloDone
** Certificate chain
* ClientKeyExchange, RSA PreMasterSecret, TLSv1
New I/O worker #2, WRITE: TLSv1 Handshake, length = 141
...
New I/O worker #2, WRITE: TLSv1 Change Cipher Spec, length = 1
* Finished
verify_data: { 95, 232, 182, 57, 141, 10, 130, 36, 152, 210, 86, 173 }
New I/O worker #2, WRITE: TLSv1 Handshake, length = 48
New I/O worker #2, waiting for close_notify or alert: state 1
New I/O worker #2, READ: TLSv1 Alert, length = 2
New I/O worker #2, RECV TLSv1 ALERT: fatal, bad_certificate
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
New I/O worker #2, called closeSocket()
New I/O worker #2, Exception while waiting for close javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
New I/O worker #2, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
Is there anyone who has experience with this that can help me out?

How to troubleshoot SSL "bad record MAC" exception

I am using an Apache CXF client, running in a Windows Java 1.6.0_29-b11 VM to connect to an IBM mainframe (I believe it is zSeries), and invoking a SOAP Web Service running there. The connection is done through SSL/TLS, and most of the time works fine.
However, from time to time I have SSL Exceptions with a bad record MAC message. Here is the output of the program using with the javax.net.debug property.
2011-11-16 12:32:37,731 INFO LoggingOutInterceptor: Outbound Message
---------------------------
ID: 29
Address: https://1.2.3.4/access/servlet/blabla.atk123
Encoding: UTF-8
Content-Type: text/xml
Headers: {Accept=[*/*], SOAPAction=["Blablaaction/ATK123.Execute"]}
Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ATK123.Execute xmlns="Blabla"><Usrid>WA</Usrid><Usrpwd>54321</Usrpwd><Ultautid>9999</Ultautid></ATK123.Execute></soap:Body></soap:Envelope>
--------------------------------------
pool-1-thread-1, setSoTimeout(30000) called
pool-1-thread-1, WRITE: TLSv1 Application Data, length = 321
pool-1-thread-1, WRITE: TLSv1 Application Data, length = 262
pool-1-thread-1, READ: TLSv1 Application Data, length = 483
pool-1-thread-1, READ: TLSv1 Application Data, length = 16148
pool-1-thread-1, READ: TLSv1 Application Data, length = 282
%% Invalidated: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
pool-1-thread-1, SEND TLSv1 ALERT: fatal, description = bad_record_mac
pool-1-thread-1, WRITE: TLSv1 Alert, length = 22
pool-1-thread-1, called closeSocket()
pool-1-thread-1, handling exception: javax.net.ssl.SSLException: bad record MAC
2011-11-16 12:32:38,511 WARN PhaseInterceptorChain: Interceptor for {Blabla}ATK123#{Blabla}Execute has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: bad record MAC
at org.apache.cxf.interceptor.LoggingInInterceptor.logging(LoggingInInterceptor.java:144)
at org.apache.cxf.interceptor.LoggingInInterceptor.handleMessage(LoggingInInterceptor.java:73)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:797)
.... (more stuff)
Unfortunately, I don't have possibilities to modify or debug the endpoint at the server.
What could be causing this?
How can I isolate and fix this behavior?
If you are getting a lot of bad packets due to some fault in your network it can happen that a bad packet will at random survive the 32-bit TCP checksum. About 1 in 4 billion bad packets will slip by TCP. Once this packet is delivered to SSL it will generate a bad record MAC for sure, because the SSL Mac is 96 bits in size.
If this is the cause, the only solution is improve the network.
Note that, in general, this is a very unlikely cause of a bad record MAC. Even a network with faulty hardware that generates bad packets is unlikely to generate them with correct IP and TCP metadata such that the packets are actually passed to the socket corresponding to the TLS connection.
This isn't related to Java, it is an SSL/TLS failure:
20 Bad record MAC fatal Possibly a bad SSL implementation, or payload
has been tampered with e.g. FTP firewall rule
on FTPS server.
It probably has something to do with the SSL implementation and the amount of data that is being sent being too big, I doubt it is random.

Categories