This applies as of PRTG 23.4.91 and Multi-Platform Probe 0.19

What is TLS and why is it necessary?

Transport Layer Security (TLS) is a protocol that provides various security features for network communication. As of Multi-Platform Probe 0.19 and the accompanying NATS server, TLS is enforced for all connections to prevent any unsecure setups.

Using TLS with the Multi-Platform Probe ensures certain security measures are in place:

• Encryption of all data during transfer
• Integrity of the transferred data
• Prevention of machine-in-the-middle attacks

Requirements

Additional Information:

• All Multi-Platform Probe components require certificates and keys in the PEM format. Common file extensions include .pem, .crt, .cer, and .key.

How to obtain the necessary certificates

Option 1: Your organization already has a certificate issued by a public CA

If your organization already purchased a certificate from a public CA, use it to issue a new certificate for your server. Make sure the new certificate is issued for the hostname or IP address which the clients will use to connect to the NATS server.

In this case, you will not need to distribute the CA certificate to the clients, since public CAs are available by default on almost all systems.

Option 2: Your organization already has its own internal root CA

If your organization is using an internal root CA, use it to issue a new certificate for your server. Make sure the certificate is issued for the hostname or IP address which the clients will use to connect to the NATS server.

In this case you’ll only need to distribute the CA certificate to the clients if your internal systems do not come pre-installed with your internal CA.

Option 3: Create your own self-signed certificate and CA

If neither option 1 or 2 are available to you, follow the steps below to create a self-signed server certificate and CA.

Note: All files created using the steps below are found in the directory where you run the commands. At the end of certificate creation, you will have the following files:

• The CA certificate: ca.crt
• The CA private key: ca.key
• The server certificate: server.crt
• The server private key: server.key

Be aware that on Windows, the certificate files might be listed as ca with file type Security Certificate. All other files created during certificate creation can be discarded.

Step 1: Obtain SSL

Linux

Most Linux distributions come with OpenSSL pre-installed. Run openssl version in a terminal to check for its availability. If it is not available, refer to your distributions documentation on how to install it. On Debian for example, it will look like this:

sudo apt install openssl

Windows

For Windows there is no official distribution of OpenSSL, but there are two alternatives:

1. If you are using a package manger like Scoop, Winget or Chocolatey, install the openssl package from there.
2. You can install OpenSSL through any of the OpenSSL distributions links listed in the OpenSSLWiki: Binaries. By default, OpenSSL is saved in your Program Files. Once you have successfully downloaded OpenSSL, you can run the commands from your Windows Terminal or cmd.

Step 2: Generate your own CA

This step will generate the required the CA certificate (ca.crt) and CA certificate key (ca.key) files. Once created, you can use these to create additional server certificates, so we recommend you keep both files in a safe place for future use.

openssl req -x509 -nodes -newkey rsa:4096 -sha256 -subj "/CN=Example_CA_Name" -keyout ca.key -out ca.crt -days 36500

Replace Example_CA_Name with the name of your choice. This name will be publicly available, so we do not recommend using any sensitive information. The resulting CA certificate will be valid for 10 years.

Step 3: Generate the server certificate

1. Create a Server Private Key (server.key) and a Certificate Signing Request (CSR) (server.csr) with the following command: openssl req -nodes -newkey rsa:4096 -sha256 -keyout server.key -out server.csr -subj "/CN=example.com"

Replace example.com with the host name or domain of your NATS server.

2. Specify Subject Alternative Names

Subject Alternative Names (SANs) are used to specify additional host names for a single certificate. These must be written to a configuration file. List all the addresses you will use to connect to the NATS server separated by a comma.

• DNS names must be prefixed with DNS:
  • Hostnames (DNS:localhost)
  • Domains (DNS:example.com)
  • Subdomains (DNS:nats.example.com)
  • Wildcard subdomains (DNS:*.example.com - Matches all subdomains of example.com)
• IP addresses must be prefixed with IP:
  • IPv4 (IP:192.0.2.0)
  • IPv6 (IP:::1)

Linux echo “subjectAltName=DNS:localhost,DNS:example.com,DNS:nats.example.com,DNS:*.example.com,IP:192.0.2.0” > ext.cnf

Windows echo subjectAltName=DNS:localhost,DNS:example.com,DNS:nats.example.com,DNS:*.example.com,IP:127.0.0.1 > ext.cnf

3. Create and sign the server certificate

Use the ca.crt, ca.key, and server.csr files you created in previous steps to create the server certificate (server.crt):

openssl x509 -req -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -extfile ext.cnf -days 36500

If you have created set up TLS as a prerequisite for the Multi-Platform Probe, you can now follow the Step-by-step installation guide for the Multi-Platform Probe found in the Knowledge Base.

For more information on the Multi-Platform Probe, see the Knowledge Base: What is the Multi-Platform Probe and how can I use it?