1. Home
  2. GLU.Guide
  3. APIs and Connectors
  4. Adding or Editing Connectors

Adding or Editing Connectors

Step 1: Connector Basic Information

Give a unique Connector Name, this is the name you will see in the connector drop-down list in the Integration builder. Choose Connection Direction, for this example we will configure an OUTBOUND Connector. Select the required Protocol / Connector type from the Protocol list. Provide a Description about the end point which will be connected to.

Choose the Applications (GLU.Engines) that the connector you are creating will be made available to. In the interests of configuration efficiency, in this way as single Connector configuration can be used across any number of GLU.Engines. If you are working on a GLU.Engine that does not have this Connector associated with it, the Connector name will not appear in the Connector drop-down list in the Integration Builder.

Same Env. Host: This setting enables you to indicate that the SOAP WSDL is located in the same Environment as the Host (which is defined at Step 1). Ticking this will ‘grey-out’ the WSDL Location fields. Step 2.3 – SSL: This is where SSL Configuration properties are set for this Connector on the specified Environment. See *SSL Configuration for further detail.

Step 2: Connector Environment Settings

Here for each Environment (selected using the Environments Drop-down list) you need to define the Host Settings, Properties and if applicable the SSL configurations for the Connector. This is where the concept of SDLC Context Awareness comes to the fore. By specifying the Host Details for each Connector and for each Environment (as defined in your SDLC in the Environments Tool), you are ensuring that when you build a GLU.Engine for a specific Environment, it will embed within it all the Host details for the Endpoints applicable only to that stage of your SDLC.

Host Settings

To invoke ‘Step 2’ – click on the Step 2 – Connector Environments Settings button. Select the Environments, that the GLU.Engine will be running in and for each apply the Environment Specific Host Settings within the Host Settings Tab. Enter the URL or IP address for the Connector in the host field. If a Port is required, enter the port in the port field.

The port field defines the API port, which is used to provide access to an the API being configured, it is used to allow initiating systems to interact with the API. Note that this is different to the Server Port which is configured in the GLU.Engine Settings (General Tab) within the Build Manager tool (more detail on it here). The Server Port along with the IP address of the server or Virtual Machine the GLU.Engine is running on it used to access the actual GLU.Engine itself, this may be to access the JMX metrics or to access the GLU.Engine Management API’s.

These details will be embedded in the GLU.Engine at build time. Since these Host Settings are environment specific, when the GLU.Engine is set to a specific Environment e.g. ‘PRE-PROD’ in the example below, the GLU.Engine will direct outbound traffic routed through your connectors to the destinations defined by these Host Settings for the PRE-PROD stage of your SDLC.

For Inbound Connectors, specify the URL / Host internal IP and Port of the server that the GLU.Engine will run on for the specified Environment. For the Inbound connectors both host and port are required. Note that if you set this Host to IP address ‘’ your GLU.Engine will be able to run on any machine, to tighten control of your GLU.Engines though it is recommended that you specify the INTERNAL IP address that the GLU.Engine will be running on in the Host field, doing so means that the GLU.Engine cannot start on any machine that does not use that specified internal IP address. For testing purposes, one can also use ‘localhost’ as the Host which will enable the GLU.Engine to run on your local machine.

For Outbound Connectors, the URL / Host IP and Port will be where the GLU.Engine sends Request messages to.

Read TimeOut: The read timeout is the timeout on waiting to read data. Specifically, if the server fails to send a byte <timeout> seconds after the last byte, a read timeout error will be raised. Read timeouts may occur if the received data payload is huge.

Connection TimeOut: The connection timeout is the timeout in making the initial connection i.e. completing the TCP connection handshake.

Once the connector has been configured, click Submit to complete the Connector configuration. The Connector will thereafter be available on the Connector lists for the GLU.Engines it has been attached to.


This is where Protocol specific Properties are defined – in the example below, since this Connector is configured as a SOAP Connector, the SOAP Properties of relevance are presented. Other Protocols will render the properties applicable in this panel. See the Protocol specific GLU.Guide articles for details on Properties applicable to the specific protocol you are working with.

SSL Configuration

SSL, or Secure Sockets Layer, is a widely-used security protocol that ensures the confidentiality and integrity of sensitive data transmitted over the internet. It uses encryption algorithms to encrypt data in transit, making it unreadable to unauthorized parties, including hackers.

In the context of back-end integration, SSL is often used between a GLU.Engine and an external endpoint system to secure data transmission and protect sensitive information.

TLS (Transport Layer Security) is the updated, more secure version of SSL. Despite this, many SSL certificate providers still refer to their certificates as SSL, but these certificates typically include the most up-to-date TLS encryption standards, including options for ECC, RSA, and DSA encryption.

When integrating systems in the back-end, the use of an SSL certificate indicates the secure transmission of data and protects sensitive information from unauthorized access.

The SSL Tab provides the fields one should populate to configure your Connector SSL settings. These are also environment specific.

2-Way SSL

An SSL Keystore holds the identity key for the server and the SSL Truststore serves as the repository for trusted certificates. The SSL Truststore is used for trusting or authenticating client certificates (for two-way SSL).

2-Way SSL (also known as Mutual SSL or Two-Way Authentication) is a type of SSL/TLS encryption that provides a secure communication channel between two systems by establishing trust in both directions. In a 2-Way SSL scenario, both the client and server must present a certificate to each other during the SSL/TLS handshake. This ensures that both parties are who they claim to be and helps to prevent man-in-the-middle attacks. n this scenario, both the client and server have a unique digital certificate, and the SSL/TLS protocol is used to establish a secure connection between the two systems. The certificates are verified and authenticated by a trusted certificate authority, and the encrypted data is transmitted over the secure connection.

The SSL Keystore is a store of digital certificates used by a client or server to identify itself to the other party during an SSL/TLS handshake. In a 2-Way SSL scenario, both the client and server will have their own SSL Keystore, containing a unique digital certificate. When a client or server connects to the other party, it presents its certificate from the SSL Keystore, allowing the other party to verify its identity.

The SSL Truststore, on the other hand, is a store of trusted digital certificates used to verify the identity of other parties. When a client or server connects to another party, it checks the other party’s certificate against the certificates stored in its SSL Truststore. If the certificate is not present in the SSL Truststore, or if the certificate has been revoked, the connection will be rejected. The SSL Keystore and SSL Truststore work together to establish a secure communication channel in 2-Way SSL.

Use the applicable Keystore and Truststore fields in the SSL Tab on the Connector Environment Settings window to define the Location, Path and Type of each.

In a 2-Way SSL scenario, the SSL certificate that a client or server receives from the other party’s SSL Keystore is the same certificate that the receiving party should have in its SSL Truststore.

When a client or server connects to another party, it presents its certificate from the SSL Keystore. The other party then verifies the certificate against the certificates stored in its SSL Truststore. If the certificate is present and has not been revoked, the connection is established, and the parties can communicate securely over an encrypted channel.

For the connection to be established, it’s important that both parties have each other’s certificates stored in their respective SSL Truststores. This ensures that both parties are who they claim to be and helps to prevent man-in-the-middle attacks.

SSL Config Tools

For SSL configuration the following types of files can be handled by GLU in SSL connections

.p12 / .crt / .pem and .ppk

If these files need to be switched to .jks then the following commands can be used:

Command 1:

$ keytool -v -importkeystore -srckeystore example.p12 -srcstoretype PKCS12 -destkeystore example.jks -deststoretype JKS
  • This command uses the Java keytool utility to import a PKCS12 keystore (example.p12) into a JKS (Java KeyStore) keystore (example.jks). It converts the keystore format from PKCS12 to JKS.

Command 2:

$ keytool -importkeystore -srckeystore example.p12 -srcstoretype pkcs12 -srcalias tomcat -destkeystore exampleCert.jks -deststoretype jks -deststorepass Yvf6K33z6qyuTvnA -destalias tomcat
  • This command also uses the Java keytool utility to import a PKCS12 keystore (example.p12) into a JKS keystore (exampleCert.jks). It specifies an alias (tomcat) for the source keystore and destination keystore, and sets a destination keystore password.

Command 3:

$ keytool -importkeystore -srckeystore example.p12 -srcstoretype pkcs12 -destkeystore exampleCert.jks
  • Similar to the previous commands, this command imports a PKCS12 keystore (example.p12) into a JKS keystore (exampleCert.jks). It does not specify an alias or a destination keystore password, so it might prompt you to enter them interactively.

$ openssl s_client -showcerts -connect https://testapi.example.pl/api:443
  • This command uses OpenSSL to initiate an SSL/TLS connection to the specified server (testapi.example.pl) on port 443 (default HTTPS port) and displays the server’s certificate information. It does not import or manipulate keystore files; instead, it inspects certificates during a secure connection handshake.

The following is as an example of the feedback from a third-party entity regarding a GLU SSL request. In cases where our server require a certificate, the absence of one in the request results in an an SSL error occurs due to the server denying the request. This issue pertains specifically to requests directed to our production environment:

[CN=null][13/May/2020:17:15:18 +0200] – – – – [13/May/2020:17:15:18 +0200] “POST / HTTP/1.1” 200 25405 “-” “Apache-CXF/3.3.5”

For request test:

exampletest == is CN from client cert in logs[11/May/2020:13:06:02 +0200] testapi.example.pl exampletest – – [11/May/2020:13:06:02 +0200] “POST /api HTTP/1.1” 200 674 “-” “Apache-CXF/3.3.5”

Java includes the keytool utility in its releases. Keytool can be used to manage keys and certificates and store them in a keystore. The keytool commands allows one to create self-signed certificates and show information about the keystore.

A keytool command follows the following structure:

keytool -import -noprompt -trustcacerts -alias <AliasName> -file <certificate> -keystore <KeystoreFile> -storepass <Password>

Here is an example:

keytool -import -alias scaPPPPROD2 -keystore ESB-Ext-PPP.jks -file sba.PPPPROD2.cer

This link provides the full set of keytool operations:

In addition to keytool, GLU provides an SSL Tool which can validate your generated .jks vs the intended endpoint. The GLU SSL Tool .jar file is available here:

To use it you need to specify: IP Port Jks location Password

For example: java -jar ssl-0.0.1-SNAPSHOT.jar 8027 certNew.jks changeit

Additional SSL Resources: This link (for Digicert SSL Certs) outlines the steps … typically run by the DevOps Admin responsible for the GLU.Engine VM / Server: https://www.digicert.com/ssl-certificate-installation-java.htm


  1. Receiving System Server generates a certificate request (.csr) using the -certreq command
  2. Initiating System gets this CSR signed (by relevant CSA) and provide a signed certificate (.crt)
  3. Receiving System imports that CRT into their keystore (Java Key Store) (this replaces the self-signed original certificate with a proper signed one)
  4. Receiving System then exports a public key using the -export command (usually .cer)
  5. GLU Config then points to the public key location in the Path (see screenshot above)


  1. If the signing authority is not a standard signing authority (thawte, verisign etc) then you might need to import a root and possibly intermediate signing authority into your Truststore.
  2. If it is a ‘self-signed’ certificate, then Initiating System generated certs need to be loaded into Receiving System Truststore, else you won’t trust the authority that signed the Receiving System cert.
  3. It could be possible that your verisign/thawte/CA certs are outdated, you might need to get them from the CA (certificate authority) and load them into your truststore

The following articles provide guidance on troubleshooting different SSL Connection issues:

Was this article helpful?

Related Articles

Fill the form and we’ll contact you shortly

    I agree with

    We uses cookies to make your experience on this website better. Learn more
    Accept cookies