Migrate from Oracle Database 19c TLS 1.2 to Oracle Database 19.32 with TLS 1.3

Migrate to TLS 1.3 in stages while validating clients, certificates, wallets, and optional PQC or FIPS configuration.

This topic describes a practical migration path from an Oracle Database 19c deployment using TLS 1.2 to Oracle Database 19.32 with TLS 1.3. It also covers two optional follow-on steps:

The recommended approach is staged:

  1. Inventory the current TLS and cryptographic configuration.
  2. Confirm that the environment can adopt the next-generation cryptographic provider safely.
  3. Enable the next-generation cryptographic provider in a nonproduction environment.
  4. Establish a clean TLS 1.3 baseline while retaining TLS 1.2 only where compatibility requires it.
  5. Verify clients, drivers, wallets, certificates, and negotiated protocol behavior.
  6. Optionally enable ML-KEM or hybrid key exchange.
  7. Optionally enable FIPS 140-3 after confirming compliance and algorithm requirements.

Migration objectives

The migration should achieve the following outcomes:

Step 1: Inventory the current environment

Before enabling the next-generation cryptographic provider or changing TLS policy, record the current server, listener, and client state.

At minimum, capture:

Step 2: Confirm cryptographic dependencies before enabling the next-generation cryptographic provider

The next-generation cryptographic provider changes the cryptographic implementation used by Oracle Database. Before enabling it, confirm whether any deployed feature still depends on older algorithms, older protocol assumptions, or specific cryptographic behavior.

Review at least the following:

In practice, confirm whether any important database feature or client path still relies on:

If any such dependency exists, keep it documented as a migration exception with an owner and removal plan.

Step 3: Enable the next-generation cryptographic provider in a test environment

Oracle Database 19.32 requires the next-generation cryptographic provider for TLS 1.3, ML-KEM, and FIPS 140-3.

Switch cryptographic providers to the next-generation by running the following:

python $ORACLE_HOME/bin/set_crypto_provider.py --provider openssl

After the provider change:

Do not combine this provider switch with major TLS policy changes in the same test step. First confirm that the environment still works with the new cryptographic provider before tightening protocol or cipher policy.

Step 4: Establish the TLS 1.3 baseline with minimum configuration

For the first working configuration on 19.32, keep the settings as close to default behavior as possible.

Recommended baseline:

For the initial transition window, remove TLS_VERSION so that the client and database server negotiate TLS 1.3 or TLS 1.2 according to client capability. For configuration details, see Configuring TLS 1.3.

This allows:

Use explicit TLS_CIPHER_SUITES only when required. Otherwise, let Oracle negotiate the strongest mutually supported cipher suite automatically.

For the server and listener:

For clients:

Step 5: Verify wallet, certificate, and trust model correctness

Before moving from TLS 1.2 to TLS 1.3 enforcement, confirm that wallet and certificate layout already follows the 19.32 model.

Check the server wallet layout:

Check the listener:

Check the clients:

Step 6: Validate client readiness

Before forcing TLS 1.3 only, test every important client and connection path.

Client validation should cover:

For every representative client:

  1. Connect using tcps.
  2. Verify:
SELECT sys_context('USERENV','NETWORK_PROTOCOL') AS network_protocol FROM dual;
SELECT sys_context('USERENV','TLS_VERSION') AS tls_version FROM dual;
SELECT sys_context('USERENV','TLS_CIPHERSUITE') AS tls_ciphersuite FROM dual;

  1. Confirm that:

    • NETWORK_PROTOCOL is tcps.
    • The client negotiates TLSv1.3 when expected.
    • The selected cipher suite is a strong TLS 1.3 or TLS 1.2 suite as intended.

The client checks should also confirm:

Step 7: Clean up old TLS 1.2-era configuration

After the initial TLS 1.3 baseline is stable, remove unnecessary TLS 1.2-era overrides.

Prefer to remove:

Keep explicit configuration only where there is still a documented need.

Step 8: Enforce TLS 1.3 when all required clients are ready

After client validation is complete, move from the compatibility window to TLS 1.3 only if the environment no longer requires TLS 1.2.

To require TLS 1.3 or explicitly block TLS 1.2, follow Configure TLS 1.3.

Use this only after confirming that every required client path succeeds with TLS 1.3.

Step 9: Use defaults for strong cipher suites whenever possible

Oracle Database 19.32 with the next-generation cryptographic provider already supports strong modern cipher negotiation. The preferred operating model is:

If explicit policy is required, use a narrow list of strong suites only.

Example:

TLS_CIPHER_SUITES=(TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256)

Avoid carrying forward old TLS 1.2 CBC or RSA-based compatibility suites unless a specific client still requires them and the exception is documented.

Step 10: Optionally enable PQC after the TLS 1.3 baseline is stable

Do not introduce PQC in the same change window as the initial TLS 1.3 migration. First confirm that the environment is stable with TLS 1.3 and the next-generation cryptographic provider.

After that, enable PQC in a second phase.

Key checks before enabling ML-KEM or hybrid key exchange:

To configure hybrid or ML-KEM-only key exchange, see Configure Key Exchange Groups.

Use hybrid or ML-KEM only after confirming client compatibility. Keep PQC as a separately managed rollout, especially for mixed-client environments.

Step 11: Optionally enable FIPS 140-3 after confirming compliance requirements

FIPS 140-3 is also a separate phase. Do not enable it just because TLS 1.3 or PQC is available.

First confirm:

Use the fips.ora parameter model:

To enable FIPS 140-3:

FIPS_140=TRUE
FIPS_140_3=TRUE

To remain in non-FIPS mode:

FIPS_140=FALSE

Treat FIPS testing as its own validation cycle, because algorithm availability, allowed ciphers, and runtime behavior can differ from non-FIPS mode.

Suggested migration sequence

Use this order:

  1. Inventory the current TLS 1.2 deployment.
  2. Document all client versions and runtime dependencies.
  3. Confirm certificate and cryptographic dependencies.
  4. Enable the next-generation cryptographic provider in test.
  5. Retain TLS 1.2 and TLS 1.3 initially, as described in Configuring TLS 1.3.
  6. Keep cipher and key-exchange settings at default unless policy requires explicit values.
  7. Validate all important clients.
  8. Remove unnecessary TLS 1.2-era overrides.
  9. Require TLSv1.3 only after client validation is complete.
  10. Optionally configure hybrid or ML-KEM key exchange in a later phase. See Configuring Post-Quantum Cryptography.
  11. Optionally enable FIPS_140=TRUE and FIPS_140_3=TRUE in a separate compliance phase.

Customer decision checklist

Before production cutover, confirm the following: