SSL Authentication
To protect privacy and verify data integrity, you can configure Vertica and database clients to use Secure Socket Layer (SSL). SSL allows secure connection and communication between the client and the server. The SSL protocol uses a trusted third party called a Certificate Authority (CA). Both the owner of a certificate and the party that relies on the certificate trust the CA.
Vertica supports the following authentication methods under Transport Layer Security (TLS) v1.0, v1.1, and v1.2 protocol:
- SSL server authentication — Lets the client confirm the server's identity. The client verifies that the server's certificate and public key are valid and were issued by a certificate authority (CA) listed in the client's list of trusted CAs. This authentication helps prevent man-in-the-middle attacks. See "Prerequisites for SSL Server Authentication and SSL Encryption" in SSL Overview and Configuring SSL.
- SSL client authentication — (Optional) Lets the server confirm the client's identity. The server verifies that the client's certificate and public key are valid and were issued by a certificate authority (CA) listed in the server's list of trusted CAs. Client authentication is optional because Vertica can authenticate the client at the application protocol level through user name and password credentials. See "Optional Prerequisites for SSL Server and Client Mutual Authentication" in SSL Overview.
- Encryption — Encrypts data sent between the client and database server. This method significantly reduces the likelihood that the data can be read if the connection between the client and server is compromised. Encryption works at both ends of a transaction, regardless of whether SSL Client Authentication is enabled. See "Prerequisites for SSL Server Authentication and SSL encryption" in SSL Overview and Configuring SSL.
- Data integrity — Verifies that data sent between the client and server has not been altered during transmission.
Note: For server authentication, Vertica supports using RSA encryption with ephemeral Diffie-Hellman (DH). DH is the key agreement protocol.
Certificate Authority
The CA issues electronic certificates to identify one or both ends of a transaction. These certificates to verify ownership of a public key by the name on the certificate.
Public and Private Keys
A CA issues digital certificates that contain a public key and the identity of the owner.
The public key is available to all users through a publicly accessible directory. However, private keys are confidential to their respective owners. When you use a private/public key pair, the data is encrypted by one key and decrypted by its corresponding key.
- If encrypted with a public key, data can be decrypted by its corresponding private key only.
- If encrypted with a private key, data can be decrypted by its corresponding public key only.
For example, suppose Alice wants to send confidential data to Bob. Because she wants only Bob to read it, she encrypts the data with Bob's public key. Even if someone else gains access to the encrypted data, it remains protected. Because only Bob has access to his corresponding private key, he is the only person who can decrypt Alice's encrypted data back into its original form.