Configuring ezTLS for TCP Connections

ezTLS over TCP provides modern TLS encryption for connections that historically relied on legacy native network encryption (NNE). Because ezTLS utilizes standard TLS cipher suites, it automatically guarantees both data encryption and integrity protection, so you no longer need to configure separate NNE checksum parameters.

TCP connections negotiate ezTLS using your existing sqlnet.ora encryption-algorithm lists. While EZTLS is enabled by default, you can explicitly control its usage by including or excluding it in your configuration.

TCP Configuration Scenarios for ezTLS
Compatibility During Phased Migrations
TCP Migration Checklist

TCP Configuration Scenarios for ezTLS

You can control exactly how and when ezTLS is negotiated by modifying the encryption-algorithm lists in your client and server sqlnet.ora files. The following examples outline the standard configuration patterns for deploying, enforcing, or disabling ezTLS based on your current migration phase and security policies.

Phased Migration (Recommended): To enable ezTLS while retaining a legacy algorithm (like AES256) as a fallback for older, unupgraded clients, add EZTLS to your algorithm lists.
- Server configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_TYPES_SERVER = (EZTLS, AES256)
```
- Client configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_TYPES_CLIENT = (EZTLS, AES256)
```
Enforcing Encryption: If encryption must be strictly enforced across your environment, use the existing policy parameters to ensure connections never fall back to cleartext.
- Server configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_SERVER = REQUIRED
```
- Client configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_CLIENT = REQUIRED
```
Strict ezTLS (Post-Migration): Once all clients and servers are fully upgraded and verified, enforce ezTLS exclusively by removing legacy algorithms from your configuration entirely.
- Server configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_TYPES_SERVER = (EZTLS)
```
- Client configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_TYPES_CLIENT = (EZTLS)
```
Disabling ezTLS: If you need to disable ezTLS for a specific endpoint (e.g., for troubleshooting or to meet unique legacy requirements), simply omit EZTLS from the explicit algorithm list.
- Server configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
```
- Client configuration (sqlnet.ora):
```
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256)
```

Compatibility During Phased Migrations

When transitioning to ezTLS, you can perform rolling upgrades by keeping a legacy encryption option (like AES256) enabled until your entire environment supports EZTLS.

During this transition period, connection behavior depends on the upgrade status of your endpoints:

Fully upgraded endpoints: A new client and new server successfully negotiate ezTLS.
Mixed environments: An upgraded client can connect to an older server (and vice versa) only if both sides share a compatible legacy encryption algorithm in their sqlnet.ora files.
No match: If the client and server do not share a compatible algorithm, the connection safely fails rather than falling back to cleartext.

TCP Migration Checklist

Before and during your migration to ezTLS over TCP, ensure you:

Verify versions: Confirm that both your client drivers and server versions support ezTLS over TCP.
Update configurations: Include EZTLS in the required client and server encryption-algorithm lists.
Maintain fallbacks: Retain a compatible legacy encryption option during rolling upgrades so older endpoints remain functional.
Test thoroughly: Validate every required client type and connection path in your environment.
Validate negotiation: Use SQL*Net tracing or your preferred network diagnostics to confirm that ezTLS is actively being negotiated.
Clean up: Once the migration is fully complete and validated, remove obsolete NNE-only algorithms to meet modern deployment standards.