Over the last few years, I've educated enough customers on the concept of walletless Transport Layer Security (TLS) that I think a blog post is warranted to unpack this feature. In short, the term walletless means that you do not need to create, distribute and update Oracle wallets (or Java Trust store for JDBC thin clients) to all Oracle AI Database clients for validating the authenticity of the server's TLS signed certificate. The client instead, leverage's the client host operating system's existing certificate trust store to confirm the authenticity of a server's certificate. The client configuration conveys the intent to use the client's host operating system trust store by setting the WALLET_LOCATION=SYSTEM parameter in either sqlnet.ora or the connect string/name service (TNS) record stored in either a local tnsnames.ora file or remotely in the LDAP-based name service.
This feature was initially introduced between 2021 and 2022 with 21c and was backported to 19c and is supported going forward including 26ai.
This one-way TLS framework is composed of certificate authority (CA), a TLS server (Oracle AI Database Server) with a certificate that is signed by the CA, and a TLS client (Oracle AI Database Client such as SQL*Plus, SQLcl, SQL Developer, ... and programatic clients like java, python, ruby, ...) with local trust store. The client connects to the server over TLS, retrieves the server's certificate and then confirms the authenticity with the certificate chain of trust that is stored in a local trust store.
With self-signed certificates, a wallet (or java trust store) must be created and populated with the certificate chain of trust, which is just the client's certificate. Then the trust store(s) must be distributed to all database clients that need to securely connect over TLS to the server. This can be an arduous and operationally inefficient repetitive maintenance task that may not always be possible because the database server administrators do not always know what clients are connecting to the server.
Mutual two-way TLS authenticity framework is the same as one-way TLS plus the client has a signed TLS certificate that the server must confirm as well. Oracle's walletless solution does not include support for mutual TLS.
Let's look at two examples: Privately signed certificates by Active Directory Certificate Service (AD CS) and publicly signed certificates by a public CA.
Active Directory Certificate Service Signed Certificates
In the case of the privately signed certificates by AD CS, Microsoft automatically propagates the AD CS certificate chain to the trust store of managed computers. For enterprise environments, that covers all of the enterprise managed laptop and desktop computers. For database client software running on any of the managed hosts, the client's sqlnet.ora (parameter defaults file) or tnsnames.ora can set WALLET_LOCATION=SYSTEM to indicate that the client can confirm the authenticity of the server's certificate.
Here is a sample sqlnet.ora file entry:
cat sqlnet.ora
WALLET_LOCATION=SYSTEM
WALLET_LOCATION=SYSTEM
Here is a sample tnsnames.ora file entry:
PDB1 =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCPS)(HOST=hrdb.dbauthdemo.com)(PORT=2484))
(SECURITY=
(SSL_SERVER_DN_MATCH=TRUE)
(WALLET_LOCATION=SYSTEM)
)
(CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=pdb1)
)
)
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCPS)(HOST=hrdb.dbauthdemo.com)(PORT=2484))
(SECURITY=
(SSL_SERVER_DN_MATCH=TRUE)
(WALLET_LOCATION=SYSTEM)
)
(CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=pdb1)
)
)
Public Certificate Authority Signed Certificates
In the case of publicly signed certificates, the operating system vendor maintains a trust store that contains the current certificate chain of trust for all major public certificate authorities. This trust store is periodically updated through operating system updates.
The sqlnet.ora and tnsnames.ora examples from the privately signed AD CS example would similarly set WALLET_LOCATION=SYSTEM to use the local operating system trust store.
For reference, here is information on each of the major operating system trust stores.
Note that Advanced Interactive Executive (AIX) is the only operating system for which the trust store provider that may not by default include any certificate chains of trust. The AIX link above provides instructions on how add certificate chains of trust to the AIX trust store.
Additional documentation references for client specific configurations available below:
- 26ai TLS With or Without a Client Wallet
- 19c TLS With or Without a Client Wallet
- Autonomous Dedicated - Prepare for TLS Walletless Connections
- Autonomous Serverless - JDBC Thin Connections Without a Wallet
- Autonomous Serverless - SQL*Plus Without a Wallet
- Autonomous Serverless - SQL Developer Without a Wallet
- Autonomous Serverless - SQLcl Without a Wallet
- Autonomous Serverless - Microsoft .NET, Visual Studio Code, Visual Studio Without a Wallet
- Autonomous Serverless - Node.js and Other Scripting Languages Without a Wallet
- Autonomous Serverless - Python Applications Without a Wallet
- Autonomous Serverless - Go Applications Without a Wallet
- Autonomous Serverless - JDBC Thin Application Without a Wallet
- Graph Developers Guide - Using a Walletless TLS Connection
- KB134166 - TLS / SSL connection without using a client side Wallet LINUX
I hope you find this helpful!
Blessings!
No comments:
Post a Comment