Hi

I’m trying to configure the Integration Server as an SSL client.

Initially I wrote an SSL client in Eclipse to test the SSL connection and all this works correctly - I was able to view the SSL handshake debug etc.

I have a DER certificate (that I used in my SSL client) and I placed this in a IntegrationServer/certs/trusted directory.

I tried to use the pub.client.http service to call the https URL however I get:

ssl_debug(1): Starting handshake (iSaSiLk 3.03)…
ssl_debug(1): Sending v2 client_hello message, requesting version 3.1…
ssl_debug(1): IOException while handshaking: Connection closed by remote host.
ssl_debug(1): Shutting down SSL layer…

So I attempted to create a java service by importing the code from my SSL client.
I debug the SSL handshake:

trustStore is: /da003WebM001/IntegrationServer/packages/AppComada/resources/cm_keystore
trustStore type is : jks
trustStore provider is :
init truststore
adding as trusted cert:

/* CERT VALUES */

trigger seeding of SecureRandom
done seeding SecureRandom
trustStore is: /da003WebM001/IntegrationServer/packages/AppComada/resources/cm_keystore
trustStore type is : jks
trustStore provider is :
init truststore
“ssl.log” 495 lines, 32976 characters
0040: 09 00 15 00 12 00 03 00 08 00 14 00 11 01 00 …
HTTP Handler 10.134.42.238, WRITE: TLSv1 Handshake, length = 79
[write] MD5 and SHA1 hashes: len = 107
0000: 01 03 01 00 42 00 00 00 20 00 00 04 01 00 80 00 …B… …
0010: 00 05 00 00 2F 00 00 35 00 00 33 00 00 39 00 00 …/…5…3…9…
0020: 32 00 00 38 00 00 0A 07 00 C0 00 00 16 00 00 13 2…8…
0030: 00 00 09 06 00 40 00 00 15 00 00 12 00 00 03 02 …@…
0040: 00 80 00 00 08 00 00 14 00 00 11 4B FC D0 66 4C …K…fL
0050: 45 12 2F 0C 02 FB 3F A2 DD C8 6C D7 42 DD 16 CF E./…?..l.B…
0060: 91 FE 80 DE 8E 99 FD CA 6E D7 71 …n.q
HTTP Handler 10.134.42.238, WRITE: SSLv2 client hello message, length = 107
[Raw write]: length = 109
0000: 80 6B 01 03 01 00 42 00 00 00 20 00 00 04 01 00 .k…B… …
0010: 80 00 00 05 00 00 2F 00 00 35 00 00 33 00 00 39 …/…5…3…9
0020: 00 00 32 00 00 38 00 00 0A 07 00 C0 00 00 16 00 …2…8…
0030: 00 13 00 00 09 06 00 40 00 00 15 00 00 12 00 00 …@…
0040: 03 02 00 80 00 00 08 00 00 14 00 00 11 4B FC D0 …K…
0050: 66 4C 45 12 2F 0C 02 FB 3F A2 DD C8 6C D7 42 DD fLE./…?..l.B.
0060: 16 CF 91 FE 80 DE 8E 99 FD CA 6E D7 71 …n.q
HTTP Handler 10.134.42.238, received EOFException: error
HTTP Handler 10.134.42.238, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection du
ring handshake
HTTP Handler 10.134.42.238, SEND TLSv1 ALERT: fatal, description = handshake_failure
HTTP Handler 10.134.42.238, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 28 …(
HTTP Handler 10.134.42.238, called closeSocket()

I was wondering if anybody could point me in the right direction.

I need to also create a web service connector from a WSDL the schema locations pointing to https urls (similar URL I need to send data too).

regards

Paul

Now the error you get is:

ssl_debug(1): IOException while handshaking: Connection closed by remote host.

Question: Why remote host closes the connection? debug SSL on the other side as well.

The problem here seems to be the remote host closes connection right after the client sends a “hello”, with this info you need to debug the remote host.

Hello,

Was this issue resolved? We are facing similar type of issue.

Below is the wrapper log extract:

INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, received EOFException: error
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, SEND TLSv1 ALERT: fatal, description = handshake_failure
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, WRITE: TLSv1 Alert, length = 2
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, called closeSocket()
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, called close()
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, called closeInternal(true)
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, called close()
INFO | jvm 1 | 2015/10/08 08:54:00 | HTTP Handler 150.251.106.76, called closeInternal(true)
INFO | jvm 1 | 2015/10/08 08:54:00 | Allow unsafe renegotiation: false
INFO | jvm 1 | 2015/10/08 08:54:00 | Allow legacy hello messages: true
INFO | jvm 1 | 2015/10/08 08:54:00 | Is initial handshake: true
INFO | jvm 1 | 2015/10/08 08:54:00 | Is secure renegotiation: false
INFO | jvm 1 | 2015/10/08 08:54:05 | HTTPSListener@443, setSoTimeout(20000) called

Appreciate you response.

Thanks & Regards,
Nikhil

Hi Nikhil,

please provide your wM Version together with the Fix-Level for the affected component (IS, MWS, …).

Did you follow the instructions in the empower kb article related to POODLE configuration?

Dependend on wM Version and remote server there are several option to take in account.

Regards,
Holger

Based on this lines in your log:

ssl_debug(1): Starting handshake (iSaSiLk 3.03)…
ssl_debug(1): Sending v2 client_hello message, requesting version 3.1…
ssl_debug(1): IOException while handshaking: Connection closed by remote host.
ssl_debug(1): Shutting down SSL layer…

your system is sending a v2 client_hello, the destination server rejected right away. Some system will not take v2 client_hello at all, so the SSL handshake won’t continue.

try to use this extended setting:
watt.net.ssl.client.handshake.minVersion=sslv3
restarting IS.
It will start the handshake with v3 client_hello.

Just for more info:

With 9.x.x and above assuming JSSE=true on the HTTPS port you can set this for Inbound connections on the gateway server:

watt.net.jsse.server.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello

HTH,
RMG

we are using wm9.6 without any fixes or patches applied. in my IS admin guide, i don’t see any mention of below server configuration parameter.

watt.net.jsse.server.enabledProtocols

where do we get the list of server configuration details which can be customized but not mentioned in IS admin guide documentation?

thanks and regards,
ajay kumar kasam

Hi Ajay,

please apply latest IS_Core_Fix, SCG_Entrust_Fix and SCG_Security_Fix.

This feature has been introduced while fixing the Poodle-Issue.

Regards,
Holger

Hello rmg,

We are again facing this issue after long time now.

Also the below property is already set as you suggested:

watt.net.jsse.server.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello

Regards,
Nikhil Bhosle

Hi Nikhil,

The best way to solve ssl problems is to find out with step of the ssl handshake go’s wrong.
You can do this by using wireshark on your server. There you can follow all steps. You can even decrypt if you have the correct certificates.

maybe this site can help with the wireshark part:

kind regards
Jo

Since you are using JSSE, remove SSLv2Hello from your setting:
watt.net.jsse.server.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello

Your client’s system doesn’t support SSLv2Hello.

Why should this be removed even though JSSE true?

Since you are using JSSE, remove SSLv2Hello from your setting:
watt.net.jsse.server.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2,SSLv2Hello

TIA,
RMG

SSLv2Hello is regarded as less secure, there is no reason it should be used anymore.
SSLV3Hello should be used.
Some systems explicitly disable SSLv2Hello support. I believe that’s the case for Nikhile.

Hi,

as SSLv2 (SSLV2Hello) and SSLv3 (SSLv3) are both considered unsecure meanwhile they should no longer by allowed for either Type (JSSE/) or direction (server/client) as longer as this is really required by one of your partners.

Refer to the following iTracs:

PIE-34321
Enhancement to Integration Server to allow configuration of cipher
suites with JSSE connections.

Integration Server now contains server configuration properties
that you can use to specify the cipher suites used with inbound
and outbound JSSE communications.

Inbound JSSE Communications
To control the cipher suites used on Integration Server ports that
use JSSE and handle inbound requests, specify comma-separated
values for watt.net.jsse.server.enabledCipherSuiteList. To include
all the cipher suites supported by the JVM, specify a value of
default. For example:
watt.net.jsse.server.enabledCipherSuiteList=
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256
_CBC_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256
watt.net.jsse.server.enabledCipherSuiteList=default

The default value is default.

For changes to this property to take effect, you must start the
port. If the port is already started, you can restart it by
disabling the port and then enabling it.

Outbound JSSE Communications
To use JSSE for all of the outbound HTTPS connections from
Integration Server, specify a value of true for the
watt.net.ssl.client.useJSSE server configuration property. The
default value of this property is false, indicating that JSSE is
not used for outbound HTTPS connections.

Note: When executing the pub.client:http service, the value of the
useJSSE input parameter override the value of the
watt.net.ssl.client.useJSSE server configuration property.

To control the cipher suites used on JSSE sockets that are used
while making outbound HTTPS requests, specify comma-separated
values for the server configuration property
watt.net.jsse.client.enabledCipherSuiteList. To include all the
cipher suites supported by the JVM, specify a value of default.
For example:

watt.net.jsse.client.enabledCipherSuiteList=
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256
_CBC_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256
watt.net.jsse.client.enabledCipherSuiteList=default

The default values is default.

Note: Any changes you make to
watt.net.jsse.client.enabledCipherSuiteList affect new connections
only.

Note:  When the logging facility 0006 Server SSL Interface is set
to the Debug logging level, Integration Server writes messages
about protocols used for inbound and outbound ports to the server
log. At the Trace logging level, Integration Server writes
messages about the enabled cipher suites.

In addition to the above changes for controlling cipher suites, to
provide backward compatibility, Integration Server now includes
SSLv2Hello as a default value for the server configuration
property watt.net.jsse.server.enabledProtocols. In PIE-34054, the
default value of watt.net.jsse.server.enabledProtocls was set to
"TLSv1,TLSv1.1,TLSv1.2". Now, the default value of
watt.net.jsse.server.enabledProtocls is
"SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2".

as well as

PIE-34054
Remove use of SSLv3 from any HTTPS or FTPS Integration Server
ports.

In order to protect against POODLE vulnerability (CVE-2014-3566)
, this fix exposes server configuration parameters that allow
you to disable the use of SSLv3.0 on Integration Server HTTPS
and FTPS ports.

Depending on whether connections use the Entrust library
(entoolkit.jar) or JSSE (where useJSSE=true), you use a
different procedure to disable SSLv3.0. Follow the appropriate
procedure as follows:

For connections that use Entrust (entoolkit.jar) library:
--------------------------------------------------------- When
Integration Server uses the Entrust library to handle inbound
and outbound requests, you disable SSLv3.0 by setting the
following server configuration parameters:

- watt.net.ssl.server.handshake.minVersion

- watt.net.ssl.server.handshake.maxVersion

Possible values for these server configuration parameters are
"sslv3" and "tls" (the default). With this fix, these two
parameters take the default value "tls", which indicates that
all server side SSL listeners will support only TLSv1 and no
longer accept SSLv3 connections.

When Integration Server acts as a client and makes an outbound
request, it configures the allowed protocols using the
following server configuration parameters:

- watt.net.ssl.client.handshake.minVersion=sslv2

- watt.net.ssl.client.handshake.maxVersion=tls

Possible values for these server configuration parameters are
"sslv2", "sslv3", and "tls". If you want to disable the use of
"sslv3", set watt.net.ssl.client.handshake.minVersion as
follows: watt.net.ssl.client.handshake.minVersion=tls

To change the values of the server configuration parameters,
from Integration Server Administrator, navigate to Settings >
Extended and add the parameters as follows:

- watt.net.ssl.server.handshake.minVersion=tls

- watt.net.ssl.server.handshake.maxVersion=tls

- watt.net.ssl.client.handshake.minVersion=tls

- watt.net.ssl.client.handshake.maxVersion=tls

If any of your clients require SSLv3 to connect (the previous
default), set watt.net.ssl.server.handshake.minVersion as
follows: watt.net.ssl.server.handshake.minVersion=sslv3

When making outbound connections, you can configure Integration
Server to first try to connect using sslv3 and, if that fails,
to use tlsv1, set watt.net.ssl.client.handshake.minVersion as
follows: watt.net.ssl.client.handshake.minVersion=sslv3

This will allow Integration Server to use sslv3 with endpoints
that do not support tlsv1.

For connections that use JSSE (where useJSSE=true):

---------------------------------------------------

When Integration Server uses JSSE to handle inbound and
outbound requests, you disable SSLv3.0 by setting the following
server configuration parameters:

- watt.net.jsse.server.enabledProtocols
- watt.net.jsse.client.enabledProtocols

Possible values for these server configuration parameters are a
comma-separated values consisting of one or more of the
following:

- SSLv2Hello
- SSLv3
- TLSv1
- TLSv1.1
- TLSv1.2

With this fix, watt.net.jsse.server.enabledProtocols and
watt.net.jsse.client.enabledProtocols are set to the default
value of "TLSv1,TLSv1.1,TLSv1.2", which indicates that all
server side SSL listeners and client side outbound connections
that use JSSE will not accept any SSLv3 or SSLv2 connections.

To change the values of the parameters, from Integration Server
Administrator, navigate to Settings > Extended and add the
parameters as follows:

watt.net.jsse.server.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2
watt.net.jsse.client.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2

Note: These values are case-sensitive. Specify the values
exactly as shown.

If any of your clients need to connect using SSLv3, add SSLv3
to watt.net.jsse.server.enabledProtocols, for example:
watt.net.jsse.server.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2,SSLv3

When starting JSSE ports, at DEBUG level of logging
facility 6 (Server SSL Interface), Integration Server
logs a message to indicate what protocols are enabled
for each JSSE port.

for further informations.

Regards,
Holger

Hello All,

The issue was resolved for me after applying fix IS Core fix 8.

PIE-38429
Integration Server logs an exception when a service is invoked
through a JSSE-enabled HTTPS port with client authentication set
to “Username/Password” or “Request Client Certificates”.

When a service is invoked through an HTTPS port that uses JSSE
and has client authentication set to “Username/Password” or
“Request Client Certificates”, Integration Server logs the
following exception in the error log:
javax.net.ssl.SSLPeerUnverifiedException: peer not
authenticated.

The issue is now resolved. Integration Server does not log any
exception upon invoking a service successfully through a
JSSE-enabled HTTPS port with client authentication set to
“Username/Password” or “Request Client Certificates”.