SSL

By default, Teradata transmits data between the server and clients without encrypting it. This is generally acceptable when the server and client run on the same host or in networks where security is guaranteed through other means. However, in cases where the server and client exist on separate networks or they are in a high-risk network, the lack of encryption does introduce security concerns as a malicious actor could potentially eavesdrop on the traffic as it is sent over the network between them.

To mitigate this concern, Teradata allows you to encrypt data in transit between the server and clients using the Transport Layer Security (TLS) protocol. TLS was formerly known as Secure Socket Layer (SSL), but strictly speaking the SSL protocol is a predecessor to TLS and, that version of the protocol is now considered insecure. The documentation still uses the term SSL often and for compatibility reasons TLS-related server system

In order to secure connections between the server and client, you need to ensure that your server was compiled with TLS support.  

 

For a connection to be known SSL-secured, SSL usage must be configured on both the client and the server before the connection is made. If it is only configured on the server, the client may end up sending sensitive information (e.g., passwords) before it knows that the server requires high security.  All SSL options carry overhead in the form of encryption and key-exchange, so there is a trade-off that has to be made between performance and security.   You will find more information on this page.

 

 

Communication with Teradata can be set with any of these SSL modes:

 

 

 

 

Depending on the setup, one or more of the following fields will need to reference the appropriate file:

 

Certificate Authority

For production use, your PostgreSQL deployment should use valid certificates generated and signed by a single certificate authority. You or your organization can generate and maintain an independent certificate authority, or use certificates generated by a third-party SSL vendor.

 

To verify the identity of the PostgreSQL deployment you connect to, provide one or more certificates of trusted Certificate Authorities.

 

Client Certificate

If the server is configured to perform certificate validation, you need to provide a certificate here to identify yourself to the server.

 

Typical file extensions for the certificate are .crt or .pem.

 

Client Private Key

If the server is configured to perform certificate validation, you need to provide the private key here to identify yourself to the server.

 

Typical file extensions for the private key are .key or .pem.

 

Private Key Password

A private key can optionally be encrypted with a password.

 

If your private key is password protected, enter the password here. If not, leave the field blank.

 

Using a Let's Encrypt SSL Certificate

If you use a “let’s encrypt” SSL certificates and you face an error “certificate has expired”, then you should generate a certificate with a “certbot” option ‘--preferred-chain "ISRG Root X1"’:

certbot certonly -d <domain> --preferred-chain="ISRG Root X1"

 

Or remove the last certificate in the certificate chain generated by certbot and restart the server.

 

You may want to consult this page for full instructions.