添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
相关文章推荐
刚毅的硬币  ·  Day 31 - 使用 Amazon ...·  昨天    · 
气宇轩昂的铅笔  ·  Build a gRPC API ...·  5 天前    · 
坏坏的丝瓜  ·  Known Issues·  1 周前    · 
一身肌肉的钥匙扣  ·  在Spring webflux ...·  1 周前    · 

Known Issues

This topic describes known issues in version 10.1 of the gateway, with workarounds if available.
This topic describes known issues in version 10.1 of the
Layer7 API Gateway
, with workarounds if available.

Policy Manager

Versions 10.0 CR4 and Older of the Policy Manager Cannot Start Up for Specific Gateway Versions
Issue
: Users planning to use version 10.0 CR4 or older of the Policy Manager will not be able to start the application up if Gateway 10.0 CR5+ or 10.1 CR1+ was installed first. The JDK that comes with Gateway version 10.0 CR4 or older by default creates the truststore in JKS format.  The JDK that comes with Gateway version 10.0 CR5 or newer, however, creates the truststore using the PKCS12 format.  All Policy Managers installed on the computer read from the same truststore file. Older versions of the Policy Managers cannot open PKCS12  formatted truststores. (DE542879)
Workaround
: Should you require both Gateway 10.1 and 10.0 versions of the Policy Manager on the same computer, use version 10.0 CR5 or newer of the Policy Manager. This allows the Policy Manager to read truststores in both the JKS and PKCS12 formats.
Alternatively:
  1. Export the certificates in the Policy Manager's "trustStore" file located in the .l7tech folder.
  2. Delete the trustStore contained in the .l7tech folder.
  3. Install an updated version of the Policy Manager (i.e., version 10.5 CR5 or newer) and migrate the certificates from the old truststore to the new one.
Browser-Based Gateway Backups No Longer an Option on the Policy Manager
Issue
: The option to use browser-based administration to perform Gateway backups was removed from the Policy Manager due to the deprecation of the Policy Manager browser client. (DE509146)
Workaround
: If a browser or web-based method is required for a Gateway backup, users are advised to use RESTMAN to enable this option.
To enable browser-based administration via RESTMAN:
Determine whether an existing HTTPS port (8443 or 9443) already has browser-based administration enabled with the following command:
https://<Gateway Hostname>:8443/restman/1.0/listenPorts GET
If enabled, you should see a 'Browser-based administration' line as shown in the following sample output:
<l7:EnabledFeatures> <l7:StringValue>Published service message input</l7:StringValue> <l7:StringValue>Administrative access</l7:StringValue> <l7:StringValue>Browser-based administration</l7:StringValue> <l7:StringValue>Built-in services</l7:StringValue> </l7:EnabledFeatures>
If it is not included in the HTTPS port, you will need to add the following line to the 'EnabledFeature' section of the listenPort bundle XML:
<l7:StringValue>Browser-based administration</l7:StringValue>
After editing the bundle XML, submit the edited bundle to update the listenPort entity. Once enabled, you may use the browser-based backup method.
Published Service Properties Dialog Opens Slowly Using Java Web Start Policy Manager
Issue:
When using the Java Web Start version of the Policy Manager Published Service Properties dialog for the first time takes much longer than expected. (DE326621)
Workaround:
None. The browser client needs to download additional .jar files upon first invocation of the Published Service Properties dialog. Subsequent opening returns to normal speed.
Policy Manager Startup Takes A Long Time for New User
Issue:
When a new user is created and assigned various different roles, it may take up to 30 minutes for the User to log in to the Policy Manager, compared to the usual startup time for an Admin User (around a couple of minutes). (DE222762) (DE413957)
Workaround:
The following procedure can be used to reduce the roles items of a user, which may improve the speed and performance of permission validation:
  1. Create a new security zone . Two new roles will become available:
    • View X Zone
    • Manage X Zone
  2. Assign all the entities which should be available for a group of users (for example, developers) to this security zone.
  3. Do one of the following:
    • Only assign View/Manage X Zone roles to the user role.
    • Create a new group, assign View/Manage X Zone roles as well as other necessary predefined roles to this group. Only assign this new group to the user role.
  4. Disable auto-assign roles by setting these cluster-wide properties, to ensure the number of roles for a user does not automatically increase:
    rbac.autoRole.managePolicy.autoAssign=false rbac.autoRole.manageProvider.autoAssign=false rbac.autoRole.manageService.autoAssign=false
Policy Manager Does Not Display Correctly
Issue:
The Policy Manager may not display correctly on some high resolution monitors. If you experience display problems such as small fonts and illegible lines, try overriding the high DPI scaling behavior of the executable file. (DE211450)
Workaround:
See procedure to override high DPI scaling behavior in the Troubleshooting section in Start the Policy Manager .
Adding/Removing io.httpMaxConcurrency Cluster Wide Property Causes Error
Issue
: Adding a new value to or removing the
io.httpMaxConcurrency
cluster wide property causes a "Connection to the Gateway has been broken" error message and then closes the Policy Manager. The
io.httpCoreConcurrency
cluster wide property is also affected. (DE555513)
Workaround
: None. Despite the error and shutdown of the Policy Manager, changes to the cluster wide property is saved and can be verified by the user when they restart the Policy Manager to inspect the changes.
Resolution Failure for Published URI with Special Characters When Case Sensitivity is Disabled
Issue
: When the Resolution paths are case sensitive option is disabled, the service is unable to resolve a published URI containing special characters.
Workaround
: None.

Integrations and Cloud

Luna HSM: Patch Required for Importing Private Keys Generated by OpenSSL with PSS 256
Issue
: Applies to Luna HSM Gateway users with version 10.2 of the Luna client installed. Users may see a 'java.security.KeyStoreException' error message when attempting to import private keys generated by OpenSSL with PSS 256. (DE504253)
Workaround
: If the ability is to import a key generated by OpenSSL with PSS256 is required, Luna HSM users must contact Thales support for instructions to install a Luna patch for a fix.
Manage Keystore - Unable to Set Preference to Use the SafeNet HSM For Cryptographic Operations
Issue
: Affects Luna SafeNet HSM customers who have installed Luna client version 10.2 on their machines running Gateway version 10.0 CR 3. When enabling or connecting to the SafeNet HSM with the Manage Keystore function of the Policy Manager, the 'Prefer to use this device for all cryptographic operations' check box cannot be selected as an option. The purpose of selecting this option is to ensure that all cryptographic operations are performed on the Luna HSM appliance itself.
Workaround
: None.
nShield HSM - Cannot Access Policy Manager When Level 3 (Strict) FIPS Mode is Enabled
Issue
: Impacts nShield HSM users (running nShield client version 12.60.x or newer with Gateway version 10.0 CR3 or newer installed) who require their HSM to operate in FIPS 140-2 Level 3 mode. Users are unable to log into the Policy Manager due to a SSLHandshakeException error caused by a known Java defect . (DE498599)
Workaround
: Users requiring to run their nShield HSM in FIPS 140-2 level 3 should NOT upgrade their Gateway version to 10.0 CR3 or newer until further notice.
Key Generation Fails with Luna HSM
Issue:
When Private Key Properties ). (DE305070, DE314879)
Workaround:
Use a key type other than the "Elliptic Curve" key types.
Dependency Errors When Deleting OAuth Folder
Issue:
Deleting an OAuth policy that contains encapsulated assertions trigger dependency errors in the Policy Manager. These errors cannot be acknowledged in bulk nor can the deletion be canceled. (DE222685)
Workaround:
To avoid this, see "Problem: Deleting OAuth policy creates dependency errors" in Troubleshoot: Problems and Solutions .
Siteminder Cluster-Wide Property Validation Warning
The cluster-wide property validation type for the siteminder.session.generateCookieString was set incorrectly and you will see this WARNING message when Gateway starts. "WARNING 973 com.l7tech.util.ConfigFactory$DefaultConfig: Ignoring unknown type '(?i)true|false' for validation of property ‘siteminder.session.generateCookieString’". This should not cause any functionality issue.
Upgrading Gateway in Azure with an Azure MySQL Database Causes Syntax Error
Issue
: Some customers report receiving the following error when upgrading their Gateway with an Azure MySQL database:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '@'localhost'' at line 1.
(DE399413)
Workaround
(Updated on September 12, 2022):
  1. Backup your Azure MySQL database.
  2. In privileged shell, enter the following command:
    /opt/SecureSpan/JDK/bin/java -jar /opt/SecureSpan/Gateway/runtime/lib/liquibase-#.#.#.jar --driver=com.mysql.jdbc.Driver --classpath=/opt/SecureSpan/Gateway/runtime/lib/mysql-connector-java-#.#.##.jar --changeLogFile=/opt/SecureSpan/Gateway/config/etc/db/ssg.xml --url=jdbc:mysql://gatewaydb.mysql.database.azure.com:3306/ssgvortx --username='vadmin@gatewaydb' --password='x' update
    • If you are using liquibase-4.#.# or a newer, ensure that the forward slash is added to the classpath parameter:
      --classpath=/opt/SecureSpan/Gateway/runtime/lib/mysql-connector-java-#.#.##.jar:
      /
    • See next section to learn which versions of the Liquibase (liquibase-#.#.#.jar) and MySQL connector drivers (mysql-connector-java-#.#.##.jar) you should use.
    A 'Liquibase Update Successful' message should be returned.
  3. To confirm that the Gateway version has been upgraded to 10.1, enter the following in MySQL:
    select * from ssg_version
    For example, if version 10.1.00 is not returned for current_version, then enter the following:
    update ssg_version set current_version = '10.1.00';
Liquibase and MySQL Connector Driver Versions
Depending on your Gateway version, ensure that the correct driver versions are used for Liquibase and MySQL connector. While the following table offers a guide to help you quickly locate the correct Liquibase and MySQL connector driver versions for current releases of the Gateway as of this writing, for future releases of the Gateway, you can look up their versions in the following folder:
/opt/SecureSpan/Gateway/runtime/lib/
10.0 GA
liquibase-3.2.2.jar
mysql-connector-java-5.1.46.jar
10.0 CR1
liquibase-3.2.2.jar
mysql-connector-java-5.1.46.jar
10.0 CR2
liquibase-3.2.2.jar
mysql-connector-java-5.1.46.jar
10.0 CR3
liquibase-3.2.2.jar
mysql-connector-java-5.1.46.jar
10.0 CR4
liquibase-3.2.2.jar
mysql-connector-java-5.1.49.jar
10.0 CR5
liquibase-3.2.2.jar
mysql-connector-java-5.1.49.jar
10.1 GA
liquibase-3.10.1.jar
mysql-connector-java-5.1.46.jar
10.1 CR1
liquibase-4.5.0.jar
mysql-connector-java-8.0.26.jar
10.1 CR2
liquibase-4.5.0.jar
mysql-connector-java-8.0.26.jar
Cloud Foundry Installations of Container Gateway Show Error logs at Startup
Issue
: During Gateway startup, logs regarding the initial configurations of Gateway are shown as ERR on Cloud Foundry. (DE359636)

Database

Gateways Using MySQL 8.0.27 or Newer with Replication Enabled: 'Too Many Connections' or Unresponsive Error
Issue
: Applies to version 10.x Gateways with MySQL version 8.0.27 or newer installed (MySQL 8.0.27 was included in the Gateway October 2021 MPP). When replication is enabled, users may encounter a 'too many connections' or unresponsive error when attempting to log into MySQL. This issue stems from a new default multithreading replication setting for MySQL  8.0.27+. (DE526480)
Workaround
: The February 2022 Monthly Platform Patch has resolved this issue. For more information, see the Knowledge Base article here .
Liquibase Database Exception Causing Database Schema Upgrade Failure
Issue
: Some users are reporting the following error when attempting to upgrade their MySQL database schema as part of a Gateway upgrade (DE490936):
Migration failed for change set upgrade_x.y.z.xml::create_published_service_properties::gateway: Reason: liquibase.exception.DatabaseException: Error executing SQL CREATE TABLE ssg_testUpgrade.published_service_property (published_service_goid BINARY(16) NOT NULL, name VARCHAR(128) NOT NULL, value MEDIUMTEXT NOT NULL): Table 'published_service_property' already exists
Workaround
: The workaround consists of several steps. You will compare the DATABASECHANGELOG entries with entries belonging to another baseline Gateway of the same version. If there isn't another existing Gateway database available to serve as a baseline for comparison, you'll need to install a new Gateway in a different server (separate from the production server) for this purpose. For example, if you’re upgrading from version 9.4 to 10.0 of the Gateway, perform a fresh installation of Gateway version 9.4 in a separate server. Next, compare the DATABASECHANGELOG table from the freshly installed SSG Gateway version 9.4 database with the one from the Gateway that is experiencing upgrade difficulties:
On both Gateway MySQL databases, run:
# use ssg; # select count(*) from DATABASECHANGELOG;
If the returned count numbers differ between the two databases, it’s likely the DATABASECHANGELOG was corrupted in the problematic/production Gateway.
You’ll want to rectify this by copying the change log entries from the database of a baseline Gateway or freshly installed Gateway and replacing the log entries from the database of the problematic Gateway:
  1. Backup the production database which contains the Gateway schema you wish to upgrade.
  2. On the baseline or fresh installation of the Gateway of the same version, run the following command:
    # mysqldump ssg DATABASECHANGELOG > /home/ssgconfig/dbchangelog_rows.sql
  3. Open
    dbchangelog_rows.sql
    and locate the following line:
    INSERT INTO 'DATABASECHANGELOG' VALUES (...);
  4. Copy the entire line including the contents inside (...).
  5. Stop the production Gateway before making changes to the database:
    # service ssg stop
  6. From the MySQL client, run:
    # use ssg; # delete * from DATABASECHANGELOG;
  7. Paste the
    INSERT INTO ‘DATABASECHANGELOG’ VALUES (...) ;
    line into the command line to run.
  8. Run the following command to save your changes to the production database that you are upgrading:
    # commit;
  9. Restart the production Gateway with the following command:
    # service ssg start
  10. Continue to upgrade the production database schema using the SSG Config Menu as before.

Encryption

TLS 1.3 Post-Handshake Authentication Not Supported
Issue
: TLS 1.3 post-handshake authentication is not supported by the Gateway for both inbound and outbound traffic due to a documented JDK limitation . (DE504887)
Workaround
: Because there are no future plans for JDK to support post-handshake authentication, Gateway users are advised to either disable post-handshake authentication from the client/back-end side OR use TLS 1.2 instead for Gateway message routing.
Obsolete Elliptical Curve (EC) Key Support Phased Out from Gateway Message Routing
Issue
: Certain EC keys deemed as obsolete or weak by Java can no longer be used for Gateway message routing purposes. For example, the following EC keys are now considered obsolete:
  • sect163k1
  • sect193r1
  • k-163
  • p-224
Attempting to use these keys may yield an "Unable to obtain HTTP response" error. (DE507971)
Workaround
: Users are advised to choose current/stronger EC keys instead. You can learn more about deprecated/obsolete EC keys via OpenJDK documentation here:
Gateway Now Uses SunJSSE TLS Provider: Increased Time for Authentication Bind Operation
Issue:
Impacts all Gateway form factors that perform LDAP authentication. Beginning with Gateway version 9.2, SunJSSE became the primary TLS provider, which is used by LDAP user authentication when the Gateway communicates with an LDAP provider over a secure network. Unlike previous TLS providers (i.e., the deprecated FIPS/BSAFEJSSE), LDAP binds performed by SunJSSE require a full TLS handshake for each LDAP user. This process adds approximately
100 ms to the LDAP authentication bind for each user
when compared to the same process for Gateway version 9.1. (DE474013)
Workaround:
The Gateway provides authorization caching of previously completed or successful binds.To reduce the performance impact of the full TLS handshake for repeat binds against the same user, the authorization cache size and storage of successful binds may be increased:
  • authCache.successCacheSize (default is 2000)
  • authCache.maxSuccessTime (default is 60000 ms)
Both properties can be configured as Gateway Cluster Wide Properties - see Credential Caching Cluster Properties for more information.
The optimal size of the cache is dependent on the size of your LDAP user base. Note that the cache success will not take into account of users changing passwords or being disabled on the LDAP server while success is cached.
Private Key is Created without Special Purpose When Loaded from Bootstrap/Bundle Folder or Sent to RESTman Endpoint
Issue:
When trying to create a private key with a defined special purpose in a RESTman bundle via the bootstrap/bundle folder of the Container Gateway, that private key is created but without the special purpose (e.g. Default CA). (DE320421)
Retrieving Certificate When Gateway in FIPS Mode
Issue:
The Add Certificate Wizard fails to retrieve a third-party certificate using the “Retrieve via SSL Connection (HTTPS or LDAPS URL)" option if the Gateway is in FIPS mode (cluster property
security.fips.enabled
= true). (DE211158)
Workaround:
  1. Retrieve or download the certificate file using external means. For example, you can use this OpenSSL command:
    # echo | openssl s_client -connect host.host:port 2>/dev/null | openssl x509 -outform PEM > cert.pem
  2. Import the certificate to the Gateway by navigating to
    Tasks > Certificates, Keys, and Secrets > Manage Certificates > Add > Import from a file
Cannot create or import private key with same subject DN when public certificate data is different
Issue:
Gateway does not allow creation or import of private keys with the same subject DN and different public certificate, even when a different alias is provided.
Workaround:
When the public certificate is the same, a private key can be imported even if it leads to multiple keys with same subject DN (for example, same cert with new chain). You can choose to update certificate chain for list of multiple keys through ‘Confirm Replace Certificate Chain’ prompt.

Assertion Operations

Execute JavaScript Assertion: Read Error When Attachment is Stored on Disk
Issue:
Some Gateway users have reported that the Execute JavaScript assertion cannot access attachments when they are stored on disk because the assertion lacks file permissions. The issue occurs for messages exceeding the
attachment.diskThreshold
cluster property value.
Workarounds:
Two main workarounds have been identified for mitigating the issue:
  • Firstly, users can adjust the
    attachment.diskThreshold
    cluster property to a value higher than the default 1048576 bytes, ensuring that attachments remain in memory and bypass the permission error.
  • Alternatively, for significantly larger attachments surpassing the disk threshold, users can implement a grant permission statement within the ssg.policy file. This amendment facilitates unimpeded access for the JavaScript assertion to the attachment stored on disk, thereby averting permission-related errors during processing. To implement the statement:
    1. Edit the ssg.policy file:
      # nano /opt/SecureSpan/Gateway/runtime/etc/ssg.policy
    2. Add the following grant statement to the file:
      grant { permission java.io.FilePermission "/opt/SecureSpan/Gateway/node/default/var/attachments/*", "read,write"; Reference: Oracle Documentation
    3. Restart the Gateway.
Connection Error in Connect To Outbound WebSocket Assertion
Issue:
During the end-to-end connection upgrade process, and right after the outbound connection is succeeded, Gateway shows the following error message from backend (outbound): (DE467783)
com.l7tech.external.assertions.websocket.server.WebSocketOutboundHandler: Failed to send message to inbound: Message could not be delivered, connection no longer available.
Workaround:
You will not see this issue once the end-to-end connection upgrade is completed.
Context Variable ${request.time} Returns Incorrect Time When Used in Encapsulated Assertions
Issue:
When
${request.time}
is used in the underlying ("backing") policy of an encapsulated assertion , it returns an incorrect value.
(DE305223)
JSON Path Assertion Returns Error With Null Value
Issue
: When evaluating a JSON expression with a value of
null
(case-sensitive), the assertion fails. (DE384413)
Workaround
: Use the JSON Path Expression V2 assertion.
Multi-Valued Variable Error with Look Up Item by Value Assertion
Issue:
The Look Up Item by Value Assertion fails if a multi-valued variable contains the same value multiple times. (DE305234)
For example:
Set Context Variable fave as String to: banana Set Context Variable fruits as String to: apple,banana,pear,banana Split variable fruits into fruitsalad on "," Look Up Item by Value: find item ${fave} within ${fruitsalad}; output index to ${index} Return Template Response to Requestor -- ${index}
This fails to return "1,3". However, in the ssg_0_0.log file, a similar INFO entry to the following is logged:
com.l7tech.external.assertions.xmlsec.server.ServerIndexLookupByItemAssertion: 6: More than one value was matched. Exception caught!
Workaround:
Use the following sample workaround policy:
To use the workaround policy:
  1. Download the .xml file to your computer.
  2. Click
    Import Policy
    on the Policy Tool Bar to import the policy into the Policy Manager. For more information, see Importing a Policy from a File .
Perform JDBC Query Assertion Error When Using Hyphen in Procedure Name
Issue:
When setting up a Perform JDBC Query Assertion , using hyphen in the stored procedure name will fail the query, as it does not comply with JDBC's naming conventions. (DE309730)
Workaround:
Do not use hyphen in the procedure name.
Route via HTTP(S) Assertion Unexpected Failure
Issue:
The [Other] tab in the HTTP(S) Routing Properties contains the control "Never fail as long as target returns an answer". There is a known issue that can still cause the assertion to fail even when an answer is returned under the following scenario:
  • In the [Security] tab, the Service Authentication is “Use HTTP Credentials from Request”.
  • The backend services return a 401 HTTP error. (DE215522)
Workaround:
To prevent assertion failure in this scenario, use “Specify HTTP Credentials” as the Service Authentication method instead. Specify the username and password as context variables from the request (for example,
${request.username}
,
${request.password}
).
Connection Timeout During SSH Routing
Issue:
When the "SFTP" protocol is selected in the Route via SSH2 Assertion , the connection timeout is twice as long as the value specified in the assertion. (DE215650)
Workaround:
Reduce the timeout to one half the desired value.
Duplication of Request Cookie Header in Gateway Response of Route via HTTP to Assertion
Issue:
Gateway Upgrade to 10.1 CR2 causes the Route via HTTP to Assertion to duplicate the cookie header, resulting in backend server failure.
Workaround:
User can disable the
com.l7tech.server.policy.assertion.ServerHttpRoutingAssertion.statePool.enable
system property in the
/opt/SecureSpan/Gateway/node/default/etc/conf/system.properties
file to avoid duplication of cookie header in response. If this system property is not available in the file, you can add it and disable it by setting its value to false.
XML Canonicalization Has Changed for Gateway 10.1 CR2: Absolute Namespace URIs Must Be Used
Issue
: Some Gateway users who have published a web service containing Canonical XML transformation may experience the following error when a client attempts to make a request with XML within the body:
org.apache.xml.security.c14n.CanonicalizationException: Element <element name> has a relative namespace: ...
Because Gateway 10.1 CR2 was given a more secure XML messaging Java library upgrade, moving forward and following current XML messaging standards (see W3C Canonical XML Version 1.1 ), the use of relative namespace URIs for XML canonicalization has been removed. (DE545801)
Resolution
To resolve this, users must use an absolute namespace URI instead when accessing the
requestXpath.element
variable that results from specifying XPaths for assertions such as ' Evaluate Request XPath '.
For example, instead of using a relative URI such as
alpha/beta/charlieservice
, use the absolute URI,
http://delta.org/alpha/beta/charlieservice
, instead.
Other result variables like
requestXpath.result
and
requestXpath.elements
(plural) are strings and don't cause this error (i.e. does not use XML canonicalizer).
Workarounds
These workaround options apply if you are not immediately able to adopt the use of absolute namespace URIs for Gateway requests. Choose the one that works for your scenario.
[Workaround Option A]
Use the ' Evaluate Regular Expression ' assertion to extract the problematic element. For example, the following regular expression is used to extract the 'HeaderData' element:
<HeaderData(.*)<\/HeaderData>
See the Regular Expression Properties screenshot for reference.
[Workaround Option B]
If possible, use the
requestXpath.elements
(plural) result variable instead; however, this may return more than one matching result depending on your expected request data.
Complex Mutation Failures Influence Rollback
Issue:
With failures of complex mutation requests, rollback may not perform as planned (where full entity details are included for response.)
Workaround:
Avoid using complex fields such as policy dependencies(all Dependencies, direct Dependencies), p12 of key type and so on in mutation responses.
Connection Policy Does Not Support HTTP Call Before Websocket Outbound Connection Call
Issue:
When an HTTP request from WebSocket Inbound Connection policy is made prior to Websocket Outbound connection call, the Connection Policy reports an error. (DE558542)
Workaround:
The error is caused by an incorrectly configured response message from the websocket inbound connection policy. Within the websocket inbound connection policy, avoid utilizing the global response message as a destination. For example, customize the response destination of the HTTP(S) Routing assertion within the websocket connection policy.
Apply JSON Transformation Assertion: Boolean Values Returned as String
Issue
: Applies to Gateway version 11.0 CR2 and 10.1 CR4. When the Apply JSON Transformation assertion is used for converting XML to JSON, a conversion issue arises when handling XML attributes containing boolean values (true or false). In such instances, the conversion process encloses quotes around the boolean value, treating it as a string. (DE585801)
Workaround
: This issue is scheduled to be addressed in a future release of the Gateway. A hotfix is currently available upon request to provide an immediate solution - please contact Layer7 support for more information.

System Administration

System Reboot Issues
Issue:
Gateway node sometimes takes a longer time to boot up after applying a patch.
Workaround:
To improve system reboot time, follow these steps for each Gateway node:
  1. Take a snapshot of your VM.
  2. Run the following commands in the same order as mentioned below:
    # cd /etc/rc.d/init.d
    # ./layer7-run-once-on-boot
    This command might take a few minutes to execute.
    # reboot -n
Your Gateway node boots up quickly. Repeat this task for every node in the cluster.
CentOS 7 Issues
Gateway version 10.0 supports the CentOS 7 platform. The following are known Gateway issues related to the CentOS 7 platform.
Update my.cnf File to Fix Issue with mysqld Generating Error Logs
Issue:
In Layer7 API Gateway 10.0 OVA installation, mysql error logs are generated in
/var/log/messages
instead of
/var/log/mysqld.log
as defined in the
my.cnf
file.
Reason:
In CentOS 7, systemd manages MySQL server startup and shutdown.
[mysqld_safe]
is not installed as it is not needed. Some parameters are defined in the
[mysqld_safe]
section in
my.cnf
file such as log file path and pid-file. So it might seem like mysqld is not generating error logs.
Workaround:
Edit the
my.cnf
file and move all the content from
[mysqld_safe]
section to
[mysqld]
section. Restart the MySQL server.
Ensure that you overwrite the
pid-file
parameter line. If there are multiple entries in the
[mysqld]
section for a parameter, then only the last line is prioritized and earlier entries are ignored.
AMI Gateways: Network Service Showing a 'Failed' Status
Issue:
AMI Gateway (version 10.0) customers may report seeing a failed status for their network service when viewing the summary of network devices and their connection status: Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface eth0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device eth0 does not seem to be present, delaying initialization. Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: [FAILED] Dec 04 10:23:44 ip-111-11-11-111.broadcom.internal network[967]: Bringing up interface ssg_eth0: [ OK ]
Workaround:
None required. Due to the predictable network interface naming scheme introduced by CentOS 7, the AMI network service will first look for "eth0" when it should be looking for "ssg_eth0", the new name that was given by Gateway. As long as the service is able to verify the existence of "ssg_eth0" with an OK status, no actual system failure will occur despite the initial FAILED status associated with "eth0". (DE441402)
Cloned OVAs Require Manual Patching
Issue:
After cloning a Gateway OVA (version 10.0), the Gateway administrator is unable to SSH into it. Newly deployed clones will have different network adapter hardware addresses, causing the VM to create their own unique network interface names with the predictable device naming scheme. Because of the name conflict between the original OVA and the clone, the firewall rules in the iptables prevents the user from accessing OVA clones via SSH. This issue is known for the Gateway OVA that runs on CentOS 7. (DE441413)
Workaround:
Customers planning to clone Gateway OVAs should do the following:
  • Disable iptables/ip6tables services prior to cloning.
  • After cloning the OVAs, ensure that the interfaces identified in the network configuration files (i.e., ifcg files) are aligned with the interface names that appear in the iptables/ip6tables. You may use the
    nmcli
    command as part of your reconfiguration. See the following procedure as an example.
To change a device name from ens160 to ssg_eth0 on a cloned OVA:
  1. Log into the cloned OVA as a root user in console.
  2. List the available connections to the Gateway with the following command:
    nmcli connection show
    Two connections should be displayed:
    • One connection with a NAME of 'ssg_eth0' without a DEVICE assigned.
    • Another connection with a NAME of 'Wired connection 1' with DEVICE 'ens160' assigned. Your machine/setup may use a different DEVICE name.
  3. Delete the connection without a DEVICE assigned (i.e., ssg_eth0) with the following command:
    nmcli connection delete ssg_eth0
    You may verify the update with the
    nmcli connection show
    command.
  4. Update the connection with the ens160 DEVICE assigned with the following command (use the appropriate DEVICE name that suits your machine and setup):
    nmcli connection modify "Wired connection 1" 802-3-ethernet.mac-address "$(cat /sys/class/net/ens160/address)" con-name "ssg_eth0" ifname "ssg_eth0"
    The connection with the NAME 'Wired connection 1' and assigned DEVICE of 'ens160' is renamed to NAME 'ssg_eth0', but DEVICE is still assigned as 'ens160'
    You may verify the update with the
    nmcli connection show
    command.
  5. Reboot the OVA with the
    reboot
    command and log back into the cloned OVA again as a root user.
  6. List the latest connections with the
    nmcli connection show
    command to verify that the connection with the 'ssg_eth0' NAME is now assigned with the 'ssg_eth0' DEVICE.
  7. Turn on iptables.
  8. You should now be able to successfully SSH into the cloned OVA.
The Exited Status: What It Means for Gateway-Related System Services
Issue:
Previously, in CentOS/RHEL 6, init scripts were used to start and stop services. Under systemd, these scripts have been replaced with systemd service units; more importantly, the newly introduced 'exited' status is unique to systemd and may cause confusion if you are new to CentOS 7. For example, if you are checking the status of a service and want to know if it's running, you may come across the
Active: active (exited);
status, as opposed to
Active: active (running)
. This usually means that systemd executed the commands specified in the service unit file but cannot verify if the process is actually running because an associated daemon that monitors that process was not found. Because Gateway does not use a daemon, you may see this status when checking or running services in CentOS 7. (DE437214)
Workaround:
None required.
False Warning Messages in Gateway Log
Issue:
The Gateway log contains a warning similar to the following:
WARNING 1 com.l7tech.server.policy.PolicyCacheImpl: 3255: Policy "Google Auth Code Extension" (#d095d9a4c56c975b34c64db5a6741dd0) contains an unlicensed assertion: Unknown assertion: RetrieveOAuth2Token
The RetrieveOAuth2Token assertion is part of the OAuth Toolkit, which requires no special license. Only the standard Gateway license is required.  (DE317426)
Workaround:
None required. The RetrieveOAuth2Token assertion is indeed present and functioning normally. The erroneous log message is caused by internal timing issues during the license check stage of Gateway startup. You may safely ignore this log message.
File Permissions After a Restore
Issue:
Some file permissions may not be correctly restored after a Gateway is restored using the
ssgrestore.sh
command. This results in the Policy Manager being unable to connect to the Gateway. (DE221036)
Workaround:
See "Problem: Gateway is not running properly after a restore" in Troubleshoot the Gateway .
Manage Roles Performance Issues
Issue:
Performance and speed of Manage Roles may be impacted when many (> 500) custom roles are created, and each role has numerous (200 to 300) permissions. (DE326081)
Workaround:
Avoid excessive number of roles and permissions.
Migration Issue Between Gateways
Issue:
Migration issues may occur after upgrading. Release 9.1 introduces a new "gateway-hazelcast" FIREWALL_RULE. This rule is automatically added to the Gateway upon restart, if it does not already exist. This entity is created with a unique ID per Gateway. If you attempt a bundle import, the mapping for the "gateway-hazelcast" FIREWALL_RULE must be "MapBy:name" to prevent a 409 conflict. (DE211367)
Workaround:
Modify the bundle file that is created during bundle export as follows:
Locate this line:
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE"/>
And then modify it as follows:
<l7:Mapping action="NewOrExisting" srcId="
<unique_ID>
" srcUri="http://
<IP_address>
:8080/restman/1.0/firewallRules/
<identifier>
" type="FIREWALL_RULE"> <l7:Properties> <l7:Property key="
MapBy
"> <l7:StringValue>
name
</l7:StringValue> </l7:Property> </l7:Properties> </l7:Mapping>
Cluster Passphrase Is Invalid After Upgrading to Gateway Version 10.1
Issue
: Affects Appliance Gateway 10.1 users. Some users have reported that after migrating to Gateway version 10.1 from 9.4, the cluster passphrase from the source Gateway is no longer valid in the new Gateway. (DE550173)
If the cluster passphrase contains ‘>’, ‘<’, or ‘&’ reserved XML characters, a web service converts them to their respective HTML entity equivalents (i.e., &gt;, &lt;, or &amp) in node.properties. This conversion occurs prior to the encryption and saving of the passphrase in node.properties. As a result, the decrypted cluster passphrase will not match the original passphrase.
Workaround
: If this issue occurs, use the SSGCONFIG menu > 4) Change the Layer7 API Gateway cluster passphrase option to change the actual passphrase containing the ‘>’, ‘<’ or ‘&’ characters.
When prompted to “Enter the cluster passphrase or 'quit' to quit", specify the actual passphrase that includes the characters '>', ", or '&'. If you encounter an incorrect cluster passphrase error, replace the characters with their entity equivalents.
So if the existing passphrase is:
pa$$phrase>
Enter the passphrase with the entity character substitute:
pa$$phrase&gt;
Next, when prompted for the new cluster passphrase, enter the actual ‘>’, ‘<’, and ‘&’ characters as required. This ensures that the correct cluster passphrase is saved as intended in node.properties.

Miscellaneous

java.net.SocketException Error Occurs When SSL Debug is Enabled
Issue
: Users may see the following stack trace when SSL debug logging is enabled on the Gateway:
Logger.java:765|SSLSocket duplex close failed ( "throwable" : { java.net.SocketException: Socket is closed at java.net.Socket.shutdownInput(Socket.java:1539) at com.l7tech.common.io.SocketWrapper.shutdownInput(Unknown Source) at sun.security.ssl.BaseSSLSocketImpl.shutdownInput(BaseSSLSocketImpl.java:218) at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:643) at sun.security.ssl.SSLSocketImpl.bruteForceCloseInput(SSLSocketImpl.java:598) at sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:558) at sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:471) at com.l7tech.common.io.SSLSocketWrapper.close(Unknown Source) at com.l7tech.server.tomcat.c.close(Unknown Source) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:329) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748)}
This issue is caused by the Java Development Kit (JDK), as documented here , and occurs in Java 11. (DE494717)
Workaround
: None. A fix will not occur until the Gateway moves to the next long-term release of JDK after Java 11.
Context Variables with ${service.*} Prefix Have a Global Scope
Issue:
Context variable that have the prefix "service" results in a globally scoped variable, instead of the local scope as expected. (DE293047)
Examples:
  • The value for context variable ${service.AAA} set in a global policy can be retrieved from the service policy. The expected result is that the variable is empty when access from the service policy.
  • The value for context variable ${service.BBB} set in the underlying policy fragment for an encapsulated assertion can be retrieved from the service policy. Assuming the variable is not configured to be returned as a parameter, the variable should be empty when accessed from the service policy.
Workaround:
Use a prefix other than "service" if you do not want the context variable to have a global scope.
Exceptions Being Thrown by Gateway When 'Sending Reply to Specified Queue' is Used
Issue
: Gateway is throwing exceptions when using the 'Sending Reply to Specified Queue'  Inbound option for MQ 8.0. (DE386344)
Occasional Outbound JMS Request Processing Error
Issue:
There is a known issue with NamingException where outbound JMS messages are not processed correctly and returned the following error:
com.l7tech.server.policy.assertion.ServerJmsRoutingAssertion: 4: Error in outbound JMS request processing: Something already bound at (queue-name). Exception caught!
However when the messages are reprocessed, they behave as expected. (DE304792)
Multiple private keys with same subject DN after upgrade from 9.4.00
When upgrading from 9.4.00, the Gateway may have numerous private keys with the same subject DN, regardless of whether the certificate data is identical or not. Private keys with the same subject DN could not be created in 9.4.00, but they could be imported if you assign them a unique alias.
When upgrading from 9.4.00 to 10.1.00, the existing keys are unchanged. And additional Keystore procedures needs to be performed before importing the keys.
For example, if you want to import a key that has the same subject DN as multiple existing keys; you must delete all keys that have matching subject DNs, with the exception of those that have the same certificate data. However, after an import a prompt to update the existing keys' certificate chain with the one from the key to be imported gets displayed.
Existence of the Same Subject DN in the Key Store Fails Creation of a New Private Key.
Issue:
Replace the existing root certificate with a new one of the same name. When a user creates a new private key and signs it with a new root certificate, the expiration date indicates that it is still signed with the previous root certificate. (DE373185)
Workaround:
Create a new private key with the same Subject DN as a signer certificate from another key in the keystore's certificate chain. Remove the certificate chain from the certificate that has to be re-signed. The user can now create a new certificate with the same Subject DN, sign it, and replace the certificate chain.
Removed Root Certificate is Utilized to Sign a New Private Key
Issue:
When a user creates a signer using the same Subject DN, the user receives the old root signer certificate details with the new key. (DE324395)
Workaround:
To replace the certificate chain, the user should first renew the CSR for the previous key(s) that were signed by the older key with the same SubjectDN as the new Signer key, and sign it with a new signer. Once all the older keys are up to date, then the new key can be signed with the new signer.
Creation of New Signer with Old Signers Subject DN
Issue:
If a private key that was used to sign other keys is deleted, any keys with the same subjectDN of the deleted key in their certificate chain must also be deleted, else the certificate will remain in the database. (DE337781)
Workaround:
The workaround for this issue is the same as the defect “Removed Root Certificate is Utilized to Sign in a New Private Key”. The new fix eliminates the need for customers to delete the older private key, which was offered as a workaround in prior versions of Gateway and resulted in downtime for customers.
Intermediate Certificates Does Not Upload Correctly
Issue:
The certificate chain is referenced by other private keys, so the update is reflected incorrectly. (DE330274)
Workaround:
The workaround for this issue is the same as the defect ‘Removed Root Certificate is Utilized to Sign in a New Private Key’.
Import a New Key with Same Subject DN as the Intermediate Certificate
Issue:
The older certificate chain will be used to import a new key when it has the same Subject DN as the Intermediate certificate. (DE464166)
Workaround:
The workaround for this issue is the same as the defect ‘Existence of the Same Subject DN in the Key Store Fails Creation of a New Private Key’.
Incorrect Encoding of the "|" Character
Issue
: When a request parameter includes "|" character and template.MultivalueDelimiter is set to "|", the "|" character gets encoded to "\\\".  (DE560987)
Workaround
: Add a space after the "|" or any other special character to act as the multi-value delimiter. You can also use the new template.escapemultivaluedelimeter cluster-wide property to decide whether the delimiter in the response should be escaped.