TLS Securing JetPatch Server and Endpoint Communications

Once a JetPatch Connector is deployed to an endpoint server, it initiates TLS-secured HTTPS communication with the JetPatch Manager if configured to use the Web protocol as means of connector and Manager communication (other options can be configured).  By default, this is TLS 1.2 and this can be configured for TLS 1.3 (with appropriate java version).  Note: We support any ciphers that are supported by the NGINX server.  See https://tecadmin.net/enable-tls-with-nginx/ for more information (/etc/nginx/conf.d/intigua.nginx.conf)

Each connector uses a self-generated identity token to authenticate itself to the JetPatch server. The token is registered once with the server (through the TLS-secured channel), and used from that point on in all communications. The JetPatch server routinely cross-checks this identity token with server meta-information such as MAC addresses, to identify and handle cases where endpoint identity has changed, e.g. when an endpoint has been cloned. In such cases, the JetPatch server may ask the JetPatch Connector to re-establish its identity by registering a new identity token.

The validity of the server certificate used by the JetPatch server is checked by the connector, in order to defend against Man-in-the-Middle (MitM) attacks. To support this, one or more root CA certificates must be provided to the JetPatch Connector during its deployment, upgrade or re-configuration (management service change).   To get this configured on the JetPatch server, see the below steps:

Create Cert and Key

By default, a CA certificate and key are generated and stored in

JetPatch Server - 

/etc/nginx/intigua-sslcert/

JetPatch Proxy - 

/etc/nginx/

If you have more certificates you would like to use in the case of one or more JetAgent proxy servers or a JetPatch Active/Passive architecture, please make sure to have each of the certificate files available in the appropriate /etc/nginx/intigua-sslcert/  (for JetPatch server, both Active/Passive HA) or /etc/nginx/ (for JetProxy server). Each server should have in its directory the certificate files used by this server.

Note: please ensure that the cert files have the proper owner and permission.

sudo chown tomcat.tomcat <cert name>

sudo chmod ug+r <cert name>

However please note that all of the combined certificates should be copied also the JetPatch certificate repository as explained in the next step:
Once the certificate is available in /etc/nginx/intigua-sslcert/ or /etc/nginx/  directories, you also need to edit the Nginx conf file to point to the location of the new certificate (crt and key files): 
JetPatch server or JetPatch (Active/Passive) HA server

/etc/nginx/conf.d/intigua.nginx.conf

Following fields:
ssl_certificate           intigua-sslcert/intigua.crt;
ssl_certificate_key    intigua-sslcert/intigua.key;

JetProxy server:

/etc/nginx/conf.d/intigua.conf

Following fields:
ssl_certificate           intigua.crt;
ssl_certificate_key    intigua.key;  

In the example above, relative pass to intigua-sslcert/intigua.crt and intigua-sslcert/intigua.key or intigua.crt and intigua.key for JetProxy

After copying the required certificate into the relevant servers, it is needed to change the certificates ownerships to tomcat:tomcat - simply run the following command:

chown tomcat:tomcat <cert path>

The certificate repository path is configured in the intigua.properties file with the property certificates.path and has a default value /usr/share/intigua/certs . All certificates, that can be used on some of the manager communication channels (master/slave front-ends, proxies) has to be copied or linked into this location

1. Create a new connector service and enable / disable the following features 
   • Set the parameter 'Verify the JetPatch Manager's SSL Certificate' to True (by default)
   • Verify the certificate's hostname against JetPatch Manager's hostname – not mandatory but can also be set to true if needed and the certificate is issued accordingly.
2. Deploy the JetPatch connector to endpoints. Now, all subsequent deployments will enforce the new certificates. 

Notes:

1. Verify connector protocols 
2. As mentioned above, new certificates can be added to client endpoints by installing a new connector version or by reconfiguring it (changing its management service)
3. Any certificate that is configured on the Manager or JetAgent Proxy requires the nginx service to be restarted, this is done by running the command line:
   'service nginx restart' for RHEL/CentOS 7 and above or 'systemctl restart nginx' for Rhel/Centos 6
4. To disable authentication set the connector parameters to false (turn of the radio button when configuring the JetPatch connector management service).
5. If multiple certificates are transferred to the client endpoints, the JetPatch Connector is built in a way which selects the certificate in an optimized way (it will attempt to use the certificate that worked the last time and only if not successful it will try the next certificate in line).

Communication with Web Clients

The certificate used for the communication with the Connectors is also used for encrypting the traffic to the User Web clients, therefore the above procedure also applies for Web clients.

It is recommended to sign the certificate by trusted authority (CA) to avoid web-browser warning messages or alerts. The default certificate supplied in the JetPatch installation is a self signed certificate.

How to manually change a TLS certificate on the Endpoint (Connector)

This method explains how to push / change a TLS certificate on endpoint servers manually. This method is used for cases such as past-due certificates. When the certificate is past due, there will be no connectivity between endpoint and manager and the only way to restore is would be by manually pushing a new valid certificated to manager server and clients. In cases of certificate replacement when the current is still valid, just add the certificate to the manager path (explained above), create a new management service and deploy to endpoints for JetPatch console. 

Before we start : In the sections below please don't forget to replace the 'INTIGUA_ROOT_DIR_PATCH' to the actual path you are using. 

Default INTIGUA_ROOT_DIR_PATH

• Windows:C:\Program Files\
• Linux: /usr/local/

1. Create new directory named "cert", the new directory path is:

For Windows

 #INTIGUA_ROOT_DIR_PATH\Intigua\vAgentManager\components\cert

For Linux/Solaris:  

#INTIGUA_ROOT_DIR_PATH/intigua/vAgentManager/components/cert

#INTIGUA_ROOT_DIR_PATH\Intigua\vAgentManager\components\cert

#INTIGUA_ROOT_DIR_PATH/intigua/vAgentManager/components/cert

rootCAfilePath: "#INTIGUA_ROOT_DIR_PATH\\Intigua\\vAgentManager\\components\\cert\\certificate.pem"

enableHostVerify: false
hasValidCert: true

rootCAfilePath: "#INTIGUA_ROOT_DIR_PATH/intigua/vAgentManager/components/cert/certificate.pem"

enableHostVerify: false
hasValidCert: true