TLS Features in Oracle Database

TLS secures connections between the Oracle Database client and server. Starting with Oracle Database 19.32, Oracle Database 19c supports both OpenSSL and Dell BSAFE Crypto-C Micro Edition Suite (MES) as cryptographic providers. Though MES remains the default provider, it is recommended to switch to OpenSSL as the cryptographic provider as OpenSSL enables TLS 1.3, FIPS 140-3 compliance, post-quantum cryptography (PQC) algorithms, and hybrid key exchange groups. For information on why and how to switch cryptographic providers see Why TLS Modernization Matters and Switching the Cryptographic Provider for Oracle Database 19c.

The database client and server can be configured to use TLS depending on your requirements. There are several options to consider which are mentioned below. Configuring a client-server TLS connection requires the database server to have a wallet. The server wallet includes the private key, the signed user certificate, the root of trust certificate and any intermediate certificates for the database server user certificate.

The TLS wallet on the database server must be stored under the WALLET_ROOT location. Create a directory for TLS under WALLET_ROOT, so it looks like WALLET_ROOT/<PDB GUID>/tls. Each container (including CDB root) will have its own TLS wallet, there’s no configuration to have a single wallet work for more than one or all containers when using WALLET_ROOT.

How TLS Network Encryption Works

When a client initiates a tcps connection, the client, listener, and database server participate in the TLS path as follows:

  1. The client connects to the listener over tcps.
  2. The TLS handshake starts before database user authentication.
  3. The endpoints negotiate a common TLS version and cipher suite.
  4. The server presents its certificate, and the client validates the certificate chain and, when enabled, DN matching rules.
  5. If mutual TLS is required, the client also presents its certificate and the server validates it.
  6. After the TLS session is established, Oracle Database performs database user authentication by the configured database method.
  7. Application data then travels inside the negotiated encrypted TLS session.

The key operational point is that TLS certificate authentication and database user authentication are related but separate layers. A correct TLS deployment protects the transport path. Database access still depends on the configured database authentication and authorization model.

Self-Signed Certificate vs. CA-Signed Certificate

Choose the trust model before configuring the listener or client.

One-Way TLS vs. Mutual TLS

Use TLS_CLIENT_AUTHENTICATION to control the behavior.

TLS With or Without a Client Wallet

A client wallet is required when the client must present a certificate for mTLS. It can also store a private or self-signed CA root when the system certificate store cannot be used.

A client can use one-way TLS without an Oracle wallet when all of the following apply:

Using the system certificate store reduces wallet distribution and renewal work for large client estates.

Certificate DN Matching

DN matching verifies that a valid certificate belongs to the server the client intended to reach. Without DN matching, a certificate signed by a trusted CA may be accepted even if it identifies a different server.

For partial matching, set the following in sqlnet.ora:

TLS_SERVER_DN_MATCH=TRUE

The client compares the connect descriptor HOST value with certificate identity fields such as the common name and subject alternative names. For full matching, also set the expected DN in sqlnet.ora:

(SECURITY=
  (TLS_SERVER_DN_MATCH=TRUE)
  (TLS_SERVER_CERT_DN="CN=db.example.com,O=Example,C=US"))

Both listener and database server certificates are checked. Establish basic TLS first, and then enable DN matching.

Post-Quantum Cryptography

Determine if using post-quantum cryptography (PQC) is appropriate for your database configuration.

Post-Quantum Cryptography (PQC), also known as quantum-resistant or quantum-safe cryptography, is a new class of cryptographic algorithms designed to be secure against attacks by future, large-scale quantum computers.

Current widely used public-key cryptographic methods, such as RSA and Elliptic Curve Cryptography (ECC), rely on mathematical problems that are computationally difficult for classical computers to solve. However, a sufficiently powerful quantum computer, using algorithms like Shor’s algorithm, could easily break these systems, compromising the security of sensitive data.

PQC algorithms are based on different mathematical problems—such as those related to lattices, hash functions, or codes—that are believed to be difficult for both classical and quantum computers to solve. The transition to PQC is a critical, proactive measure to protect long-term data, such as medical records and intellectual property, from being harvested today and decrypted in the future once a quantum computer becomes available.

Oracle Database supports the use of two PQC algorithms standardized by the National Institute of Standards and Technology (NIST): ML-KEM and ML-DSA.

See Configuring Post-Quantum Cryptography and Post-Quantum Cryptography Reference for detailed information about PQC algorithms, configuration, and FIPS mode interaction.