Author: Purnima Kesanur (puk@softwareag.com)
Version: 10.4
This article describes how to secure API Gateway and its components using HTTPS.
#How Do I Secure API Gateway Server Communication using HTTPS?
#Creating a Custom Keystore with Self-Signed Certificates
#How do I Secure API Gateway User Interface Communication using HTTPS?
#How do I Secure API Gateway Data Store Communication using HTTPS?
#Configuring Search Guard with self-generated certificates
#How do I Secure the TLS Configuration in API Gateway?
#How do I Configure a Secure Communication Channel between API Gateway and API Portal?
Overview
SSL creates a secure connection between servers and clients over the web and internal network, safeguarding sensitive data for secure transmission. The Hypertext Transfer Protocol Secure (HTTPS) is an internet communication protocol that protects the integrity and confidentiality of data between the user's computer and the site. The data sent over HTTPS is secured using SSL/TLS, which provides protection using encrypted channels.
The API Management setup comprises various components, such as, API Gateway server, API Gateway UI, Elasticsearch, API Portal, Kibana, and Terracotta. You must create secure connections between these components in order to enable a secure channel of communication. This article explains how to enable SSL support for the components of an API Management setup.
This article assumes that you have API Gateway advanced edition of version 10.2 or later installed. Additionally you have a basic understanding of the following:
- API Gateway and its related components like the user interface (UI)
- API Gateway administration configurations
- Java security using keystore and truststore certificates
The following figure illustrates the full HTTPS configuration in an API Management setup.
For ensuring the security of the data being transferred between two components, you can implement one-way or two-way SSL/TLS. In an API Management setup two-way SSL/TLS can be implemented for secure communication between the following components:
- API Gateway server and client
- API Gateway server and Elasticsearch
- API Gateway UI and API Portal
How Do I Secure API Gateway Server Communication using HTTPS?
Secure API Gateway server, a component in an API Management setup, to enable the other components in the API Management setup to communicate with the API Gateway server over HTTPS. This use case explains how to secure API Gateway server communication using HTTPS protocol by using the existing server and client certificates.
The use case starts when you have an API Gateway instance to be secured using HTTPS and you have the required server and client certificates to secure the communication channel between API Gateway server and other components. It ends when the secure channel is configured for communication between API Gateway server and the other components.
Before you begin
Ensure that you have:
- API Gateway administrator privileges
- Required client and server certificates
To configure the API Gateway server for secure communication
- Ensure that the keystore and truststore with the required certificates are located at
Installation_Dir\common\conf
.
for details on how to create a keystore and generate the required self-signed certificate. - API Gateway UI.
This is required to set up a secure outbound communication from the API Gateway server to the client.- Log on to the API Gateway user interface.
- Navigate to Administration > Security > Keystore/Truststore.
- Click Add keystore.
- Provide the following details:
- Alias: A text identifier for the keystore file. The alias name can contain only alphabets, numbers, and underscores. It can not include a space, hyphen, and special characters.
- Select file: Browse and select the file https_keystore.jks file located at
Installation_Dir\common\conf
. - Password: Specify the password for the saved keystore file associated with this alias.
- Type: Specify the certificate file format of the keystore file, which, by default, is JKS for keystores.
- Click OK.
A warning appears, prompting you to create a password for the key alias. - Close the warning.
The Update keystore dialog box appears. - Provide the password for the https_keystore file, for example, manage.
- Click Save.
- Click Add truststore.
- Provide the following details.
- Name: A name for the truststore file.
- Upload truststore file: Browse and select the https_truststore.jks file located at
Installation_Dir\common\conf
. - Password: Specify the password that is used to protect the contents of the truststore.
- Click Save.
- In the Configure keystore and truststore settings section, provide the details of keystore and truststore configured.
- Click Save.
API Gateway, by default, uses the configured keystore and truststore files for keys and certificates for any in and out HTTPS communication.
- Create an HTTPS port in API Gateway and associate the keystore and truststore aliases.
This is required to set up the inbound communication.
- Navigate to Administration > Security > Port.
- Click Add ports, and select HTTPS as the port type.
- Click Add.
- Provide the following details
- Port: Specify the port number you want to use for the HTTPS communication.
- Alias: Specify an alias for the port that is unique for this API Gateway instance. The alias must be between 1 and 255 characters in length and include one or more of the following: alphabets (a -z, A-Z), numbers (0-9), underscore (_), period (.), and hyphen (-).
- Backlog: Specify the number of requests that can remain in the queue for an enabled port before API Gateway begins rejecting requests. The default is 200. The maximum value is 65535.
- Keep-alive timeout: Specify when to close the connection if the server has not received a request from the client within this timeout value (in milliseconds) or when to close the connection if the client has explicitly placed a close request with the server.
- In the Listener-specific credentials section provide the following information:
- Keystore alias: Select HTTPS_KEYSTORE.
- Key alias(signing): Select https_keystore.
- Truststore alias: Select Truststore.
- Click Add.
The HTTPS port 8886 is added and displayed in the list of ports.
- Enable the new port 8886 by clicking the X mark in the port's Enabled column.
The port 8886 is now enabled and the API Gateway server is now ready to accept requests over HTTPS port 8886.
- Set the port 8886 as a primary port by clicking in the port's Primary port column.
The port 8886 is now set as the primary port and the port 5555 is no more the primary port.
-
Disable the port 5555 by clicking the tick mark in the port's Enabled column.
The default primary port 5555 that accepts requests on HTTP is now disabled.
- Configure the API Gateway UI to access the API Gateway server securely.
- Open the file uiconfiguration.properties located in the folder
Installation_Dir\profiles\IS_default\apigateway\config\
. - Modify the following properties:
#IS properties apigw.is.base.url = https://localhost:8886 apigw.is.rest.directive = /rest apigw.user.lang.default = en
Here we configure the HTTPS port 8886 in the base URL property to point the API Gateway to communicate to the server URL.
- Open the file uiconfiguration.properties located in the folder
You now have a secure communication channel established between the API Gateway server and the client.
Creating a Custom Keystore with Self-Signed Certificates
You have to perform this procedure if your organization does not have policies and procedures in place regarding the generation and use of digital certificates and certificate chains, including the use of certificates signed by a CA but want to generate a self-signed certificate and import them into the Keystore and truststore.
- Create a new keystore with a self-signed certificate.
- Run the following command, and provide the keystore password (for example, manage) and the other required details to generate a new key and store it in the specified keystore https_keystore.jks.
keytool -genkey -v -keystore https_keystore.jks
-alias HTTPS_KEYSTORE -keyalg RSA -keysize 2048 -validity 10000
Example:
- Run the following command and provide the keystore password (for example, manage) to export the certificate from the keystore https_keystore, and place it in a specified location.
keytool -exportcert -v -alias HTTPS_KEYSTORE -file
Installation_Dir\common\conf\https_gateway.cer -keystore
Installation_Dir\common\conf\https_keystore.jks
Example:
The certificate https_gateway.cer is exported from the keystore https_keystore and placed in the location Installation_Dir\common\conf\.
- Run the following command, and provide the keystore password (for example, manage) and the other required details to generate a new key and store it in the specified keystore https_keystore.jks.
- Create a truststore and import the generated certificate.
- Run the following command to create a truststore file and import the generated certificate into the truststore file.
keytool -importcert -alias HTTPS_TRUSTSTORE -file Installation_Dir\common\conf\https_gateway.cer -keystore Installation_Dir\common\conf\https_truststore.jks
Example:
A truststore file https_truststore.jks is created with the imported certificate.
You can now view the keystore and truststore files created and located at Installation_Dir\common\conf\.
- Run the following command to create a truststore file and import the generated certificate into the truststore file.
How do I Secure API Gateway User Interface Communication using HTTPS?
Secure API Gateway UI (web application), one of the API Gateway components in an API Management setup, to enable users to access the API Gateway UI securely over HTTPS. This use case explains how to secure API Gateway communication using HTTPS protocol.
The use case starts when you have an API Gateway instance with API Gateway UI that needs to be secured using HTTPS where you are using existing certificates to secure the communication channel between API Gateway UI and the clients(browsers). It ends when the secure channel is configured for communication between the API Gateway UI and the client.
Before you begin
- You must have API Gateway administrator privileges.
- You must have the required client and server certificates.
To configure API Gateway user interface for secure communication
- Ensure that the server certificates and client certificates are located at
Installation_Dir\common\conf
.Note: If you want to use a custom keystore with self-signed certificates, see #Creating a Custom Keystore with Self-Signed Certificates for more details on how to create a keystore and generate the required self-signed certificate. - Configure the keystore and the HTTPS port on which you want to expose API Gateway UI.
- Navigate to
Installation_Dir\profiles\IS_default\configuration\com.softwareag.platform.config.propsloader
and open the property file com.softwareag.catalina.connector.https.pid-apigateway.properties. - Modify the following properties by providing the keystore, passsword, and port details.
keystoreFile=generated_keystore_file_path/https_keystore.jks port=9073 (https port in which you want to expose webApp) @secure.keystorePass=password (password used while creating the keystore file)
- Navigate to
For details of the configurations, refer the following:
- https://documentation.softwareag.com/webmethods/wmsuites/wmsuite10-5/Cross_Product/10-5_Software_AG_Infrastructure_Administrators_Guide.pdf
- https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
How do I Secure API Gateway Data Store Communication using HTTPS?
API Gateway Data Store is the default data store for API Gateway. You can secure API Gateway Data Store (a simple Elasticsearch instance), one of the components in an API Management setup, to communicate securely over HTTPS. This use case explains how to secure Elasticsearch using Search Guard, an Elasticsearch plugin, that offers encryption, authentication, and authorization to protect data from attackers and other misuses. Search Guard secures Elasticsearch by exposing it over HTTPS, and enables basic authentication by configuring users.
The use case starts when you have an API Gateway instance that uses API Gateway Data Store as the default data store, and you want to secure the communication channel between API Gateway Data Store and other components using HTTPS. It ends when the secure channel is configured for communication between Elasticsearch and other components.
Before you begin
Ensure that you have:
- A basic understanding of API Gateway and its communication with API Gateway Data Store for storing data.
- A basic understanding of Kibana and its communication with API Gateway Data Store for rendering the dashboards in API Gateway.
To secure API Gateway Data Store communication using HTTPS
- Install and initialize the Search Guard plugin.
- Shutdown API Gateway.
- Navigate to Installation_Dir\InternalDataStore\bin and open the file
enable_ssl.bat
. Comment out the last line as shown.
- Click Save.
- Copy the folder sagconfig from Installation_Dir\IntegrationServer/instances\Instance_name\packages\WmAPIGateway\config\resources\elasticsearch to Installation_Dir\InternalDataStore.
- Copy the certificates node-0-keystore.jks and truststore.jks from Installation_Dir\InternalDataStore\sagconfig to Installation_Dir\InternalDataStore\config.
- Navigate to Installation_Dir\InternalDataStore\config\ and open the file elasticsearch.yml.
- Delete all the properties that start with searchguard, if present, and add the Search Guard properties as follows:
searchguard.ssl.transport.keystore_type: JKS searchguard.ssl.transport.keystore_filepath: node-0-keystore.jks searchguard.ssl.transport.keystore_alias: cn=node-0 searchguard.ssl.transport.keystore_password: a362fbcce236eb098973 searchguard.ssl.transport.truststore_type: JKS searchguard.ssl.transport.truststore_filepath: truststore.jks searchguard.ssl.transport.truststore_alias: root-ca-chain searchguard.ssl.transport.truststore_password: 2c0820e69e7dd5356576 searchguard.ssl.transport.enforce_hostname_verification: false searchguard.ssl.transport.resolve_hostname: false searchguard.ssl.transport.enable_openssl_if_available: true
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_type: JKS
searchguard.ssl.http.keystore_filepath: node-0-keystore.jks
searchguard.ssl.http.keystore_alias: cn=node-0
searchguard.ssl.http.keystore_password: a362fbcce236eb098973
searchguard.ssl.http.truststore_type: JKS
searchguard.ssl.http.truststore_filepath: truststore.jks
searchguard.ssl.http.truststore_alias: root-ca-chain
searchguard.ssl.http.truststore_password: 2c0820e69e7dd5356576
searchguard.ssl.http.clientauth_mode: OPTIONAL
searchguard.authcz.admin_dn:“CN=sgadmin”
- Save and close the file.
- Run Installation_Dir\InternalInternalDataStore\bin\enable_ssl.bat,
This installs the Search Guard plugin and starts the API Gateway Data Store.
- Shutdown and restart the API Gateway Data Store.
- Navigate to Installation_Dir\InternalDataStore\plugins\search-guard-2\tools and run the following command to initialize the API Gateway Data Store.
sgadmin.bat -cd ..\..\..\sagconfig\
-ks ..\..\..\sagconfig\sgadmin-keystore.jks
-kspass 49fc2492ebbcfa7cfc5e -ts ..\..\..\sagconfig\truststore.jks
-tspass 2c0820e69e7dd5356576 -nhnv -p 9340 -cn SAG_EventDataStore
For details on all the Search Guard properties, see #Search Guard Properties.
- Add users for basic authentication.
- Navigate to Installation_Dir\InternalDataStore\sagconfig and open the sg_roles_mapping.yml file.
- Add the username (for example, TestUser) in the users list as follows:
sg_all_access: users: - Administrator - 'CN=demouser' - TestUser
- Generate the hash code for your password.
- Run Installation_Dir\InternalDataStore\plugins\search-guard-5\tools\hash.sh.
- Type the password.
- Press Enter.
This generates the hash code.
- Navigate to Installation_Dir \InternalDataStore\sagconfig and open the file sg_internal_users.yml.
- Add the username and password as follows:
#keys cannot contain dots #if you have a username with dots then specify it with username: xxx Administrator: hash: $2a$12$sm2AEpQx6QNq6YRSYHGCnetiRWKMWrQY/udSSI0dDFZ1r3qo51bzK
CN=demouser:
hash: $2a$12$.sbt5vK0AiBOmQ9hVyFK.sR55dx.7NJGSdP1YEqPUXHZKHZBRuoOTestUser:
hash: $2a$12$Ua1gUiWaW5/b8ohgDqTfg.ruEDNOCsuV9RexlTigNf65TvSn6/Loy - Run the command sgadmin.bat to initialize the Search Guard plugin.
- Shutdown and restart the API Gateway Data Store once the Search Guard plugin is initialized.
API Gateway Data Store now runs on a secure channel on the HTTPS port and requests the basic authentication details.
-
Change the Kibana configuration to connect to Elasticsearch.
- Navigate to Installation_Dir\profiles\IS_default\apigateway\dashboard\config\ and open the file, kibana.yml.
- Uncomment the following properties and update them as follows:
- elasticsearch.username: TestUser
- elasticsearch.password: TestUser@123
- elasticsearch.ssl.verificationMode: certificate
- elasticsearch.ssl.certificateAuthorities: file path of your root-ca.pem certificate
- elasticsearch.url: https://hostname: 9240
Sample kibana.yml file
- Change the API Gateway configuration to connect to Elasticsearch.
- Navigate to Installation_Dir\IntegrationServer\instances\default\packages\WmAPIGateway\config\resources\elasticsearch and open config.properties file.
- Uncomment the following properties and update them as follows:
- pg.gateway.elasticsearch.http.username=TestUser
- pg.gateway.elasticsearch.http.password=TestUser@123
- pg.gateway.elasticsearch.https.truststore.filepath=Installation_Dir/InternalDataStore/sagconfig/truststore.jks
- pg.gateway.elasticsearch.https.truststore.password=2c0820e69e7dd5356576
- pg.gateway.elasticsearch.https.enabled=true
- Start the API Gateway Data Store manually.
- When API Gateway Data Store is up and running, start the Kibana server manually by running the kibana.bat file located at Installation_Dir/profiles\IS_default\apigateway\dashboard\bin.
- Start API Gateway.
You can now log on, create APIs, and access the Analytics page with the user credentials.
Configuring Search Guard with self-generated certificates
As an API Provider, if you want to generate your own certificates to use with Search Guard instead of the default certificates that are shipped with API Gateway, you can configure Search Guard with user-generated certificates as Step 5. Search Guard provides an offline TLS tool. Use the tool to generate the required certificates for running Search Guard in a production environment.
- Configure Search Guard with user-generated certificates.
- Download the tool zip file from https://search.maven.org/search?q=a:search-guard-tlstool
- Create a YAML file at Tool Installation Directory\config
When you run the TLS tool command, it reads the node and certificate configuration settings from this YAML file, and places the generated files in a configured directory.
Sample YAML file
-
Run the following command to generate the required certificates.
Tool Installation Directory/tools/sgtlstool.bat -c ../config/Demo.yml -ca -crt
The generated certificates are placed in the Tool Installation Directory/tools/out folder.
- Copy the certificates listed below from the folder Tool Installation Directory/tools/out to the Installation_Dir/EventDataStore/config folder.
- test-node-1.key
- test-node-1.pem
- test-node-1_http.pem
- test-node-1_http.key
- test-client.pem
- test-client.key
- root-ca.pem
- root-ca.key
- Configure the generated certificates in the API Gateway Data Store elasticsearch.yml file.
- Start API Gateway Data Store manually.
A log message warns that the Search Guard is not initialized after API Gateway Data Store is up because the Search Guard is not initialized with the latest certificates - Open a command prompt and change the directory to Installation_Dir\EventDataStore \plugins\search-guard-5\tools.
- Run the command
sgadmin.sh -cd ..\sagconfig -nhnv -icl -cacert ..\..\..\config\root-ca.pem -cert ..\..\..\config\test-client.pem -key ..\..\..\config\test-client.key -keypass your certificate password -p 9340
Done with success log message appears. - Shut down and restart API Gateway Data Store.
API Gateway Data Store now uses the generated certificates for SSL communication.
Search Guard Properties
Property | Description |
---|---|
TRANSPORT ( 2-way authentication is enabled by default) | |
|
Type of keystore. Possible values: JKS, PKCS12 |
|
Location of the keystore. |
|
Keystore entry name if there are more than one entries. |
|
Password to access keystore. |
|
Type of truststore. Possible values: JKS, PKCS12 Default value: JKS |
|
Location of the truststore. |
|
Truststore entry name if there are more than one entries. |
|
Password to access truststore. |
|
If true, the hostname mentioned in certificate is validated. Set this as false if you are using the general purpose self signed certificates. Possible values: true, false Default value: true |
|
If true, the hostname is resolved against the DNS server. Set this as false if you Note: This is applicable only if the property Possible values: true, false |
|
Use if OpenSSL is available instead of JDK SSL. Possible values: true, false Default value: true |
HTTP | |
|
Set this to true to enable SSL for a REST interface ( HTTP). Possible values: true, false Default value: true |
|
Type of keystore. Possible values: JKS, PKCS12 Default value: JKS |
|
Location of the keystore. |
|
Keystore entry name if there are more than one entries. |
|
Password to access keystore. |
|
Type of truststore. Possible values: JKS, PKCS12 Default value: JKS |
|
Location of the truststore. |
|
Truststore entry name if there are more than one entries. |
|
Password to access truststore. |
|
Option to enable two-way authentication. Possible values:
|
Search Guard Admin | |
|
Search Guard maintains all the data in the index searchguard. This is accessible to only users ( client certificate passed in sdadmin command) configured here. |
|
All certificates used by the nodes at the transport level need to have the oid field set to a specific value. Search Guard checks this oid value to identify if an incoming request comes from a trusted node in the cluster or not. In the former case, all actions are allowed. In the laer case, privilege checks apply. Additionally, the oid is also checked whenever a node wants to join the cluster. Default value: '1.2.3.4.5.5' |
|
Index where all the security configuration is stored. Currently, non-configurable. Default value: searchguard |
How do I Secure the TLS Configuration in API Gateway?
Securing the TLS configuration in API Gateway involves securing the TLS configuration for API Gateway server ports
and API Gateway UI ports.
To secure TLS configuration in API Gateway
- Secure the TLS configuration of the API Gateway server ports.
- Restrict the TLS version by adding the following setting:
watt.net.jsse.server.enabledProtocols=TLSv1.2
This specifies the SSL protocol versions that API Gateway supports when acting as a server handling inbound requests. Java Secure Socket Extensions (JSSE) is required to support TLS 1.1 or 1.2. For more information about configuring portsnto use JSSE, see https://documentation.softwareag.com/webmethods/integration_server/pie10-5/10-5_Integration_Server_Administrators_Guide.pdf - Reject the client initiated renegotiation by adding the following line to the custom_wrapper.conf file located in the directory SAG_root/profiles/IS_default/configuration.
wrapper.java.additional.402=-Djdk.tls.rejectClientInitiatedRenegotiation=TRUE
- Specify a list of secure cipher suites.
For details about the recommended cipher suites, see the cipher suite recommendation by IANA organization or the https://documentation.softwareag.com/webmethods/integration_server/pie10-5/10-5_Integration_Server_Administrators_Guide.pdf. - Set the size of Ephemeral Diffie-Hellman Keys to 2048 depending on the configured cipher suites. You can do this by adding the following line to the custom_wrapper.conf file located in the directory SAG_root/profiles/IS_default/configuration:
wrapper.java.additional.401=-Djdk.tls.ephemeralDHKeySize=2048
- Restrict the TLS version by adding the following setting:
- Secure the TLS configuration of the API Gateway UI ports.
- Enable TLSv1.2 by adding the following line to the properties file com.softwareag.catalina.connector.https.pid-apigateway.properties located in the directory SAG_root/profiles/IS_default/configuration/com.softwareag.platform.config.propsloader.
sslEnabledProtocols=TLSv1.2
- Specify a list of secure cipher suites by adding the following line to the properties file com.softwareag.catalina.connector.https.pid-apigateway.properties located in the directory SAG_root/profiles/IS_default/configuration/com.softwareag.platform.config.propsloader.
ciphers="List of Secure Cipher_Suites"
For details about the recommended cipher suites, see the cipher suite recommendation by IANA organization (https://ttps://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml ) or the https://documentation.softwareag.com/webmethods/integration_server/pie10-5/10-5_Integration_Server_Administrators_Guide.pdf. - Set the size of Ephemeral Diffie-Hellman Keys to 2048 depending on the configured cipher suites. You can do this by adding the following line to the custom_wrapper.conf file located in the directory SAG_root/profiles/IS_default/configuration:
wrapper.java.additional.401=-Djdk.tls.ephemeralDHKeySize=2048
- Enable TLSv1.2 by adding the following line to the properties file com.softwareag.catalina.connector.https.pid-apigateway.properties located in the directory SAG_root/profiles/IS_default/configuration/com.softwareag.platform.config.propsloader.
You can verify the resulting TLS configuration using tools such as testTLS.sh that checks for vulnerable TLS configurations.
How do I Configure a Secure Communication Channel between API Gateway and API Portal?
API Portal is a web-based, self-service portal that enables an organization to securely expose APIs to external developers, partners, and other consumers to help them build their own applications on their desired platforms. You can secure API Portal, a component in an API Management setup, to enable secure communication with the API Gateway instance over HTTPS. This use case explains the steps required for API Gateway to securely communicate with API Portal for sending the runtime events and metrics and API Portal to communicate with API Gateway securely for key requests.
The use case starts when you API Portal as one of the components, in the API Management setup, to securely communicate with the API Gateway instance using HTTPS. It ends when the secure communication channel is configured between the API Gateway instance and API Portal.
Before you begin
Ensure that you have:
- API Portal 10.2 or later installed
- A basic understanding of API Portal
- The required certificates for API Gateway and API Portal
To configure a secure communication channel between API Gateway and API Portal
- Configure API Portal as a destination on the HTTPS port.
- Navigate to Administration > Destinations in the API Gateway user interface.
- Click API Portal > Configuration.
- Provide the following information:
- In the Portal configuration section, provide the following details:
- Base URL: The API Portal base URL which API Gateway uses to communicate to API Portal using the HTTPS port. By default, API Portal uses port 18102 for HTTPS communication.
- Username and Password credentials to access API Portal.
- In the Gateway configuration section, provide the following details:
- Base URL: The API Gateway server URL, which API Portal uses to communicate to API Gateway using the HTTPS port. Specify the port 8886 that is configured for HTTPS communication.
- Username and Password credentials to access API Gateway.
- In the Portal configuration section, provide the following details:
- Click Publish.
This configures API Portal as a destination and creates a communication channel between API Gateway and API Portal over the HTTPS port.
- Ensure that the keystore and truststore with the required certificates for API Gateway are located at
Installation_Dir\common\conf
. - Ensure that the keystore and truststore with the required certificates for API Portal are located at
Installation_Dir\ API_Portal\server\jre\lib\security
.
You now have a secure communication channel between API Gateway and API Portal. You can now publish an API, which is enforced with Enable HTTPS/HTTPS policy with the HTTPS option configured, from API Gateway to API Portal and invoke the API from API Portal using the HTTPS endpoint that has been used to publish it to API Portal.
Further read:
Learn how to secure API Gateway and its components using HTTPS: Securing API Gateway and its components using HTTPSRead on the steps needed to follow to secure APIs using SSL certificate in API Gateway: webMethods.io API Gateway: Securing APIs using SSL Certificate