SOAP Error | Peer sent alert: Alert Fatal: handshake failure | wM6.5

Hi All,

I am using webMethods 6.5 and I encountered the below error while executing the pub.client:soapHTTP service available in WmPublic. Peer sent alert: Alert Fatal: handshake failure

Initially I thought this was due to the certificate of the target url not being installed in wM IS but even after I imported the same, the flow did not work and I got the same error again.

I imported the client certificate by the below method:
Security > Certificates > Configure Client Certificates

Can you please help? I am not very experienced in working with SOAP services, so feel free to guide and ask for any inputs from me that’ll help in figuring out the issue.

Many thanks in advance,

Hi Mainak,

can you share an overview of your certificate configuration from IS Admin UI from the Security section?

Can you try "openssl s_client -showcerts -connect host:port" on your host to connect to the partner?
Or just try to access the WebService in a Browser window to check the certificate validity?

Depending on your partners server configuration you might run into a SSL/TLS version issue here, this should be identifiable by checking the access to the partners server by using the commands above.

If a SSL/TLS version is the root cause you will have to plan a migration of your webMethods installation to at least 9.12 (via 7.1.3 and 9.5) as wM 6.5 only supports TLS v1.0, while official TLS v1.1 and TLS v1.2 will be supported with 7.1.3 onwards, but for stable support at least wM 9.x (x >= 5) should be used.


Hi Holger,

Thanks for your reply and it did shed some light on the issue.
First off, PFA the information you requested along with the output of the command you suggested.
I can see that TLSv1.2 is being used here and as you said “wM 6.5 only supports TLS v1.0”, I think there might be a TLS version issue here.

I have two questions here:

  • How to confirm that “wM 6.5 only supports TLS v1.0”? Is there any documentation of sorts?
  • Is there any way to make this work as upgrading wM is not an option, unfortunately?

I found this page (link PFB) where there is a section called TLS/SSL Handshake Issues & Debugging. There my handshake issue is mentioned and as a solution, it said:

I tried the above way but it did not work and yes, I restarted the server after changing the configuration. :slight_smile:
Moreover, it also stated that

But I don’t have any of those parameters configured in server.cnf and even if I had to I don’t know what values I should configure them with. I’d like some help with those if it’ll help with the situation.

Looking forward to your reply and advice.

Server_Certificate_configuration.docx (49.3 KB)

Hi Mainak,

based on your input one more question:
Can you provide a ScreenShot of your About-Page of IS?

The Entrust IAIK library bundled to the IntegrationServer does not support TLS v1.1 and TLS v1.2.

TLS v1.1 and TLS v1.2 will be only available when IS runs in JVM 7 or 8, but not in JVM 6 or lower.
Additionally, TLS v1.1 and TLS v1.2 require JSSE mode instead of Entrust mode.

Here is a sample of the complete SSL/TLS-Settings when disabling SSLv2 and SSLv3 completely and only allow TLS regardless of version:,TLSv1.1,TLSv1.2,TLSv1.1,TLSv1.2

The first 2 entries refer to the protocol versions of JSSE and the other ones refer to the Entrust IAIK lib, where ‘tls’ stands for TLS v1.0, which is the maximum here.
The “” tells the IS to use JSSE for outgoing connections to any other servers.

If you want to disable TLS v1.0 and TLS v1.1, just remove them from the list of allowed protocols.

When the above settings are missing in your server.cnf, you can add them by editing the “Extended Settings” section in IS Admin UI under “Settings”. But these might not be taken into account as long as you do not have to corresponding Fix applied to your IS.

When you are hosting an HTTPS-Port in your IS, make sure it is configured to use JSSE as well for incoming connections.

Please check on Empower ( for articles related to the POODLE SSL vulnerability.
I am not sure if there is a fix available for 6.5 to work around this vulnerability or to use JVM 7 with 6.5.


Hi Mainak,

Pardon me if I jumped in and answer your question. I’m an ex-GS from SAG and I can tell you that you’re wM6.5 is definitely running on Entrust library. It’s only support TLS 1.0 unfortunately. Whatever extended properties available on JSSE part will not be available for your case. FYI, JSSE features only available from wM9.5 if i’m not mistaken.

If you want to see in details the SSL debug log, use this extended property “watt.ssl.iaik.debug” to “true” to enable entrust library SSL debug log. The details SSL client and server communication logs will most likely be output to server.log in wM6.5.

As Entrust/JSSE security library are part of the core IS features, that is the reason it’s important to know that you’ve to ensure you’ve migrated to the minimum in support version by SAG. If you fallen behind especially in this case that far behind, you will most likely on your own with the risks.

If you need those urgently, I suggest you to ask your clients to upgrade to a supported version to take advantage of that.

1 Like

Hi Mike,

thanks for adding some additional insights on this.

I already had the same in mind.

AFAIK there is a version of the Entrust library available which supports TLS v1.1. and TLS v1.2, but this version is not yet available in the webMethods Suite.
I doubt that this will ever happen in the favour of switching to the JSSE version.

Migrating is a complex matter here, as you will have to migrate several times:
6.5 to 7.1 to 9.5 to 9.12
If you want to migrate further to 10.3 or 10.5 is up to you.
As 6.5 and the intermediate releases before 9.12 are already out of regular support you will have to check how to download them.
Might be easier to “reinvent the wheel” based on wM 9.12 or wM 10.x in this case.


Hi Mike and Holger,

I did have a discussion with our client and we agreed on a suitable path to mitigate this issue.

We are thinking of a workaround as wM version is incompatible for TLSv1.2.

It’s with higher management now. Anyways, Thank you so much for your explanations. Your advice were a life-saver. :slight_smile: