Action required: Certificate change may break mTLS connections to Autonomous AI Database Serverless
On April 15, 2026, DigiCert will stop trusting G1 root certificates. Many existing mTLS wallets for Oracle Autonomous AI Database Serverless (ADB-S) were issued with those G1 roots.
If your apps use mTLS and the wallet was generated before January 28, 2026, connections can fail after April 15, 2026. TLS (walletless) connections are not affected.
What's changing
DigiCert is distrusting G1 root certificates on April 15, 2026. ADB-S wallets created up to January 28, 2026 use G1 roots; newer wallets use G2 roots.
That means mTLS wallets generated before January 28, 2026 will stop working after April 15, 2026. New wallets already align with the change.
Details on DigiCert root certificates
Who is affected
- You use mTLS (wallet-based) connections to ADB-S, and
- Your application, tool, or service uses a wallet generated before January 28, 2026.
If you use TLS authentication (walletless), no action is needed.
What changed on Oracle's side
As of January 28, 2026, ADB-S issues wallet zip files with newer G2 root certificates. No change to TLS (walletless) connections.
What you need to do before April 15, 2026
- Inventory every app, tool, and integration using mTLS to connect to ADB-S. Capture the wallet creation date.
- Re-download the database wallet zip file for each affected database.
- Update application configurations, connection pools, and deployment secrets to use the new wallet.
- Test in a non-production environment, then schedule production updates during a safe window.
- Monitor connections and error rates after rollout.
You don't need to rotate database credentials. The existing G1-based wallet will work until April 15, 2026-then it won't.
Recommended direction for leaders
Standardize on TLS (walletless) where policy allows. It reduces operational overhead, avoids future certificate trust shifts, and simplifies onboarding for new services.
If mTLS is required by policy or vendor constraints, bake wallet refresh into your quarterly maintenance cycle to avoid date-driven scrambles.
Timeline and ownership
- This week: Confirm who owns each mTLS-connected app. Assign a single owner to the refresh plan.
- Next 1-2 weeks: Download new wallets, update non-prod, complete testing.
- Within 30 days: Roll out to production; add monitoring and a rollback plan.
- Before April 15, 2026: Final verification that no G1 wallets remain in use.
- Stakeholders: App owners, DBAs, security/compliance, vendor managers, incident management/on-call.
Risk if you wait
Connections using old wallets will fail after April 15, 2026. Expect outages, failed jobs, delayed data pipelines, and customer impact.
Short-term fallback if you're blocked: switch affected services to TLS (walletless) temporarily-if that meets your security requirements-then complete the mTLS wallet refresh.
Quick checklist
- List all mTLS connections to ADB-S (prod and non-prod).
- Confirm wallet generation dates; flag anything before January 28, 2026.
- Re-download wallets and update configs/secrets.
- Test, deploy, monitor, and document.
- Decide: migrate to TLS (walletless) now or schedule it for your next iteration.
Manager FAQs
How do we know which apps are at risk? Check connection methods in app runbooks and secret stores; search for wallet files in CI/CD and deployment repos. Anything labeled mTLS or using a wallet zip created before January 28, 2026 is in scope.
Will this cost downtime? It shouldn't. Treat it like a configuration update. Use standard maintenance windows and roll out by service.
What's the budget/effort? Light engineering time per app (download wallet, update config, test). The heavier lift is coordination across teams and vendors.
Can we ignore this? No. On April 15, 2026, old G1 wallets will fail. Plan the change now and avoid operational churn later.
Your membership also unlocks:
