Connector Communication
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 in NGINX for TLS 1.3 (with appropriate java version).
ssl_protocols TLSv1.2 TLSv1.3;
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.
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:
Communication with Web Clients and Certificate Configuration
In addition to securing communication between the JetPatch Manager and Connectors, the same certificate is also used to encrypt traffic between the JetPatch Manager and web clients. This ensures that all communication remains protected through HTTPS, even if a browser displays a warning or error regarding the certificate.
By default, the JetPatch installation provides a self-signed certificate. While this secures the communication, web browsers typically flag self-signed certificates as untrusted, leading to warning messages or alerts. This does not compromise the encryption but may cause usability concerns.
Steps to Resolve Browser Certificate Warnings
To prevent browser warnings and ensure smooth interaction:
1. Generate a Certificate on the JetPatch Application Machine:
- Use the JetPatch server to create a .key file for a locally generated certificate.
- This certificate can then be signed by a trusted Certificate Authority (CA) or signed using openssl.
2. Sign the Certificate by a Trusted CA:
- Having the certificate signed by a trusted CA ensures that it is recognized by web browsers without additional configuration.
- This is the recommended approach for enterprise environments.
3. Use a Locally Generated Certificate:
- If a CA-signed certificate is not feasible, the locally generated certificate can still be used effectively.
- To avoid browser warnings, this certificate must be installed on the client machine where the web browser is running.
- On Windows, use the MMC console to add the certificate to the “Trusted Root Certification Authorities” store.
Securing Communication with Modern Web Browsers
Modern browsers such as Chrome and Edge enforce stricter SSL security standards compared to older browsers like Internet Explorer. Specifically, they require the SSL certificate to include a DNS name entry in the Subject Alternative Name (SAN) field. If the SAN field is missing, the certificate is flagged as invalid or insecure, even though communication remains encrypted.
To address this issue and ensure smooth access to the JetPatch web interface, follow these steps:
1. Generate a New Self-Signed Certificate with a SAN Entry
When creating the certificate, ensure the DNS name (e.g., yourdomain.com) is included in the SAN field. This can be achieved using tools like OpenSSL or PowerShell.
Here’s an example using OpenSSL:
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout selfsigned.key -out selfsigned.crt -config <(
cat <<-EOF
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
CN = yourdomain.com
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = yourdomain.com
EOF
)
2. Additional Configuration for Locally Generated Certificates
If you opt for a self-signed certificate without a trusted CA:
Install the self-signed certificate on the client machine where the browser is running.
- On Windows, use the MMC console to add the certificate to the Trusted Root Certification Authorities store.
Recommended Best Practice
For seamless use across multiple browsers and machines, it is strongly recommended to have the certificate signed by a trusted Certificate Authority (CA). This ensures recognition by browsers without requiring local installation on each client.
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.
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
-
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.
- Deploy the JetPatch connector to endpoints. Now, all subsequent deployments will enforce the new certificates.
Notes:
- Verify connector protocols
- 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)
- 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 - To disable authentication set the connector parameters to false (turn of the radio button when configuring the JetPatch connector management service).
- 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).
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
2. FTP the certificate to this path :
For Windows
#INTIGUA_ROOT_DIR_PATH\Intigua\vAgentManager\ components\cert
For Linux/Solaris:
#INTIGUA_ROOT_DIR_PATH/intigua/vAgentManager/components/cert
3. Change the new certificate name to "certificate.pem"
4. Update config file: add new entries to csclient.cfg file (Intigua/vAgentManager/
For Windows
rootCAfilePath: "#INTIGUA_ROOT_DIR_PATH\\Intigua\\vAgentManager\\ components\\cert\\certificate. pem"
enableHostVerify: false
hasValidCert: true
For Linux / Solaris
rootCAfilePath: "#INTIGUA_ROOT_DIR_PATH/intigua/vAgentManager/components/cert/certificate. pem"
enableHostVerify: false
hasValidCert: true
5. Delete csclient.cfg.bin file (Intigua/vAgentManager/
6. Restart the connector
Comments
0 comments
Please sign in to leave a comment.