Step-by-Step Guide: Configuring 2-Way TLS on MuleSoft DLB

Setting up 2-Way TLS (mutual TLS) on MuleSoft’s Dedicated Load Balancer (DLB) can feel daunting. We get it — there are keystores, truststores, certs, and configurations across systems. But don’t worry — this guide walks you through it clearly, step by step.

🔧 What You’ll Need

Before starting, make sure you have:

✅ A working MuleSoft application deployed to CloudHub
✅ A configured Dedicated Load Balancer (DLB)
✅ Your client certificate (X.509 PEM)
✅ Your truststore (to trust the client’s cert)
✅ Access to Anypoint Platform & Runtime Manager

1️⃣ Upload Your Client Certificate to DLB Truststore

1. Go to Runtime Manager > Load Balancers
2. Select your DLB and click one of yours domains
3. Upload your client certificate to the truststore by clicking Choose File next to Client Certificate

📌 Important Notes:

• You can upload multiple public certificates — for example, when supporting more than one client (e.g., Salesforce and internal apps). Here is a sample content of a pem file that holds two certificates.

-----BEGIN CERTIFICATE-----
MIIEVTCCAz2gAwIBAgIOAXRqV5gzAAAAADg0lqEwDQYJKoZIhvcNAQELBQAwdTEN
MAsGA1UEAwwEU0ZEQzEYMBYGA1UECwwPMDBEM1gwMDAwMDQ3MFAyMRcwFQYDVQQK
...
P/keofXqUyPb
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEVTCCAz2gAwIBAgIOAXRqV5gzAAAAADg0lqEwDQYJKoZIhvcNAQELBQAwdTEN
MAsGA1UEAwwEU0ZEQzEYMBYGA1UECwwPMDBEM1gwMDAwMDQ3MFAyMRcwFQYDVQQK
...
P/keofXqUyPb
-----END CERTIFICATE-----

• If a client certificate has a certificate chain (like intermediate certificates), you must upload the entire chain — not just the leaf certificate.
  → Salesforce is a common example — if you only upload the leaf cert, the handshake will fail.

🧠 Lesson Learned:

When working with Salesforce, remember to include intermediate certificates! Without them, the DLB won’t be able to fully verify the certificate, and the connection will fail during the TLS handshake.

This step tells the DLB which client certificates to trust.

2️⃣ Enforce Client Certificate Validation

After uploading client certificates, you’ll need to configure how strictly the DLB enforces their use.

1. Locate the Client Certificate Validation option
2. Select one of the modes:
   • Mandatory (default): the request must include a valid certificate, or it will be rejected
   • Optional: the request can include a certificate, but it’s not required — this allows fallback to other auth mechanisms

🧠 The DLB performs certificate validation and passes the result to your Mule applications via the X-SSL-Client-Verify HTTP header.

Possible values:

• SUCCESS – client certificate was presented and verified
• FAILED – certificate was provided but invalid
• NONE – no certificate was sent

This gives you flexibility: enforce strict mTLS, or allow a hybrid model depending on your integration scenario.

💡 Pro Tip: Give Your Testers Their Own Certificate

To maintain full control over who can call your secured APIs, it’s a good idea to generate a dedicated client certificate for your QA or API testing team.

They can use this certificate (stored securely in a .p12 file containing the private key) when testing endpoints through the DLB.

From the MuleSoft side:

• You upload only the public part of this certificate to the DLB’s truststore
• The private key remains secure with the testers

This approach lets you:

• ✅ Track exactly who is calling your API
• ✅ Let testers work independently while staying secure

3️⃣ Your App Stays TLS-Agnostic

Once your DLB is configured with client certificate validation, you don’t need to make any TLS-specific changes in your Mule application.

Why? Because Two-Way TLS is entirely handled by the Dedicated Load Balancer. Your app won’t even know if the request came with a certificate or not.

All you have to do is:

• Point your clients to the DLB endpoint (e.g. https://api.yourcompany.com/your-app)
• Deploy your Mule app normally to CloudHub
• (Optional) Inspect headers like X-SSL-Client-Verify if you want your app to react differently based on validation result

Your API stays clean and simple — all the security magic happens at the edge.

4️⃣ Test the Mutual TLS Flow

✅ Try calling your API with a client certificate — it should work.
❌ Try calling it without one — it should be rejected at the TLS handshake stage.

You can test using:

• Postman with client certificates
• cURL:

curl https://api.yourcompany.com/your-app \
  --cert client.crt \
  --key client.key

✅ Recap

2-Way TLS strengthens security by verifying both sides of the connection.

Once configured, only approved clients can talk to your API — even if they have the right token.