Introduction

Certificates, TLS, wallets, CAs — these terms often confuse GoldenGate administrators, especially when configuring secure communication between components in GoldenGate Microservices (MSA).
To simplify this, let’s break it down using a relatable analogy: a child, a teacher, and a parent.
This analogy will help you clearly understand server certificates, client certificates, and CA certificates, and how GoldenGate uses them to establish trust and secure communication.

Understanding Certificates in GoldenGate Through a Simple Analogy

Analogy Setup

Imagine:

• Child = the GoldenGate client (e.g., Admin Client, Receiver Server, WebUI)
• Teacher = the GoldenGate server (e.g., Distribution Server, Administration Server)
• Parent = the Certificate Authority (CA), a trusted authority that confirms identities.

Now let’s see how certificates fit in:

1. Server Certificate — “Teacher’s ID card”

When the teacher (server) gives out the marksheet, the child (client) needs to know:

“Am I really getting this from my real teacher, not a fake one?”

So, the teacher shows an ID card (Server Certificate) issued and signed by the parent (CA).

In GoldenGate MSA:

• The server certificate identifies the GoldenGate service (like https://oggserver.company.com).
• It’s signed by the CA, so clients (admin client,webui) can trust it.
• Stored typically in the service manager wallet.

2. Client Certificate — “Child’s ID card”

Now, the teacher also wants to be sure that the child is genuine:

“Are you really my student, or an outsider pretending to be one?”

So, the child also presents an ID card (Client Certificate) signed by the same parent (CA).

This = Client Certificate.

In GoldenGate MSA:

• Used for mutual authentication.
• The server verifies the client certificate to ensure only trusted clients connect.
• Stored in the client wallet or keystore.

3. CA Certificate — “Parent’s Signature Template”

Everyone trusts the parent’s signature — both the teacher and the child know it.
If the teacher’s ID or child’s ID carries that signature, everyone can trust it’s real.

This signature template = CA Certificate.

So:

• The CA certificate is like the known signature of the parent.
• It’s shared publicly so others can verify any certificate signed by that parent.

In GoldenGate:

• You import the CA certificate into both client and server wallets.
• That allows both sides to validate each other’s certificates.

How It Works in GoldenGate MSA

When your GoldenGate components (e.g., Distribution Server and Receiver Server) communicate:

1. Server presents its server certificate
2. Client validates it using the CA certificate
3. If mutual authentication is enabled, client sends its client certificate
4. Server validates the client certificate
5. Once both trust each other, TLS-secured communication begins

Browser Example (Web UI)

When accessing the GoldenGate Web UI:

1. Browser sends a request to the GoldenGate Server
2. Server sends its Server Certificate
3. Browser validates the certificate using CA information stored in its trust store
4. Once validated, HTTPS negotiation begins
5. GoldenGate then validates the user credentials for login

🎥 Want to Configure This Yourself?

📌 Step-by-step setup of GoldenGate 23ai with self-signed certificates:
👉 https://www.youtube.com/watch?v=J-dBsK7CIfU

📌 Want complete practical GoldenGate training?
Fill the enquiry form or contact on below number:
👉 https://agtrancotech.com/course-enquiry/

Regards,

Ashish Agarwal

Call and Whatsapp:+14168715708