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.

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 ‘0.0.0.0’ 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.

Properties

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

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


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).

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:

$ keytool -v -importkeystore -srckeystore example.p12 -srcstoretype PKCS12 -destkeystore example.jks -deststoretype JKS

$ keytool -importkeystore -srckeystore example.p12 -srcstoretype pkcs12 -srcalias tomcat -destkeystore exampleCert.jks -deststoretype jks -deststorepass Yvf6K33z6qyuTvnA -destalias tomcat

$ keytool -importkeystore -srckeystore example.p12 -srcstoretype pkcs12 -destkeystore exampleCert.jks

$ openssl s_client -showcerts -connect  https://testapi.example.pl/api:443

The following is an example of the 3rd Party Feedback which can be expected on a GLU SSL request there is no cert in request- when we require it (force) you have ssl error because our server deny requestFor this request to Prod: 

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

For request to Test: 

exampletest == is CN from client cert in logs[11/May/2020:13:06:02 +0200] testapi.example.pl exampletest 196.44.38.170 - - [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:

https://docs.oracle.com/en/java/javase/13/docs/specs/man/keytool.html


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:
https://s3.console.aws.amazon.com/s3/object/glu.capetown/GLU.Public.Shared.Folder/ssl-0.0.1-SNAPSHOT.jar?region=af-south-1

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

For example: java -jar ssl-0.0.1-SNAPSHOT.jar 10.156.145.123 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

Steps:

  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)

Notes:

  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 troubleshoot different SSL Connection issues: https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html

https://gist.github.com/4ndrej/4547029

https://www.digicert.com/ssl-certificate-installation-java.htm

Was this article helpful?

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill the form and we’ll contact you shortly

    I agree with

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