Your OCI Autonomous Database wallets are about to stop working — here's what to do before April 15
If you're running Oracle Autonomous Database Serverless with mTLS wallet connections, you've probably received an email from Oracle that felt a bit like the fire alarm going off during a meeting. Important, but easy to think "I'll deal with that later."
Don't leave it too long. April 15, 2026 is the hard deadline, and it's less than a month away.
Here's what's happening, why it matters, and exactly what you need to do. No fluff.
What's changing?
DigiCert is distrusting its G1 root certificates on April 15, 2026. This isn't an Oracle decision - it's an industry-wide certificate lifecycle change driven by browser root programme requirements from Mozilla and Chrome. DigiCert announced it months ago, and the ripple effects are hitting everything from Microsoft Exchange to IBM Db2 to your Autonomous Database wallet.
The short version: if your ADB-S mTLS wallet was downloaded before January 28, 2026, it will stop working after April 15, 2026.
Your applications won't connect. Your jobs will fail. And it'll happen on a Tuesday, because certificate expiry always happens on a Tuesday.
Why does this affect Autonomous Database specifically?
Oracle Autonomous Database Serverless supports two connection methods: TLS (walletless) and mTLS (wallet-based). If you're using mTLS, you downloaded a wallet zip file when you set up your database connection. That wallet contains the root certificates that your client uses to establish a trusted, mutually authenticated connection to the database.
Wallets generated before January 28, 2026 contain DigiCert G1 root certificates. After April 15, those G1 roots will no longer be trusted by DigiCert. The chain of trust breaks. Your connection fails.
Since January 28, Oracle has been issuing new wallets with G2 root certificates. So the fix is straightforward - but you do actually have to do it.
The email from Oracle that prompted this post. If you received one of these, pay attention.
Who is affected?
You need to act only if all three of these are true:
You're running Autonomous Database Serverless (ADB-S)
You're connecting via mTLS (wallet-based connections)
Your wallet was downloaded before January 28, 2026
If you're using TLS (walletless) connections, you're fine. No action needed.
Not sure which you're using? Here's how to check.
How to check your connection method
In the OCI Console, navigate to your Autonomous Database instance and look at the Network section on the database details page. You'll see whether mTLS is required or whether TLS is also enabled.
The Network section on your ADB-S details page. If "Require mutual TLS (mTLS) authentication" is enabled, you're on mTLS.
How to check your wallet age
If you're on mTLS, check when your wallet was generated. The simplest way is to look at the file timestamps on the wallet zip you originally downloaded. If you can't find the original file, err on the side of caution and re-download it anyway - it takes two minutes and costs nothing.
You can also inspect the certificates inside the wallet:
# Unzip the wallet and check the root certificate dates
unzip wallet_YOURDB.zip -d wallet_check
openssl x509 -in wallet_check/README -noout -dates 2>/dev/null || \
openssl x509 -in wallet_check/cwallet.sso -inform DER -noout -dates
If the root certificate references DigiCert Global Root CA (the G1 root) rather than DigiCert Global Root G2, you need to refresh.
The fix: step by step
Step 1 — Re-download the wallet
Go to your Autonomous Database instance in the OCI Console. Click Database connection, then Download wallet.
Click Database connection, then Download wallet. You'll be asked to set a wallet password.
Set your wallet password (or use the same one you used previously - it's the password that protects the wallet file, not your database credentials). Download the zip.
The new wallet will automatically contain the G2 root certificates. No wallet rotation is required - you're just downloading a fresh copy.
Step 2 — Update your applications
This is the part that takes the most coordination. Everywhere you have an application, tool, or service connecting to ADB-S via mTLS, you need to replace the old wallet with the new one.
Common places to check:
Application servers — look for the
TNS_ADMINdirectory or wherever you unzipped the walletJDBC connection pools — the wallet path in your connection URL or datasource config
Python scripts using
python-oracledb— theconfig_dirorwallet_locationparameterSQL Developer — the connection properties will reference the wallet location
OCI Data Integration, Data Flow, or other OCI services — these may use an Object Storage–based wallet; check your connection assets
Kubernetes secrets — if you mounted the wallet as a secret, update the secret data
CI/CD pipelines — if your deployment process downloads or caches the wallet, refresh it
For a typical JDBC connection, the change looks like this:
# Your connection string doesn't change — just the wallet files
jdbc:oracle:thin:@mydb_high?TNS_ADMIN=/path/to/new/wallet
Replace the contents of your wallet directory with the new files. Restart your connection pool or application. Done.
Step 3 — Test before April 15
Don't just swap wallets in production blind. If you have a non-production ADB instance (and you should), test the new wallet there first. Confirm your application connects, queries work, and any connection pool recycling behaves normally.
If you want to be thorough, you can verify the certificate chain in the new wallet:
# Check which root CA is in the new wallet
openssl x509 -in cwallet.sso -inform DER -noout -issuer -subject 2>/dev/null
# Or check the PEM files if present
grep -l "DigiCert Global Root G2" *.pem
Step 4 — Consider moving to TLS (walletless)
This is the real recommendation, and Oracle has been pushing this for a while: switch to TLS authentication and drop the wallet entirely.
TLS (walletless) connections don't require downloading or managing wallet files at all. The trade-off is that you need to configure network access controls - either a private endpoint or an Access Control List (ACL) - but once that's done, you never have to worry about wallet refreshes again.
To enable TLS on an existing ADB-S instance:
Go to your database details page
Under Network, click Edit
Ensure you have either a private endpoint or an ACL configured
Toggle Require mutual TLS (mTLS) authentication to allow TLS
Update your connection strings to use the TLS connection string (port 1521 instead of 1522)
This is something we've been gradually moving towards across our own environments. Every wallet refresh is a reminder of why walletless connections are worth the initial setup effort.
The bigger picture: certificate hygiene in OCI
If you've read my previous post about OCI Let's Encrypt automation breaking, you'll notice a pattern here. Certificate lifecycle management on OCI requires active attention.
Two certificate-related disruptions in the space of a month:
Let's Encrypt dropping the TLS Client Authentication EKU - broke OCI Certificate Service renewals because the EKU profile didn't match
DigiCert G1 root distrust - breaks mTLS wallet connections for Autonomous Database
Both are legitimate upstream changes. Neither is Oracle's fault. But both require you to actively manage your certificate estate rather than assuming "it just works."
If you take one thing away from these two posts, it's this: set up alerting on your certificate and wallet expiry dates. We caught the Let's Encrypt issue because our TLS expiry monitoring fired. The DigiCert G1 issue was flagged by Oracle's email notification. If you're not monitoring either of these channels, you're flying blind.
Some practical steps to build into your ops routine:
Subscribe to Oracle Cloud notifications so email alerts actually reach someone who acts on them
Monitor certificate expiry across your OCI load balancers and WAF configurations
Track wallet download dates for all ADB connections - add them to your runbook
Review DigiCert's root CA timeline - they've announced further changes including G5 root adoption. This isn't the last time this will happen
Timeline at a glance
| Date | What happened |
|---|---|
| January 28, 2026 | Oracle ADB-S began issuing new wallets with G2 root certificates |
| Now | You should be re-downloading wallets and updating applications |
| April 15, 2026 | DigiCert distrusts G1 roots. Old wallets stop working. Connections fail. |
| 2027–2028 | Let's Encrypt reducing cert lifetimes to 64 days (2027) then 45 days (2028). Certificate management gets busier. |
TL;DR
If you're connecting to Oracle Autonomous Database Serverless using mTLS wallets downloaded before January 28, 2026 - go re-download them now. The old G1 root certificates will be distrusted on April 15, 2026, and your connections will fail.
Better yet, switch to TLS (walletless) connections and never think about wallet refreshes again.
And please - set up certificate expiry monitoring if you haven't already. Future you will be grateful.
