Layer7 API Management

Hi all,

I'm experiencing an issue with version 8.2 of the ssg

I have two sandbox environments where this works perfectly

My production ssg won't connect to some external servers; I've tested aws lambda and google (both work in my sandboxes)

2015-11-23T17:28:04.502+0000 WARNING 9034 com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion: 4042: Problem routing to https://ttgy6tebd5.execute-api.eu-west-1.amazonaws.com:443/alpha/l5zqbs. Error msg: Unable to obtain HTTP response from https://ttgy6tebd5.execute-api.eu-west-1.amazonaws.com:443/alpha/l5zqbs: Received fatal alert: handshake_failure

I've added all of the relevant certificates to my trust store and configured the listen port (ssl/tls settings) to no avail.

We are able to send the same requests via curl from the prod servers command line successfully so the boxes have connectivity and access to the right cipher suites

I've set up a basic route via https using my sandbox as a server and production as the client...

It seems that the server(sandbox) has to support tls 1.0 in order for this connection to work which indicates that the gateway uses tls 1.0 to negotiate ssl handshake; this can't be a default setting as it works in my other boxes... is there any way to change it??

Is there anyone out there in the community that has experienced anything similar?

Any help would be greatly appreciated and I will update this thread with the answer if we manage to resolve it so that no one else has to go through this pain...

Kind regards,

Gary

Hi gary.vermeulen,

You can activate more than one supported TLS version on your listen port properties. By default SSL exchanges will try to use the higher TLS protocol version. Maybe you should check the activated cipher suites are the same as they are in your sandboxes.

Last item to check is the ssl imported certificate : it must be enabled for outbound ssl connection, and maybe as a trust anchor.

Please tell me if this helps.

Have a nice evenig

Hey Nicolas,

Thanks for replying,

This is not a problem related to using the gateway as a server but as a client and I have checked that the cipher suites are not the cause by cloning the settings across environments without any luck..

I've also imported the third parties certs and double checked after your recommendation that our certs are setup correctly..

When my production gateway makes outbound calls to third parties; for example you might surface a login page via the gateway that when submitted does a route via https to an aws lamda function and returns the response to your user..

The connection between the gateway(client) and the third party(aws lamda) cannot be established and I've debugged it down to the gateway using TLS1.0 when making outbound connections...

When a client is communicating with the gateway all versions of TLS are supported and a handshake takes place.. This is only an issue in production; I'm running out of things to try

Any thoughts?

Kind regards,

Gary

Hi gary,

You're welcome.

Do you reproduce this issue with all https webservices (maybe you could try some other providers) ?

Please share here your logs for deeper analysis.

Hi Nicolas,

After many hours trying to get to the bottom of this we determined the root cause to be the l7 gateway only supporting TLS1.0 when making outbound connections with cipher suites that not all third parties support.

We are using a SafeNet Luna HSM which the only difference between sandbox and production.. I then found this which confirmed our theory

I've contacted support with this info and asked for some guidance but they haven't been very helpful as of yet...

Kind regards,

Gary

As far as I know, one part of the SSL connection may give up, if it can not support any of the CIPHERS supported by other end.

Adding cipher suites to Listen port will not help, since this is outbound.

I guess if you install Java Cryptology Extension to Gateway, and copy it to under $JRE_HOME/lib/security, your SSL connection may work.