Troubleshoot: Problems and Solutions

This topic provides troubleshooting assistance for common issues.
This topic provides troubleshooting assistance for common
API Gateway
Problem: Gateway does not reboot
I logged in to the Gateway as an LDAP user and imported a new authentication configuration file. I used the "R" option to reboot and nothing happened.
: By changing authentication schemes, you lose the ability to reboot the machine. Do one of the following actions:
  • Log in as the
    user and select,
    (Reboot the Gateway appliance)
  • In vSphere Client, select
    Restart Guest
    Do not use the Reset option on the vSphere Client, as this can cause data loss.
Problem: Gateway is not running properly after a restore
I restored a 
API Gateway
using the
command. Now I can't connect to it using the Policy Manager. Closer inspection reveals that the
file is not running and information is not being recorded to the Gateway log files. (SSG-9735)
Perform the following steps:
  1. Open a privileged shell and navigate to this directory:
    cd /opt/SecureSpan/Gateway/node/default/etc/conf/
  2. Run the following command:
    # chmod g+r *
  3. Restart the 
    API Gateway
    . You should now be able to connect normally.
Problem: Gateway does not start after a custom installation
After I complete a custom installation, the Gateway will not start and I get the following error:
Error: Unable to start the server: Error starting server: Error creating bean with name 'liquibaseManager' defined in class path resource: Constructor threw exception; nested exception is java.lang.RuntimeException: Could not find liquibase folder: /opt/SecureSpan/Gateway/config/etc/db?
: Open /opt/SecureSpan/Gateway/node/default/etc/conf/
  1. Add the system property,
     to point to the database scripts directory.
  2. Restart the Gateway.
The default scripts directory is: ${ssgBase}${fs}Gateway${fs}config${fs}etc${fs}db, or /opt/SecureSpan/Gateway/config/etc/db.
Problem: Deleting OAuth policy creates dependency errors
When I deleted an OAuth policy, it resulted in many "dependency" errors that needed to be acknowledged one at a time. How can I avoid this?
This is a result of the Policy Manager's validation checks: it is warning you that you are removing a policy fragment that is currently serving as a backing policy for an encapsulated assertion. To avoid having to acknowledge each dependency error, first delete all the encapsulated assertions related to the OAuth Toolkit. You can do this by using the Manage Encapsulated Assertion task. Advanced users can also avoid these errors by deleting the OAuth folder using the RESTMan Service. (SSM-5068)
Problem: Slow shutdown and startup of Software Appliance (VMware)
When I apply multiple Monthly and Release Platform Patches, the shutdown and startup time of software appliance (VMware) is very slow.
Ensure that you update the VMware tools.
Problem: JDBC connection failures
My JDBC connection to the database is failing because the server thinks it is under a DDOS attack due to a sudden surge of connections.
Use the recommended configuration below, especially if you use the CA API Management OAuth Toolkit or the CA Mobile API Gateway.
  • Ensure that the following JDBC Cluster Properties are set to the same value:
  • Set the following Additional Properties for the JDBC connection:
    • Property Name:
      Property Value:
      To set a C3P0 pooling property:
    • Property Name:
      Property Value:
      To set a C3P0 pooling property:
    • Property Name:
      Property Value:
      To set a C3P0 pooling property:
    • Property Name:
      Property Value:
      To set a C3P0 pooling property:
  • If an Oracle DB is in use, also set this Additional Property:
    • Property Name:
      Property Value:
      select 1 from dual
      (enter the entire value)
      To set a C3P0 pooling property:
Problem: "Gateway Inactivity timeout reached" displays immediately upon Policy Manager log in
The Gateway claims you have reached the inactivity timeout even though you just logged in with the Policy Manager.
This issue can occur when session persistence is not configured on your Load Balancer. Either configure session persistence or connect to a specific Gateway node using an IP address, instead of using the cluster hostname.
Problem: Inbound SSL handshake issue #1: Client requires trusted CA Listing
The client requires a Known Trusted CA listing before the client application will send the client certificate to the Gateway.
  • When TLS 1.1 or 1.2 is enabled on the listen port:
    • The Gateway populates the accepted issuers list in the handshake based on the Trusted Certificates stored in properties
  • When only TLS 1.0 is enabled on the listen port:
    • The Gateway can include an accepted issuers list in the handshake if you add
      to the listen port's advanced properties (see "Advanced Properties" in Manage Certificates.
  • For a solution that encompasses all listen ports, set the
    cluster property to a PEM-formatted certificate for the Certificate Authorities, separated by commas.
       <certificate contents>
    -----END CERTIFICATE-----,
       <certificate contents>
    -----END CERTIFICATE-----
    Restart the Gateway for this setting to take effect.
    cluster property is hidden and must be manually typed into Manage Cluster-Wide Properties.
Problem: Inbound SSL handshake issue #2: Connection failure over SSL
The client will not connect to the Gateway over SSL.
Possible causes and solutions:
  • Does the client support the cipher suites set on the listen port? Verify the client support and adjust the listen port as necessary. Cipher suites are defined in the SSL/TLS Settings tab in the Listen Port Properties.
  • Has the CA certificate been added to Manage Certificates and assigned correct usage? If not, client certificate validation will fail.
  • Is the client attempting to connect to the Gateway using SSLv3? The Gateway no longer supports this protocol due to its insecurity. If you must enable this protocol for interoperability with legacy systems, add
    to the listen port's advanced properties (see "Advanced Properties" in Listen Port Properties). 
Problem: Gateway performance issues when using HSM FIPS Level 3
You notice an impact on the cryptographic performance of the Gateway when your Hardware Security Module (HSM) is configured for FIPS Level 3.
If you are experiencing performance issues when using FIPS Level 3:
  1. Locate and open the following file in a text editor:
  2. Add the following Gateway system properties:
  3. Save and exit the file.
  4. Restart the Gateway.