Certificate Validation in Dedicated Load Balancers

If at least one CA certificate is provided for the SSL endpoint, the load balancer passes the client certificate data to the API using these HTTP headers:

X-SSL-Client-Verify

Returns one of:
- SUCCESS
  
  The client is verified only after SUCCESS.
- NONE when the certificate is not present
- FAILED when other validation problems occur
X-SSL-Client-DN

Contains the full distinguished name of the client certificate
X-SSL-Issuer

Contains the full distinguished name of the issuing certificate
X-SSL-Client-Serial

Contains the serial number used by the CA to identify the client

The client certificate is validated at the DLB-level, but it is not re-validated at the API-level. TLS is 1-way between the DLB and the API.

How Client Certificate Validation Works

Client certificate validation succeeds when either of these conditions occurs:

The list of certificates you uploaded to the DLB includes the client certificate.
Any CA in the list of certificates you uploaded to the DLB signed the client certificate.

Trust-Based Validation Behavior

The DLB performs trust-based validation. It trusts any certificate that chains up to a trusted root CA or intermediate CA that you uploaded.

For example, if you upload this certificate chain to the DLB:

Client Certificate1 → Intermediate CA1 → Intermediate CA2 → Root CA

The DLB also accepts a different client certificate that chains to the same CAs:

Client Certificate2 → Intermediate CA1 → Intermediate CA2 → Root CA

In this case, the DLB accepts Client Certificate2 even though it’s not part of the intended client chain. The DLB accepts it because you uploaded Intermediate CA1 and CA2 as trusted CAs.

The DLB doesn’t enforce client identity. It only verifies that the certificate is valid and that a trusted CA signed it.

Implement Client Identity Verification

To verify client identity beyond CA trust validation, inspect certificate details in your Mule app. Use the X-SSL-Client-DN header to verify the Subject DN or Common Name (CN) and the X-SSL-Client-Serial header to match authorized serial numbers. Validating these headers restricts access to specific authorized clients.

Add Revocation Lists

The CloudHub load balancer can optionally verify client requests against certificate revocation lists (CRL). All CRL files must be concatenated into a single, unencrypted PEM-encoded file for upload. The order of items in the CRL is not important.

To add a revocation list when you create the load balancer, use the --crl option with the cloudhub load-balancer create command.

If your load balancer already exists, you can use the CloudHub API to add or update your CRLs. To do so, send a PATCH request to the /organizations/{myOrgID}/vpcs/{myVpcID}/loadbalancers/{myDlbID} endpoint and include a revocationList element:

[
  {
    "op": "replace",
    "path": "/sslEndpoints/0/revocationList",
    "value": "-----BEGIN X509 CRL-----\nMIIBTTCBtwIBATANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJBVTETMBEGA1UE\nCBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRk\nMRAwDgYDVQQDEwdvcmcuY29tFw0xNjAzMTUwOTI2MThaFw0xODAzMTUwOTI2MTha\nMBwwGgIJAIBvvO4dJHjhFw0xNjAzMTUwODUwMTZaoA4wDDAKBgNVHRQEAwIBBjAN\nBgkqhkiG9w0BAQUFAAOBgQCCAbGXW+Hnzmd1bXqWsFXfogOsJScoxkJOhhmjui3I\nhTUyO5plGHUBLjBnDkypM+iLfn0W4wPcNj7FZdz4Hu/WLntxwrTtR5YOcfIhEGcq\nwvJq/1+WKUPC6eqGwx0iKOOBIWsaf5CNOOUQMo6RaeTeu8Uba2EGFk1Vu/SoZYAK\nsw==\n-----END X509 CRL-----\n"
  }
]

To get the values for myVpcID and myDlbID values from the CLI, use the cloudhub vpc describe-json and cloudhub load-balancer describe-json commands.

To update any other property, send a PATCH request to your load balancer endpoint.

Prepare to Manage Certificate Cipher Suites

To manage cipher suites with the CloudHub API, you must first:

Generate your authorization bearer token.
Retrieve your organization ID using the CloudHub API.

See Retrieve a single organization.
Retrieve your VPC ID using the CloudHub CLI.

See cloudhub vpc describe-json.
Retrieve your DLB ID using the CloudHub CLI.

See cloudhub load-balancer describe-json.
Install jq to format the JSON output.

See jq.

Generate Authorization Bearer Token

To generate your authorization bearer token for Anypoint Platform:

Send your Anypoint Platform user name and password to the API:

curl -X POST 'https://anypoint.mulesoft.com/accounts/login' -H 'Content-Type: application/json' -d '{"username":"myUsername","password":"myPassword"}'

This command returns the access token:

{
  "access_token": "myAccessToken",
  "token_type": "bearer",
  "redirectUrl": "/home/"
}

Copy the value of access_token to use in the API calls.

Manage Certificate Cipher Suites

Using the CloudHub API, you can:

List available cipher suites.
Display the default cipher suite for a DLB.
Rotate the cipher by replacing the default cipher suite.

List Available Cipher Suites

To list available cipher suites for an organization using the CloudHub API:

Prepare to manage certificate cipher suites.

Run this GET call:

curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/loadbalancers/ciphersuites -H 'Authorization: Bearer myAccessToken' | jq

myOrgID is the organization ID.
myAccessToken is the access token you generated.

The output includes ciphers:

{
  "data": [
      {
          "id": "5b4a36e1e65c892316abd4d1",
          "name": "NewDefault-v1",
          "ciphers": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384",
          "description": "Default ciphers (new version)-v1",
          "defaultSuite": true
      },
      {
          "id": "5b4a36e1e65c892316abd4d2",
          "name": "OldDefault",
          "ciphers": "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4",
          "description": "Default ciphers (old version)",
          "defaultSuite": false
      },
      {
          "id": "5b4bfedee4b0f45ab1de6979",
          "name": "EcdheEcdsaRsa",
          "ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384",
          "description": "ECDHE ECDSA RSA ciphers",
          "defaultSuite": false
      },
      {
          "id": "5ba28106e4b00522d78f40b6",
          "name": "RestrictCiphers",
          "ciphers": "AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256",
          "description": "Restricted Ciphers",
          "defaultSuite": false
      }
  ],
  "total": 4
}

Recommended Cipher Suites

The following recommended cipher suites provide a good balance between compatibility and security for your SSL endpoint:

ECDHE-RSA-AES256-GCM-SHA512
DHE-RSA-AES256-GCM-SHA512
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384

Most cipher suites offer forward secrecy. RC4-SHA (supports Internet Explorer 8) does not. For this reason, MuleSoft and Microsoft do not recommend using it.

The CloudHub dedicated load balancer supports TLS 1.2.

Display the Default Cipher Suite for a DLB

To display the default cipher suite for a DLB using the CloudHub API:

Prepare to manage certificate cipher suites.
Run this GET call:
curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/myDlbID -H 'Authorization: Bearer myAccessToken' | jq
In the command:
- myOrgID is the organization ID.
- myVpcID is the ID for the VPC.
- myDlbID is the ID for the DLB.
- myAccessToken is the access token you generated.

The output includes defaultCipherSuite:

"defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384"

Rotate the Cipher by Replacing the Default Cipher Suite

To rotate the cipher by replacing the default cipher suite for a DLB using the CloudHub API:

Prepare to manage certificate cipher suites.
Run this PATCH call:
curl -X PATCH https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/ myDlbID -H 'Authorization: Bearer myAccessToken' -H 'Content-Type: application/json' -d '[{"op":"replace", "path":"/defaultCipherSuiteName", "value":"NewDefault-v1"}]' | jq
In the command:
- myOrgID is the organization ID.
- myVpcID is the ID for the VPC.
- myDlbID is the ID for the DLB.
- myAccessToken is the access token you generated.
- NewDefault is the value of name for a cipher suite from the list of available cipher suites that you generated in List Available Cipher Suites.

The output now includes defaultCipherSuite:

"defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384"

Limitation

To use an ECDSA-based authentication cipher, generate the certificate and key pair using an ECDSA-based algorithm and apply the same algorithm to the SSL certificate and key configuration on the DLB.

If you try to use an ECDSA-based authentication cipher with an RSA-based certificate and key pair, the SSL handshake fails and you receive either of the following error messages:

SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure

Error: write EPROTO 140434219616616:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40 140434219616616:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:603:

Because current DLB configuration permits only one type of SSL certificate and key pair per SSL endpoint, a client using an RSA-based cipher can not connect to an ECDSA-based configuration, and vice versa.