8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » Misc » Here

Database Callouts : Simplifying Certificate Management and TLS Version Support by Using a Reverse Proxy

This article describes how using a reverse proxy can simplify the certificate management required for database callouts. It also explains how this can be used to overcome TLS support issues encountered by older systems.


It is assumed you understand how we handle database callouts using HTTPS. If not it is explained here.

It is assumed you understand the basics of a reverse proxy. There are examples of using NGINX and Apache as reverse proxies here.

When we use the term reverse proxy, it could apply equally to a load balancer acting as a reverse proxy.

Certificate Management

When we make a HTTPS callout from the database we need the root certificate of the URL in our wallet. If the root certificate of the URL changes, our callouts are broken until we load the new root certificate.

Why would the root certificate change?

By using a reverse proxy in front of the external URLs we protect ourselves from changes to the root certificates. When the reverse proxy sends requests to the external URL, it negotiates the HTTPS connection in a similar way that a browser does. We don't have to worry about managing the root certificates of the external URLs. To achieve this we do the following.

We now open the wallet and make a callout to the reverse proxy, which in turn contacts the external URL.

We can add new URLs to the reverse proxy at any time, without having to worry about downloading certificates. They will be handled automatically by the reverse proxy.

ACL/ACE Management

Before we can make a database callout to a URL we have to create an ACL/ACE to allow access to the URL. This is described here.

By using the reverse proxy as our immediate callout, we only need to consider the ACL/ACE for accessing the reverse proxy from the database, as the base URL for any callout is the same. It's always the reverse proxy.

We can add new URLs to the reverse proxy at any time, without having to worry about adding new ACLs/ACEs to the databases.

TLS Version Support

Internet security is a constantly moving target. Unfortunately, our systems can't always keep up with the speed of change. Fronting all database callouts with a reverse proxy can solve some of the problems we are likely to face. Here are some examples.


Wallets and ACLs are used to secure the database from callouts to bad URLs. Using a reverse proxy for database callouts means we effectively remove these from the equation. As a result it is important we validate all changes to the reverse proxy configuration to make sure we are not introducing problems.

If our reverse proxy is supporting old protocols, it's important we protect it as much as possible. Make sure access is restricted to only those database servers that need to use it. Once the reason for the old protocols has gone, remove the old protocols.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.