How ezTLS Secures Connections

To understand the ezTLS security model, it is important to distinguish between encrypting data and verifying identity. Encryption protects data while it travels between the client and server. Certificate-based identity verification confirms the identity of the server, the client, or both. In conventional one-way TLS, the client verifies the server certificate using a trusted certificate authority (CA), while in mutual TLS (mTLS), both sides verify each other’s certificates. In either case, the TLS handshake negotiates the protocol version and cipher suite, then establishes the keys used to encrypt network traffic.

Although ezTLS uses certificates to establish an encrypted TLS connection, it does not use them for certificate-based identity verification. When a client connects using ezTLS, Oracle AI Database uses the server certificate if one is configured. Otherwise, it automatically creates a temporary, self-signed certificate, and maintains the associated wallet state in server memory. In both cases, the client does not validate the certificate against a trusted CA, so the certificate alone does not confirm the server’s identity. You therefore do not need to configure a wallet or trust store to use ezTLS encryption.

During ezTLS connection setup, the client and server first establish an encrypted TLS connection. The database user then authenticates using a configured authentication method. Successful authentication establishes a shared secret known exclusively to the client and server. ezTLS uses that secret to establish a separate session key and bind subsequent network traffic to the authenticated database session. This binding helps prevent an eavesdropper or man-in-the-middle attacker who lacks the shared secret from hijacking the connection.

Because ezTLS does not independently verify the server’s identity, use standard one-way TLS when the client must validate the database server, or mTLS when both sides must verify each other’s identity with certificates.