After creating a second instance of Access Gateway (AG) on a Red Hat host, the second instance was not able to make an SSL connection to the same backend host as the first instance. The second instance contains the same certificate authority (CA) cert in the ca-bundle.cert file as the first instance. The AG Web Agent trace log shows that AG cannot find the needed CA cert in order to trust the connection.
The one CA cert that was contained in the ca-bundle.cert file was not the correct one for the backend host in question. The first instance of AG had some additional .cert files in the /secure-proxy/SSL/certs folder that were not present in the second instance, and the needed CA cert was in one of those files (the discrepancy came when the original .cert file was backed up differently on each host, with the working host retaining the .cert extension while the non-working host had the .cert extension changed to something else).
Comparing the two server.log files from each instance helped reveal this problem. The working instance was loading >300 certs at startup while the non-working instance was only loading a single cert.
Release : 12.8
Component : SITEMINDER SECURE PROXY SERVER
The CA cert that was allowing the backend connection to succeed in the 'working' instance of AG was being loaded from a file other than ca-bundle.cert. AG will load any cert that's in any .cert file in the secure-proxy\SSL\certs folder. Once we copied all the .cert files from the working instance to the non-working instance and restarted the non-working instance, the non-working instance was able to successfully connect to the backend host.