Getting SSL Exception while using java callout

[otmidhuna]

Hi,

We have been using Java service callout for a long time now and were using HttpUrlConnection to call other APIs. Suddenly on 22nd May the same stopped working for https protocol in development which previously used to work. The same is working fine in production until now.

We were only getting this as exception(java.lang.IllegalArgumentException: SSL) in APIGEE logs but were unable to figure out the cause. Also to note that any https URL that we are trying to call using HttpUrlConnection is failing now in multiple proxy also which seems to be strange behaviour considering the same worked previously and the same is working on production too.

We also have tried adding code to circumvent any SSL related issues of certificates or handshakes but still did not work after the issue occured.

Require help in identifying what can be the issue and how it can be fixed.

[API-Evangelist]

May be below may help..

1. If it was working and stopped it could be firewall (again not sure about your topology) .Check using telnet or do a packet pactures while running your proxy..

2. Enable debug on MP and easy to identify.

https://docs.apigee.com/private-cloud/v4.19.06/enabling-debug-logging?hl=en

Why Java code is not giving complete stack trace? may be revisit the code for better error handling.

Let us know what you find..

[dchiesa1]

if you are saying that the TLS failure is happening on a wide variety of target systems, then it's less likely that the problem is due to incorrectly configured certificates at all of those systems.

Vinay suggested that if it was working before and now stopped working it could be a firewall issue. That's possible. It's also possible that the problem is on the Apigee side.

I have read here recently about an update to the JDK causing TLS failure. (See here).

If the problem is isolated to a single target system, then it's likely not the JDK issue.

Another cause of the symptoms you're seeing could be expiry or revocation of the x.509 certificate used by the peer (the remote system). We sometimes forget, but TLS (SSL) happens based on the trust of an X.509 certificate presented by the peer. Apigee will connect to a remote system over TLS if the remote system presents a certificate which (a) is valid, and (b) which Apigee trusts. By "valid" we mean that the current time (now) lies in between the validity dates (notBefore and notAfter) on the certificate itself.

If the TLS connection was working on Friday, and is no longer working now, one cause could be that the certificate has expired.

How can you check this? Here's a tip from shellhacks.com.

If it turns out the cert is expired, to correct the problem, you need to contact the owner of the upstream system and ask that they renew or update the certificate.

Using variations of the tip in the shellhacks article can help you diagnose other problems, too. For example it's possible that someone managing the remote system has reconfigured the certificate for the remote system, and as a result, that remote system is no longer presenting a certificate that is treated as trusted by Apigee. It's possible that the remote system is presenting a certificate that does not match the hostname of the remote system.

Lots of possibilities.