The Real Fix:
Seeing this behaviour - while understandable seen as an inconvenience if unexpected - should actually be viewed as an opportunity to improve the security of the weaker side in the communication, whether it be the API Gateway side or another side. It would be generally advised to keep both sides up-to-date software-wise, follow typical security standards and best practices such as using TLSv1.2 and using modern cipher suites, etc. Doing so should avoid any conflicts in SSL restrictions.
Of course, that is not always possible nor always in someones control. In such a scenario, the workaround below can be used on the Gateway. As the properties are actually Oracle Java properties, they may also be able to be applied to other Java-based applications or load balancers. If the other end is t
If the API Gateway is the stronger one security-wise and the one causing the communication to cease when it receives a certificate change packet during the handshake, then the two system properties listed below must be added to the /opt/SecureSpan/Gateway/node/default/etc/conf/system.properties file to override the behaviour to allow SSL renegotiations:
A restart of the API Gateway / SSG service should be completed before the changes take effect. At this point, the described symptom should no longer appear and communication should now succeed. If they continue to be seen, then it's quite possible the other end is the one closing the connection and may need to be changed appropriately. In some cases, customers have needed to make similar changes to the above on clients, load balancers, or backend servers. The vendor of such endpoints may need to be contacted to ensure proper configuration.