SSL/TLS Overview ​

To use SSL/TLS for secure connections to Yellowbrick data warehouses, you need to complete the following tasks (and understand some related concepts):

• Decide the level of trust verification required.
• Obtain certificates if needed based on the required trust level.
• Set the defaults or explicit connection properties for the required level of trust and certificate locations.
• Use the proper server host name in your connections.
• Make sure the correct set of network ports is available for client connections.

SSL/TLS, Certificates, and Trust ​

Most problems encountered by users attempting SSL connections are a result of not having some basic understanding of TLS/SSL, certificates, and verification of trust.

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are protocols to encrypt and authenticate data transfer between applications. SSL was the original protocol that has since been replaced by TLS. SSL is often used to refer to a secure protocol although TLS is typically what is being used.

Using a TLS/ SSL connection provides two separate pieces of functionality:

• Encryption of traffic between your client application (ybsql, ODBC driver, ybload, and so on) and the server application (the Yellowbrick data warehouse)
• Verification that the server is who it claims to be

When a TLS/SSL connection is established, the data will always be encrypted, even on an untrusted connection. If a connection is trusted, this means that the client application has been able to verify, using certificates, that the server host and domain names match the names passed through in the connection. This verification is achieved through the SSL chain of trust, as discussed later in this section.

The options to enable or disable trust requirements differ among the drivers, ybsql, and the Java-based ybtools. If trust verification is required, the decision to verify trust is a client-side function. Yellowbrick instances are configured to allow TLS/SSL connections only, but the server cannot require the client to do trust verification.

SSL Chain of Trust ​

A chain of trust is an ordered list of certificates, available on the client host:

• An initial leaf certificate, which is the certificate installed on your Yellowbrick data warehouse
• Intermediate certificates, which are issued to your organization by a trusted Certificate Authority (CA)
• The root certificate of the CA, which is publicly available and typically included in the trusted certificate store for your operating system and Java installation.

This chain enables the client application to verify that the certificate is trustworthy; each certificate in the chain can be verified through its parent. In turn, server identity spoofing can be prevented.

The following diagram is a logical view of the chain of trust:

To see a specific chain of trust, you can use a web browser. The following example, using Microsoft Edge, shows a chain of three certificates:

• Sectigo: root certificate from the trusted Certificate Authority (CA)
• Sectigo RSA Domain Validation Secure Server: Intermediary certificate from the certificate signer that:
• Can be verified using the root certificate
• Issued the following leaf certificate
• *.yellowbrick.com: Leaf certificate, a wildcard certificate that applies to any host in the domain yellowbrick.com instead of a specific host name only

Self-signed certificates cannot be verified because they do not provide a chain of trust. The self-signed certificates that a Yellowbrick data warehouse ships with are an example of this. Many organizations have policies requiring verification of the chain of trust when users connect to databases, web servers, and so on. Therefore, these organizations install their own trusted certificates on their Yellowbrick data warehouses.

The security policies of many companies do not allow the use of self-signed certificates or client settings that ignore certificate root verification for use with clusters storing confidential or personally identifiable information (PII). In these environments, the self-signed certificate must be replaced with a certificate from a trusted signing authority, using a PEM-encoded file or a Java KeyStore (JKS).

SSL/TLS Ports ​

Database client connections, bulk load and unload options, Yellowbrick Manager access, and other SSL/TLS communication with the Yellowbrick cluster go through specific ports. Additional network ports in the corporate firewall may need to be opened; otherwise, users will receive errors and communication will fail. For a list of port numbers used for data control and transfer, see Opening Network Ports for Clients.