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

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.

Assumptions
Certificate Management
ACL/ACE Management
TLS Version Support
Security

Assumptions

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

UTL_HTTP and SSL (HTTPS) using Oracle Wallets

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?

Typically root certificates have a really long lifespan, but they will eventually expire and need to be replaced.
The external site may change to a different Certificate Authority (CA), which will cause the root certificate to change. Now that CA certs only last one year, companies quite often switch to whichever CA is cheapest at the time of renewal. We've seen a number of our external URLs change certificate authority multiple times.

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 configure a reverse proxy to front all the required external URLs.
We configure the reverse proxy to use HTTPS using a self signed certificate with a really long lifespan (10+ years).
We load the self-signed certificate of the reverse proxy into the wallet of the database server.

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.

The database can't handle newer versions of TLS : In recent years we've had two big events related to TLS versions support. Several years ago SSLv3 was disabled across the internet, and more recently TLSv1.0 and TLSv1.1 were both disabled. If we had kept up to date with database upgrades and patches, this wouldn't have affected us, but both events caused issues with some of our databases that were lagging behind. The obvious solution is to do the necessary database upgrades and patches, which we did eventually, but those can take time to plan. The quick solution was to switch to using a reverse proxy to front the external URLs, and make sure our reverse proxy still supported the old version of SSL/TLS. Only when the last problematic database was upgraded could we remove the old protocol support.
The database can't handle older versions of TLS : Oracle database 23c has removed support for TLSv1.0 and TLSv1.1. That should be good news for most people, but invariably companies will have some old internal systems that are lagging behind that still don't support TLSv1.2 or higher. This means an upgrade to Oracle database 23c will break callouts to those old systems. We can use a reverse proxy to solve this problem too. Access from the database to the reverse proxy uses TLSv1.2 or higher, then the reverse proxy talks to the legacy system using an older protocol.

Security

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.