Planning TLS/SSL encryption between OpenText Analytics Database and Kafka

Some things to consider before you begin configuring TLS/SSL:.

Some things to consider before you begin configuring TLS/SSL:

Which connections between the scheduler, OpenText™ Analytics Database, and Kafka needs to be encrypted? In some cases, you may only need to enable encryption between the database and Kafka. This scenario is common when the database and the Kafka cluster are on different networks. For example, suppose Kafka is hosted in a cloud provider and the database is hosted in your internal network. Then the data must travel across the unsecured Internet between the two. However, if the database and the scheduler are both in your local network, you may decide that configuring them to use SSL/TLS is unnecessary. In other cases, you will want all parts of the system to be encrypted. For example, you want to encrypt all traffic when Kafka, the database, and the scheduler are all hosted in a cloud provider whose network may not be secure.
Which connections between the scheduler, the database, and Kafka require trust? You can opt to have any of these connections fail if one system cannot verify the identity of another. See Verifying Identities below.
Which CAs will you be using to sign each certificate? The simplest way to configure the scheduler, Kafka, and the database is to use the same CA to sign all of the certificates you will use when setting up TLS/SSL. Using the same root CA to sign the certificates requires you to be able to edit the configuration of Kafka, the database, and the scheduler. If you cannot use the same CA to sign all certificates, all truststores must contain the entire chain of CAs used to sign the certificates, all the way up to the root CA. Including the entire chain of trust ensures each system can verify each other's identities.

Verifying identities

Your primary challenge when configuring TLS/SSL encryption between the database, the scheduler, and Kafka is making sure the scheduler, Kafka, and the database can all verify each other's identity. The most common problem people have encountered when setting up TLS/SSL encryption is ensuring the remote system can verify the authenticity of a system's certificate. The best way to prevent this problem is to ensure that the all systems have their certificates signed by a CA that all of the systems explicitly trust.

When a system attempts to start an encrypted connection with another system, it sends its certificate to the remote system. This certificate can be signed by one or more Certificate Authorities (CA) that help identify the system making the connection. These signatures form a "chain of trust." A certificate is signed by a CA. That CA, in turn, could have been signed by another CA, and so forth. Often, the chain ends with a CA (referred to as the root CA) from a well-known commercial provider of certificates, such as Comodo SSL or DigiCert, that are trusted by default on many platforms such as operating systems and web browsers.

If the remote system finds a CA in the chain that it trusts, it verifies the identity of the system making the connection, and the connection can continue. If the remote system cannot find the signature of a CA it trusts, it may block the connection, depending on its configuration. Systems can be configured to only allow connections from systems whose identity has been verified.

Note

Verifying the identity of another system making a TLE/SSL connection is often referred to as "authentication." Do not confuse this use of authentication with other forms of authentication used with the database. For example, TLS/SSL's authentication of a client connection has nothing to do with database user authentication. Even if you successfully establish a TLS/SSL connection to the database using a client, the databse requires you to provide a user name and password before you can interact with it.