One Client Cert, All APIs? A Hidden Security Gap in MuleSoft DLB

When it comes to 2-Way TLS in MuleSoft, many assume that once the DLB (Dedicated Load Balancer) is configured and client certificates are validated — all is secure. But there’s a subtle and important security gap you should know about.

---

🔍 The Problem: Validation Isn’t Context-Aware

Imagine this:

• Your DLB is set up for 2-Way TLS ✅
• You’ve uploaded multiple client certificates to the DLB’s truststore ✅
• Everything works — clients can call your APIs over HTTPS using their certificates ✅

But here’s the catch:

The DLB does not match specific client certificates to specific APIs.

This means that any valid certificate uploaded to the truststore can be used to call any API behind that DLB — even if it wasn’t intended to.

Example:

Let’s say:

• You uploaded certs for Salesforce, Payment Gateway, and Internal Monitoring to the DLB
• You have two APIs:
  • /eapi/salesforce — intended only for Salesforce
  • /eapi/payment — intended only for the Payment Gateway

Now: even if the Payment cert calls the Salesforce API, the DLB will validate it — because it’s in the truststore — and the request will go through.

That’s a security concern.

✅ The Fix: API-Level Certificate Filtering

To solve this, we need a way to ensure that only the expected certificate is accepted per API.

One of the approachs is to implement a custom policy in API Manager that:

• Extracts the Subject DN (Distinguished Name) from the client certificate
• Compares it to an expected value for that API
• Rejects any request with an invalid or unknown DN

🔧 Good news: I built one for you

You can find my custom policy here: 👉 Validate Certificate DN Policy on GitHub

It’s easy to install and use in your API Manager policies — and it closes this important security gap.

---

🛠️ Alternative: Split Your APIs Across Multiple Domains

If you’re operating multiple APIs with different access rules, you can also leverage one powerful DLB feature: multiple domain support.

DLB allows you to expose multiple fully qualified domain names (FQDNs), each mapped to a different backend app or group of APIs. For example:

• pm.api.my.company.com → used by your Payment Gateway clients
• sf.api.my.company.com → used exclusively by Salesforce

Each domain entry can have its own configuration, including:

• its own client certificate validation rules
• unique keystore/truststore setup

With this model, each trusted client presents its certificate only to the subdomain intended for them, and you can configure 2-Way TLS separately per domain.

📘 Learn how to configure this step-by-step in: 👉 Configure 2-Way TLS on MuleSoft DLB

This strategy provides better isolation and control — especially in large-scale enterprise environments.

---

🔐 Recap

• DLB validates certificates, but doesn’t map them to specific APIs
• Any valid certificate can access any endpoint behind the same DLB
• Use a custom policy to filter by Subject DN and enforce proper access
• ✅ Alternatively, use separate subdomains per API/client to fully isolate TLS config

---

💡 Pro Tip

In regulated environments (e.g. banking, healthcare), this validation is not optional — it’s critical.
Always assume that certificate presence ≠ intent.

---