Last Updated on 30/05/2021 by Patryk Bandurski
So far, I have explained how to configure your Dedicated Load Balancer to use your domains. Now we will focus on configuring it more securely. We enforce mutual authentication. My goal is to show you how to configure it, what the options are, and, last but not least, how to test it. Let’s get started.
Mutual Authentication
One-way TLS
In this chapter, I will briefly introduce what two-way TLS is. To better depict it, I start with describing one-way TLS … or just TLS. This is something that you should already be familiar with. Anytime you visit your Bank web page to pay the bills, you access the trusted web page. How do you know that it is trusted? Based on the green lock in the address bar, like on the screen below. You may view the certificate, find out for whom it is issued, and what Certificate Authority (CA) signed it.

This is the same for your APIs or vendors’ APIs. Usually, the API endpoint is exposed over a secure protocol with a CA-signed certificate so that the callers can trust your API. The server trusts any client that is connecting to our endpoint. The one-way TLS is used mainly with some authentication mechanism, so the client needs to send credentials.
Two-way TLS
We can increase the security by limiting the clients the server trusts – unlike in one-way TLS. This involves the client certificate. It contains basic information about the client’s identity. In the diagram below, you can see the MuleSoft server with the public (certificate) and a private key.

In this scenario, you receive from the Client its certificate. All the subsequent calls from that client will hold the same certificate. As a result, our server will accept the calls. Client certificates are stored in the truststore on the server.
Client certificates configuration
The prerequisite for the following steps is to create a VPC and associated Dedicated Load Balancer. In my case I have api-pb.lb.anypointdns.net. You need to be aware that this kind of configuration is not available if your use Shared Load Balancer.
One client certificate
The first scenario is relatively simple. We have only one trusted client. In my case, I assume that only Salesforce will be calling from the internet MuleSoft Dedicated Load Balancer – like in the diagram below.

To configure DLB, we need a public certificate from the client – here, Salesforce. MuleSoft requires that certificates are in the PEM format. How does it look like? Take a look down below:
-----BEGIN CERTIFICATE-----
MIIEVTCCAz2gAwIBAgIOAXRqV5gzAAAAADg0lqEwDQYJKoZIhvcNAQELBQAwdTEN
MAsGA1UEAwwEU0ZEQzEYMBYGA1UECwwPMDBEM1gwMDAwMDQ3MFAyMRcwFQYDVQQK
DA5TYWxlc2ZvcmNlLmNvbTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzELMAkGA1UE
...
3JDVYc+3y08iG/ytaYbI6KgZUWHSO3pduSnP2CNdO7x6QZnIc9f9Mz4/96WoUQrK
Q5rX2m+JhBCReC7sXF8UD059ssad6fuJIBcHlOmhmUgX/dWlpVsEvo9uUHNRUSx3
P/keofXqUyPb
-----END CERTIFICATE-----
Notice that it starts with BEGIN CERTIFICATE. Do not mistake it with BEGIN PUBLIC KEY.
It is time to upload the certificate.
Open the Dedicated Load Balancer configuration and go to the Certificates section. Pick the Certificate Name for which you would like to add a client certificate. Next to the Client Certificate, click Choose File, and pick the pem file. That is all, save the configuration.

After applying the changes, you should see in the certificates list Client Certificate listed. Like below.

From now on, in order to connect to our APIs via Dedicated Load Balancer, we need to use an SFDC certificate. Everything else is discarded and the 400 Bad Request returned.
More client certificates
Now imagine, that we have another trusted client. We need to upload the second public certificate. This time it will be the cucumber platform for E2E testing. One thing worth noticing is that for this client I will use a self-sign certificate. It is not a problem. On the diagram below you can see that we have two client certificates in the DLB’s truststore – one for each client.

When you try to upload the certificate, you may notice that you have only two choices. Either Remove or Replace. We need to combine public certificates into one pem file. How to do this? Just copy the whole text and put it at the end of the file. Such a file is ready to be uploaded. Combined certificates look like:
-----BEGIN CERTIFICATE-----
MIIEVTCCAz2gAwIBAgIOAXRqV5gzAAAAADg0lqEwDQYJKoZIhvcNAQELBQAwdTEN
MAsGA1UEAwwEU0ZEQzEYMBYGA1UECwwPMDBEM1gwMDAwMDQ3MFAyMRcwFQYDVQQK
...
P/keofXqUyPb
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEVTCCAz2gAwIBAgIOAXRqV5gzAAAAADg0lqEwDQYJKoZIhvcNAQELBQAwdTEN
MAsGA1UEAwwEU0ZEQzEYMBYGA1UECwwPMDBEM1gwMDAwMDQ3MFAyMRcwFQYDVQQK
...
P/keofXqUyPb
-----END CERTIFICATE-----
After uploading it and saving the configuration, on the DLB summary web page you won’t see two client certificate names in the Certificates table. Just the first one, from the file. Rest assured that all client certificates are loaded – this is just GUI limitation.

Enforceing client certificate validation
During Client Certificate configuration by default Client Certificate Validation, it set to Mandatory. It means that without a certificate traffic won’t be allowed. In case when you want to accept requests without or with the wrong certificate you should pick the Optional option. The output of client certificate verification is passed to your APIs in the X-SSL-Client-Verify header.
It can contain one of three values:
- SUCCESS
- FAILED
- NONE – no certificate provided
Testing configuration
No certificate provided
The first test it to send a request without any certificate. I have already prepared application dev-portal-xapi that should return list of products.
GET /dev-portal-xapi/products HTTP/1.1
Host: test.ambassadorpatryk.com
As a result I received 400 Bad Request with following body
<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
</body>
</html>
The same behaviour you will notice in case of expired certificate or certificate that is not in trusted.
Correct client certificate
Using Postman you can configure client certificate to be sent during your callouts. Of course for sending a request you need a certificate with a private key. For the Cucumber I have already a key pair in PKCS#12 format. The file has extension p12.
- Click File
- Click Settings
- Go to Certificates tab
- Click Add Certificate next to the Client Certificates headline
- Provide the DLB hostname (in my case test.ambassadorpatryk.com)
- Upload PFX file with key pair
- Click Add

Postman will add this certificate any time you make a call to the specified hostname.
After that initial setup, I made the same call as previously, but this time I received the response:
[
{
"product-code": "MT-B",
"product-desc": "MuleSoft Basic Training",
"product-name": "MuleSoft Basic Training",
"product-price": 2000,
"product-status": "ACTIVE"
},
...
]
Summary
It is a cinch to add client certificates to the Dedicated Load Balancer. You only have to keep in mind three things. First of all, it can be a self-signed or CA sign certificate. It must be uploaded in the pem format, which is the only one that is acceptable by the Anypoint Platform. In case of more than one client certificate, you should combine the certificates into one pem file.
I hope you enjoy reading it. Cheers
Great post. Some more things to keep in mind, with the CA signed certificates, you must have the intermediate and root certificates in order in the PEM file, I think the format is Base64 encoded PEM, the file extension seems to work with either .pem or .crt I haven’t tested any others. Also if you validate the client certificate in code, then this seems to work with either Optional or Mandatory if you validate based on the ‘x-ssl-client-verify’ headers passed on by the DLB which seem to be passed on for Successful requests with Mandatory and with all requests for Optional.
Thanks. Yes, I think that it is often forgotten that intermediate certificates need to be present. Good point. Without we will quickly see issues during the first tests.