Configuring Oracle GoldenGate with TLS to Securely Connect to the Oracle Database

In GoldenGate Microservices, deployment can be configured to operate in either a secure or unsecured mode. Opting for secure deployment utilizes SSL/TLS protocols, which provide robust encryption to safeguard the communication channels. This means that data transmitted between clients such as web browsers, the AdminClient, and various APIs to the GoldenGate host is effectively protected against interception and unauthorized access. Furthermore, secure communication can also be established between two GoldenGate hosts, ensuring that all data exchanged is encrypted and secure. This configuration is essential for maintaining the integrity and confidentiality of sensitive information during transmission.

A secure deployment does not automatically establish a secure connection between the GoldenGate host and the Oracle Database server for capturing or applying purposes. This secure connection is critical as it ensures that all data transmitted between the two servers is encrypted,  safeguarding sensitive information from potential unauthorized access. Without this encrypted data transmission, the integrity and confidentiality of the data in transit could be compromised, exposing it to various security threats. Therefore, it is essential to manually configure secure connectivity to achieve a fully secure deployment environment.

This article provides step-by-step procedures for establishing a secure TLS (Transport Layer Security) connection between your GoldenGate Deployment and the Database host. We will begin by configuring the wallet, adding certificates in the database host, and reconfiguring the listener to accept the TLS protocol connections. Next, we will copy the wallet to the GoldenGate host, configure it in the GoldenGate host, and finally, test the connectivity.

Transport Layer Security (TLS) helps keep your connections secure between an Oracle Database client and server by encrypting data. You can choose between a self-signed certificate or one from a public Certificate Authority (CA).

Using Distinguished Name (DN) matching to ensure you connect to the right server is recommended. While you can customize TLS settings, sticking with the default options for optimal security is usually best.

The examples in this article use self-signed certificates, but you can just as easily use proper certificate authority certificates if you prefer.

Full Documentation on GoldenGate Data in Transit Security: https://docs.oracle.com/en/middleware/goldengate/core/23/coredoc/secure-data-transit.html

1. Create root wallet and self signed root CA certificate.

In this step, the script will use orapki to create the wallet, generate the self-signed certificate and export the trusted certificate for use by the client trust store.

1.1. Create the wallet files

1.2. View the contents of the wallet, it should be empty

1.3. Create the self-signed certificate for the rootCA wallet

1.4. The directory should have cwallet.sso and ewallet.p12 files

1.5. View the contents of the wallet, it should have a user and a trusted certificate

1.6. Export the rootCA trusted certificate for use in creating the DB wallet

orapki wallet export -wallet /opt/oracle/tls/certificates/rootCA -dn ‘C=US,CN=ROOT’ -cert /opt/oracle/tls/certificates/rootCA/rootCA.crt -pwd ${DBUSR_PWD}

1.7. View the contents o the rootCA.crt file:

2. Create database server wallet and create certificate request.

Next, you will create the DB wallet and certificate request to be signed by the rootCA. This step also imports the rootCA trusted certificate into the DB wallet.

2.1. Create the wallet files

2.2. Add the rootCA trusted certificate to the DB wallet

2.3. Create the DB server user certificate

2.4. Export the DB certificate signing request

2.5. View the contents of the wallet, it should have a Requested certificate and a Trusted certificate

2.6. View the contents of the certificate request file:

2.7. Check all files

3. Sign database certificate with root CA certificate.

Now, you will have the rootCA sign the DB server user certificate. This provides validity to the certificate. If it is not signed by a public root, or intermediate, certificate authority (CA), or an organization’s root, or intermediate, CA, then the certificate may not be trustworthy.

3.1. Create the wallet files

3.2. View the signed server user certificate

4. Add CA root certificate and database server certificate to database wallet.

After generating the signed DB user certificate, import it to the DB wallet. In this step, you will see that the DB server user certificate changes from a “requested certificate” to a “user certificate”.

4.1. Before importing, the DB server user certificate is still marked as Requested

4.2. Import the signed DB server user certificate into the DB wallet

4.3.  After importing, the DB server user certificate is now a user certificate

5. Import CA root certificate into client trust store (Linux, Windows only)

Now that you have your signed DB server user certificate, you will deploy it to your DB wallet root location. The DB will use the WALLET_ROOT parameter to look for it’s wallet-related information, including tde and tls. Then you will copy the DB wallet, with the signed certificate the default directory Oracle GoldenGate would search for the wallet, /u02/Deployment/etc/ssl in the GoldenGate host.

The ‘WALLET_ROOT’ parameter now must be set in the Database initalization parameter.

This is a static parameter, the DB will be restarted.
Set “wallet_root” parameter as “/etc/ORACLE/WALLETS/ORCLCDB/2E9B0F48D8E60B3BE063670034ACADE0/tls”

5.1. This is a static parameter, the DB will be restarted.

5.2. Identify the GUID for PDB1, this will be the directory we use for our wallet location

5.3. As root, create the DB server wallet directory on the OS

5.4. Copy wallet files to the DB wallet location

5.5. Change ownership of ORACLE directory to oracle user

5.6. Copy the DB wallet files to the GoldenGate host

5.7. On GoldenGate Host, create the wallet

6. Monify the listener.ora and sqlnet.ora in the Database Host.

• Database Host is the server in this scenario

6.1. Modify the listener.ora and sqlnet.ora in the Database host

6.2. Modify sqlnet.ora in the database host

6.3. Bounce the listener

7. Modify the tnsnames.ora and sqlnet.ora GoldenGate host. 

• GoldenGate host in this scenario is the client.

7.1. Modify the tnsnames.ora in the GoldenGate host

7.2. Modify sqlnet.ora in the GoldenGate Host

8. Let’s test the connectivity with GoldenGate WEbUI trying to connect to the TLS secure port (1522).

8.1. Create a connection

8.2. Enter Alias, User ID and password to connect to the database with TLS, note the TNS entry in the User ID

8.3. We can now see the credention created and let’s test it

8.4 Connection established sucessfully

8.5. Verify if the connectivity is encrypted from Goldengate Hub to the Database Server

Conclusion

Using TLS for Oracle GoldenGate to Oracle Database connections provides: 

• Data Encryption (Prevents intrusion)
• Authentication (Prevents unauthorized access)
• Compliance (Meets security standards)
• Data Integrity (Prevents tampering)
• Secure Replication (Over public networks & cloud)
• Credential Protection (Secures login details)

Enabling TLS in GoldenGate ensures secure, encrypted, and compliant replication of mission-critical data. 

It is not the purpose of this article to discuss data at rest within the database; however, you can explore the documentation on TDE for that.

Oracle TDE (Transparent Data Encryption) is an Oracle Database security feature that provides encryption for data at rest. It automatically encrypts data stored in tablespaces, columns, and redo logs without requiring changes to applications.

https://docs.oracle.com/en/database/oracle/oracle-database/23/dbtde/changes-this-release-oracle-database-transparent-data-encryption-guide.html