In today’s interconnected systems, secure communication is paramount. When Oracle Database interacts with external HTTPS services – whether for REST APIs, webhooks, or cloud integrations – it must validate the server’s SSL certificate. This process ensures data integrity and confidentiality. Let’s walk through how this was traditionally handled and how recent advancements have simplified the process for calling https://httpbin.org/get.
🛠️ Traditional Approach: Manual Wallet Creation
Historically, Oracle required a wallet to store trusted certificates. This wallet acted as a secure container for SSL credentials and was essential for HTTPS communication.
Step-by-Step: Creating and Using a Wallet
0. See what happens without a certificate chain
When just accessing the page without any wallet you get the following error ( I did not forget "from dual" here - this is another, more well known 23ai feature):
Error message for APEX_WEB_SERVICE.MAKE_REST_REQUEST ('
This assumes that you have an ACL that allows the access of course; but this is another topic.
So let's see how this is fixed traditionally first.
1. Obtain the Server Certificate
You can obtain the server (root) certificate e.g. from your local browser or using openssl. Here I do the first approach with chrome:
certificate chain as shown in chrome
click "export" there and save the root certificate in base64 format to aws_root_cert_pem:
AWS Root Certificate in PEM format
2. Create a Wallet
orapki wallet create -wallet /home/oracle/trustAws -pwd TopPassword123 -auto_login
2. Add the Certificate to the wallet
orapki wallet add -wallet /home/oracle/trustAws -trusted_cert -cert servert_cert.pem -pwd TopPassword123
3. Make the REST Call with the wallet
With those preparations in place you can add the wallet as a parameter to apex_web_services:
select APEX_WEB_SERVICE.MAKE_REST_REQUEST ('https://httpbin.org/get', 'GET', p_wallet_path=> 'file:/home/oracle/trustAws');
This gives you the expected result:
Accessing the HTTPS server while passing the wallet.
While effective, this method required manual steps, secure storage of wallet files on all instances, and periodic updates when certificates expire. This may come out of nowhere - some months back e.g. Microsoft changed one of their central root certificates without doing a lot of announcements.
🚀 The Modern Way: Introducing the "system:" Keystore
Starting with Oracle Database 23ai and backported to recent 19c versions, Oracle introduced the keystore – a built-in, read-only trust store that includes a curated set of trusted Certificate Authorities (CAs). This uses the keystore of the OS as it is described for 23ai here:
New "system:" path for the wallet (
Benefits of the system: Keystore
- ✅ No Wallet Creation Required
- ✅ Automatically Updated with OS patches
- ✅ Simplifies Configuration and Maintenance
How to Use It
Just reference the keystore in your HTTPS call setup:
select APEX_WEB_SERVICE.MAKE_REST_REQUEST ('https://httpbin.org/get', 'GET', p_wallet_path=> 'system:');
That’s it! No need to manage wallet files or manually import certificates. And this works for all websites that have a certificate issued by a CA trusted from your DB server's operating system.
🧩 When Should You Still Use a Custom Wallet?
While the keystore covers most public CAs, you may still need a custom wallet if:
- You're connecting to internal services with self-signed certificates.
- You need to trust a private CA not included in the system keystore.
But even in those situations you may prefer to add your company CA to the certificates trusted from your OS. Let's have a look at such a scenario as well. Without additional measures that can of course not be accessed using the "system:" store:
Access using system: store to a site with a certificate from a private CA
This is consistent to what happens from the operating system using curl:
Access using curl to a site with a certificate from a private CA
In Oracle Linux 8 this can be fixed as follows (see https://docs.oracle.com/en/operating-systems/oracle-linux/certmanage/managing_system_certificates.html):
trust anchor my_root.pem
Now it's possible to call the service using curl. And furthermore, now also a call from the Oracle database is successful:
Calling a HTTPS service secured from a private CA trusted by the local OS
🔚 Conclusion
Oracle’s move toward the keystore is a significant and long waited for step in simplifying secure integrations. It reduces administrative overhead and aligns with modern DevOps practices. For most use cases, especially when consuming public APIs, the keystore is all you need.
If you're still managing wallets manually, now might be the perfect time to evaluate whether you can streamline your setup with this new feature.
💬 Have you transitioned to the keystore yet? What challenges or benefits have you experienced? Especially when using private CAs? Let’s discuss!