How to troubleshoot an SSL connection issue on webMethods v8.2 Integration Server

Ever had to troubleshoot an SSL connection issue but overwhelmed by a "je ne sais quoi" feeling ? Let me try to ease your pain based on recent experience.

Use case :

• Integration Server acts as an ssl client, connecting to a partner's HTTPs server
• Certificates are exchanged and loaded in key- and truststore on both ends
• Calling the URL over HTTPs results in error "ssl handshake failure".

Our first step, enable ssl debugging on the Integration Server.
Introduce two extended settings ("watt.net.ssl.debug=true" and "watt.ssl.iaik.debug=true") and restart the Integration Server. Per default ssl debug information will be send to the standard out.

After calling the URL again over HTTPs additional debug information shows :

ssl_debug(2): Starting handshake (iSaSiLk 3.03)...
ssl_debug(2): Remote client:193.2.253.29:8443, Timestamp:Wed Aug 06 14:31:05 CEST 2014
ssl_debug(2): Sending secure renegotiation cipher suite
ssl_debug(2): Sending v2 client_hello message, requesting version 3.1...
ssl_debug(2): Received alert message: Alert Fatal: handshake failure
ssl_debug(2): SSLException while handshaking: Peer sent alert: Alert Fatal: handshake failure
ssl_debug(2): Shutting down SSL layer...
ssl_debug(2): Closing transport...

What are these log entries telling us ?
The Integration Server is sending message "Sending v2 client_hello" to the HTTPs server. This request is immediately rejected by the end target (ref entry "Received alert message: Alert Fatal: handshake failure" reported in ssl debug log lines).

The purpose of the SSL v2 Client Hello is listed in the TLS specification as a way for SSL Clients to allow backwards compatibility with previous versions of SSL. The specification also states that TLS Servers are allowed to reject SSL v2 Client Hello messages if they do not support the previous versions of SSL.

Per default the Integration Server can handle different cryptographic protocols (tls, sslv2, sslv3). How to discover what type of protocol the HTTPs server supports?

1. Go to www.openssl.org
2. Download and install the binary distribution of your preference
3. Running following commands :
4. to verify is HTTPs server support tls1
   openssl s_client -verify 6 -state -msg -tls1 -showcerts -connect <host>:<port>
5. to verify is HTTPs server support ssl2
   openssl s_client -verify 6 -state -msg -ssl2 -showcerts -connect <host>:<port>
6. to verify is HTTPs server support ssl3
   openssl s_client -verify 6 -state -msg -ssl3 -showcerts -connect <host>:<port>

     Note : Replace "<host>:<port>" with the hostname and port of your end target specifications.

If the result contains "ssl handshake failure" it indicates your target is rejecting the selected protocol.

In our use case the partner only accepted tls. The issue was solved once the administrator of the HTTPs server enabled ssl v3 on his end.

Author: Johan De Wulf

SDDC vs webMethods Command Central

The IT infrastructure of large corporations is setting sail to a new promised land called Software-defined data center (SDDC). SDDC envisions to have all elements of the infrastructure — networking, storage, CPU and security – virtualized and delivered as a service. Naysayers argument that SDDC is a marketing tool, a hype. Believers claim victory be stating software will define the future data centers.

To stir the pot is that enterprises are lured into the "dark" side by a voice whispering that SDDC would allow to optimize CapEx (Capital expenditures) and OpEx (operating expenditure) savings.

"why" not to miss the SDDC trend?
SDDC is about orchestrating, coordinating and applying resources from the server, storage and networking pools to ensure that the applications or services meet the capacity, availability and response time SLAs the business requires. IT organizations will have to make significant changes to elimate barriers that exist between the various technical domains; e.g., network, compute, storage. The numbers of people involved with manual tasks will be reduced. The time to market of an application going live on a new provisioned server (incl storage, networking and application deployment) would become a matter of hours instead of weeks.

How to deploy the complete or a subset of the webMethods service stack onto a server without the hassle of doing repetitive manually configuration steps in a limited amount of time? WebMethods Command Central (CC) you say?

CC stands for "Centralizes administration, configuration and monitoring of webMethods environments for on-premise and public and private cloud implementations,
improving consistency and reducing risk.".

How does CC handle the provisioning of a new webMethods Integration Server installation?
A pre-requisite is that the server on which the Integration Server is to be installed runs the SoftwareAG Platform Manager (SPM) component. Once SPM is available the target environment needs to be registered in CC. Through a number of distinctive steps (which includes the generation of a template) CC can spine up a cloned Integration Server through the SPM satellite. In order to interact with CC several clients are available (Web UI, Command Line Interface (CLI), ...). Leveraging template based provisioning products, files, configuration and files can be cloned/copied between source and target node.

In a perfect world you would like to incorporate the CC CLI instruction set in your personal scripts to automate the installation and configuration as much as possible.Further tests with the CC 9.6 reveal that at this moment template based provisioning has at least following limitations:

• target server needs to be first equipped with SPM before further installation can be scheduled.
• predetermined list of files that are part of template based provisioning for files. Unable to customize list. All or nothing scenario.
• only works with a Default instance under the installation folder. Unable to deploy template to customized instance names.
• no Simulation mode like Deployer.
• no variable substitution in template.
• unable to rollback fixes through CC.

In the land where SDDC is Colonel and orchestration is one of his majors some of the above remarks would be considered as a disadvantage.
Word has it that CC 9.7 could come with remote SPM bootstrapping. In layman's terms this means that on a virgin server, having an ssh deamon and a Java virtual machine available should be sufficient to get SPM installed through a remote installation procedure.

Honestly, wouldn't be surprised if some of these challenges are resolved in future versions of the product.

Author: Johan De Wulf