A routing assertion in a service policy on a CA API Gateway ("API Gateway") may fail with the following error:
Problem routing to <hostname>. Error msg: Unable to obtain HTTP response from <hostname>: server certificate change is restricted during renegotiation
The error is typically observed when one end is still using an insecure SSL 3.0 protocol and another is using TLSv1.0 or newer with more modern security standards enabled. The protocol may not always matter, however. The restriction on one side and not the other can cause a conflict on what is allowed and not allowed during the handshake.
Current security standards suggest that certificate changes during renegotiation (mid-handshake) be refused and considered unsafe. As a result, many applications and frameworks such as Java (a dependency used in the API Gateway) changed their default SSL configurations to disallow such certificate changes during renegotiations.
If such a change is included in the API Gateway (newer versions include this change) but not the backend, for example, this may cause the described symptoms as the Gateway will end the communication once it receives a certificate change packet mid-handshake from the backend.
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.