Author: Shekh Muenuddeen
As you know that MuleSoft provides a shared and dedicated load balancer. As the name suggests that multiple organizations use shared load balancer. In other words, their application deployed to shared VPC. You will have a common name, including the application name for your application deployed.
But we will have requirements like we need our common subject name while calling APIs, decryption can only be done using our private keys and enable one-way SSL (by default) and two-way SSL mutual authentication.
As you know, that dedicated load balancer provides certain benefits over HTTPS related to certificates and security.
Data Integrity
Authenticity
Confidentiality
While setting up the dedicated load balancer, we need certificates signed by CA. You can generate the certificate signing request and send it to one CA or Sub CA to sign your certificate.
Once CA signs your certificate, you will get certificates. You will have a private key and a public key of your certificates.
Please check the below image to upload the private key and public key in DLB Configuration.
While seeing this image, you might be thinking about the pem file.
PEM full form is Privacy Enhanced Mail, a common format for X 509, Certificate signing requests, and cryptography keys. Ultimately its text file containing certificates in Base64 ASCII, with each certificate having headers and footers
Example –
Public key
— –BEGIN CERTIFICATE — –
Certificate Base64 ASCII
— –END CERTIFICATE — –
Private key
— –BEGIN PRIVATE KEY — –
Certificate Base64 ASCII
— –END PRIVATE KEY — –
Usaulty PEM file extension is .pem but we can store the same content with .cer, .crt and .key.
Now come to what and how can be uploaded in public key and private key in the above images for DLB.
Let’s focus on the Public key because it’s essential to understand. We need to create the proper public certificates chain where our DLB public certificates first, then intermediate CA certificate Root CA certificate added. Let read the below table.
This is the Pem file name as — public-dev-certificate-chain.pem
— –BEGIN CERTIFICATE — –
(Your Primary SSL certificate: your_domain_name.crt)
— –END CERTIFICATE — –
— –BEGIN CERTIFICATE — –
(Your Intermediate certificate: DigiCertIntermediateCA.crt)
— –END CERTIFICATE — –
— –BEGIN CERTIFICATE — –
(Your Root CA certificate: DigiCertRootCA.crt)
— –END CERTIFICATE — –
By mistake, if this chain is not proper, then the certificates chain is not exposed correctly so that your API consumer will get SSL Error ultimately its handshake failures.
To avoid this, we can verify our certificate chain online or use the tool (open SSL) Or MuleSoft net-tools application having certificate utility to download the certificate chains.
Once we clicked on the Run button, we got the certificates chain.
We can verify with our DLB URL how many certificates are exposed in the certificate chain — highly important :).
To upload the Private key, you need your private key in pem file as below
MuleSoft-dlb-dev-private.pem
— –BEGIN PRIVATE KEY — –
Certificate Base64 ASCII
— –END PRIVATE KEY — –
MuleSoft DLB configuration also validates your certificates with matching common names in private and public keys, but it does not verify whether you have uploaded the proper public certificate chain.
It’s simple as if you have only uploaded a DLB public certificate, then only the DLB public certificate is exposed to the API Consumer. It showed only one public certificate while downloading the public certificate chain from other tools like the MuleSoft net-tools application.
So we must upload a proper certificate chain in public key and verify whether the proper chain is visible or not.
We have uploaded the public key and private key in the DLB certificate configuration. This will play one way SSL and consumer responsibility is to add our DLB certificates into their trust store. Once they do that, they will not get SSL errors as we have signed our certificate via singing authority, and consumers have those CA and Sub CA certificates in their trust store. So if one certificate from our public certificates chain exists in the consumer trust store so that SSL mutual authentication is done, no SSL error comes out.
We can enforce two-way SSL from DLB Configuration, where DLB also needs to verify the client certificate by adding their public certificates in the DLB trust store. Please refer to the below image.
In the Client Certificate, we need to upload the public client certificates.
Thanks for Reading!!!
