TLS is a widely used, industry-standard protocol for protecting network traffic with encryption and integrity. In conventional certificate-authenticated TLS, the server presents a certificate, and the client verifies it against a trusted certificate authority (CA). Mutual TLS (mTLS) also requires a client certificate and corresponding trust configuration. Managing server certificates and private keys, renewals, and any required client certificates or trust configuration can add operational effort, especially when the goal is to encrypt network traffic, and database authentication already verifies the user.
Oracle also provides Native Network Encryption (NNE), a proprietary protocol that encrypts database traffic without requiring certificate or wallet management. At connection setup time, the client and server establish a Diffie-Hellman session key. During the subsequent user authentication, they establish an additional shared secret. NNE uses that shared secret to derive a session key that helps protect against man-in-the-middle attacks. NNE is widely used because it is simple to deploy without requiring customers to configure CA certificates or wallets.
Many customers, however, have also asked for standards-based TLS encryption without the wallet and certificate-management overhead, particularly when database authentication already verifies the user.
We’re excited to announce the availability of ezTLS, a feature that combines TLS-based network encryption with simplified certificate management. It provides the standards-based foundation of TLS for encryption and the easy deployment experience that customers value in NNE. ezTLS is designed to help organizations:
- Encrypt database connections with TLS without deploying or managing certificates or Oracle wallets solely for encryption.
- Benefit from cryptographic agility supported by TLS.
- Transition from NNE to ezTLS at their own pace, subject to supported database and client-driver versions.
Note that ezTLS is not intended to authenticate either client or server using PKI. It is intended only to provide encryption and integrity protection for network traffic.
ezTLS is available in Oracle AI Database 26ai Release Update 23.26.4 and Oracle Database 19c Release Update 19.33.
How ezTLS works
Before we get into ezTLS, let’s briefly recap how TLS works. In conventional one-way TLS, the client verifies the server’s certificate using the trusted CA certificate. In mutual TLS (mTLS), the client and server verify each other’s certificates using trusted CA certificates. The TLS handshake also negotiates the TLS protocol version and cipher suite, and then establishes the keys to encrypt network traffic.
ezTLS also uses certificates but in a slightly different manner. If no server certificate is available, Oracle Database automatically creates a temporary, self-signed certificate signed with ecdsa-with-SHA256 using a 256-bit secp256r1 elliptic-curve key for the ezTLS connection. But if a server certificate is already configured, the server-side ezTLS uses that certificate. In either case, the client does not validate the server certificate with a trusted CA certificate, and hence the client cannot confirm that it is communicating with the intended database server. One extra step is still needed to help verify that the client is talking to the intended server.
ezTLS provides this additional protection by binding the encrypted connection to the database authentication session that follows. After the database client establishes the encrypted TLS connection, the user authenticates to the database using the configured authentication method as usual, such as Kerberos or password authentication. A successful authentication establishes a shared secret between the client and server. ezTLS then uses that secret to establish a separate session key for encrypting subsequent network traffic over the TLS connection. Similar to NNE, this links the encrypted connection to the authenticated database session and helps protect against man-in-the-middle attacks.
As no CA-signed certificates are needed for ezTLS, a wallet or trust store does not need to be configured solely for ezTLS encryption.
For further details, please refer to the documentation.
ezTLS can be used with either TCPS or TCP listener ports. Follow the configuration steps below for the connection type you use.
Migrate from NNE to ezTLS for Oracle Database TCP Connections
To enable ezTLS over the regular cleartext TCP connection, first, configure the encryption settings on the client and server just as you would for NNE:
In sqlnet.ora on the database server
SQLNET.ENCRYPTION_SERVER = REQUIRED # on sqlnet.ora on the database server
In sqlnet.ora on the database client
SQLNET.ENCRYPTION_CLIENT = REQUIRED # on sqlnet.ora on the database client
Next, add EZTLS to SQLNET.ENCRYPTION_TYPES_SERVER in sqlnet.ora on the server. You can list it alongside NNE algorithms if you want to allow ezTLS and legacy NNE clients to connect over TCP at the same time, enabling a phased migration without a coordinated client upgrade:
SQLNET.ENCRYPTION_TYPES_SERVER = (EZTLS, AES256, AES128)
Add EZTLS to SQLNET.ENCRYPTION_TYPES_CLIENT in the client’s sqlnet.ora. This allows the client and server to negotiate EZTLS when supported. The client can still connect to other databases with legacy NNE.
SQLNET.ENCRYPTION_TYPES_CLIENT = (EZTLS, AES256, AES128)
Once all your clients support ezTLS, configure EZTLS as the only encryption type in sqlnet.ora on the server and remove the NNE algorithms from the list as follows:
SQLNET.ENCRYPTION_TYPES_SERVER = (EZTLS)
Because ezTLS uses TLS cipher suites, it automatically provides both encryption and integrity protection. You do not need to configure SQLNET.CRYPTO_CHECKSUM_SERVER or SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER. If these values are set, they are ignored.
Enable ezTLS for Oracle Database TCPS Connections
To use ezTLS with Oracle Database TCPS connections, set EZTLS to TRUE in sqlnet.ora on both the server and the client:
EZTLS = TRUE
Also, set TLS_CLIENT_AUTHENTICATION to OPTIONAL in the server’s sqlnet.ora to allow clients to connect without client authentication:
TLS_CLIENT_AUTHENTICATION=OPTIONAL
Because TCPS normally uses mutual or one-way TLS, both the server and the client must explicitly enable ezTLS. Once enabled, the server accepts both standard TLS and ezTLS connections on the same TCPS port. If you already have a wallet configured on the server, you do not need to remove the wallet to use ezTLS.
Client driver support
ezTLS is supported with the following Oracle Database client-driver versions.
- JDBC thin driver 23.26.4
- OCI-C-based driver 19.33 and 23.26.4
For other driver types, please refer to Oracle Database documentation for current support information.
Verifying ezTLS is enabled
When connecting to the database through a TCP port with NNE enabled, run
SELECT network_service_banner FROM v$session_connect_info WHERE sid= sys_context('userenv','sid');
If AES256 is used by legacy NNE, you will see the following: AES256 Encryption service adapter for Linux: Version 26.1.0.24.0 – Production
When ezTLS is used, you will see the following: TLS_AES_256_GCM_SHA384 Encryption service adapter for Linux: Version 26.1.0.24.0 – Production
When ezTLS is used over a TCPS port without a client wallet, confirm the TLS version and cipher suite with the following query:
SELECT
SYS_CONTEXT(‘USERENV’, ‘NETWORK_PROTOCOL’) AS network_protocol,
SYS_CONTEXT(‘USERENV’, ‘TLS_VERSION’) AS tls_version,
SYS_CONTEXT(‘USERENV’, ‘TLS_CIPHERSUITE’) AS tls_ciphersuite FROM dual;
Choosing the right TLS option
Note that ezTLS is designed specifically to provide TLS encryption without authenticating the communicating parties with PKI. It does not replace certificate-authenticated TLS when authentication of the communicating parties’ identities is a security requirement.
The choice depends on the security requirement for the connection:
- Use ezTLS only when the requirement is TLS-based encryption without the need for certificate-based server authentication or certificate-based user authentication.
- Use one-way TLS when clients also need to authenticate the database server using PKI.
- Use mTLS when both the client and database server require certificate-based authentication.
Summary: A standards-based path forward for database network encryption
With ezTLS, customers get modern TLS-based encryption with integrity protection, greater cryptographic agility, broad support across Oracle Database application environments, and a practical migration path from NNE—without having to introduce certificate-management infrastructure solely to encrypt database traffic.
With ezTLS available in supported Oracle Database releases and client drivers, organizations using NNE can begin planning their transition to ezTLS. Start by reviewing client-driver compatibility and identifying the database connections that can move to ezTLS.