--- schema_version: "1" id: e1ad19137cc48a4a88a499891a01a6f9f2196ca6e03eb4e73f16e7681244471a title: Certificate Validation in Dedicated Load Balancers collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/cloudhub/lb-cert-validation.md canonical_url: https://docs.mulesoft.com/cloudhub/lb-cert-validation source_site: docs.mulesoft.com content_type: documentation content_hash: 3ff00a312a056cfdfa4a26c3095c96265c2dc37d6f5b5a0a7018b5935a38fbb2 description: MuleSoft Documentation Site latest: true --- --- product: CloudHub --- # Certificate Validation in Dedicated Load Balancers > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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 > [!NOTE] 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. > [!IMPORTANT] 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`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-create) command. If your load balancer already exists, you can use the [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/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: ```json [ { "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`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-describe-json) and [`cloudhub load-balancer describe-json`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#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](#generate-authorization-bearer-token). - Retrieve your organization ID using the CloudHub API. See [Retrieve a single organization](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/minor/1.0/console/method/%233736/). - Retrieve your VPC ID using the CloudHub CLI. See [cloudhub vpc describe-json](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-describe-json). - Retrieve your DLB ID using the CloudHub CLI. See [cloudhub load-balancer describe-json](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-describe-json). - Install `jq` to format the JSON output. See [jq](https://stedolan.github.io/jq/). ### Generate Authorization Bearer Token To generate your authorization bearer token for Anypoint Platform: 1. Send your Anypoint Platform user name and password to the API: ```json 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: ```json { "access_token": "myAccessToken", "token_type": "bearer", "redirectUrl": "/home/" } ``` 2. 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](#list-available-cipher-suites). - [Display the default cipher suite for a DLB](#display-the-default-cipher-suite-for-a-dlb). - [Rotate the cipher by replacing the default cipher suite](#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: 1. [Prepare to manage certificate cipher suites](#prepare-to-manage-certificate-cipher-suites). 2. Run this GET call: ```linenums 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`: ```json { "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: 1. [Prepare to manage certificate cipher suites](#prepare-to-manage-certificate-cipher-suites). 2. Run this GET call: ```linenums 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`: ```json "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: 1. [Prepare to manage certificate cipher suites](#prepare-to-manage-certificate-cipher-suites). 2. Run this PATCH call: ```linenums 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](#list-available-cipher-suites). The output now includes `defaultCipherSuite`: ```json "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: ```linenums SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure ``` or ```linenums 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. ## See Also - [Configure SSL Endpoints and Certificates](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints) - [Add Certificates to a Dedicated Load Balancer](https://docs.mulesoft.com/cloudhub/lb-cert-upload) - [Allowlists](https://docs.mulesoft.com/cloudhub/lb-allowlists) - [Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules) - [Create a Load Balancer with Runtime Manager](https://docs.mulesoft.com/cloudhub/lb-create-arm)