From 6f17ff42b52f810232108309c2ca2d427bc35130 Mon Sep 17 00:00:00 2001 From: Luana Dos Santos Date: Sat, 17 Jan 2026 18:04:50 -0300 Subject: [PATCH 1/4] W-18989901-DLB-2way-cert-validation --- .../ROOT/pages/lb-cert-validation.adoc | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc index 83fc30b7a..42f2cd971 100644 --- a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc +++ b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc @@ -33,6 +33,46 @@ 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 isn't 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 client certificate details in your Mule application using these headers: + +* `X-SSL-Client-DN`: Contains the full distinguished name of the client certificate. Use this header to verify the Subject DN or Common Name (CN). +* `X-SSL-Client-Verify`: Returns `SUCCESS` if the client certificate is valid. Check this header to confirm that the DLB validated the certificate. +* `X-SSL-Client-Serial`: Contains the serial number that the CA uses to identify the client. Use this header to match against authorized client certificate serial numbers. + +By validating these headers in your backend application, you can restrict 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. From 907ff9dba07a7fad9cc51aa172e81609e2be1bf0 Mon Sep 17 00:00:00 2001 From: Luana Dos Santos Date: Sat, 17 Jan 2026 18:12:30 -0300 Subject: [PATCH 2/4] removed repetition --- cloudhub/modules/ROOT/pages/lb-cert-validation.adoc | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc index 42f2cd971..463b544d2 100644 --- a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc +++ b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc @@ -65,13 +65,7 @@ The DLB doesn't enforce client identity. It only verifies that the certificate i === Implement Client Identity Verification -To verify client identity beyond CA trust validation, inspect client certificate details in your Mule application using these headers: - -* `X-SSL-Client-DN`: Contains the full distinguished name of the client certificate. Use this header to verify the Subject DN or Common Name (CN). -* `X-SSL-Client-Verify`: Returns `SUCCESS` if the client certificate is valid. Check this header to confirm that the DLB validated the certificate. -* `X-SSL-Client-Serial`: Contains the serial number that the CA uses to identify the client. Use this header to match against authorized client certificate serial numbers. - -By validating these headers in your backend application, you can restrict access to specific authorized clients. +To verify client identity beyond CA trust validation, inspect the client certificate details in your Mule application. Use the `X-SSL-Client-DN` header to verify the Subject DN or Common Name (CN), and use the `X-SSL-Client-Serial` header to match against authorized client certificate serial numbers. By validating these headers in your backend application, you can restrict access to specific authorized clients. == Add Revocation Lists From 2cb32d01a3453e215beb588d788550d2e46b9526 Mon Sep 17 00:00:00 2001 From: Luana Dos Santos <84200607+luanamulesoft@users.noreply.github.com> Date: Wed, 21 Jan 2026 13:29:07 -0300 Subject: [PATCH 3/4] Update lb-cert-validation.adoc --- cloudhub/modules/ROOT/pages/lb-cert-validation.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc index 463b544d2..179fe6264 100644 --- a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc +++ b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc @@ -56,7 +56,7 @@ 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 isn't part of the intended client chain. The DLB accepts it because you uploaded `Intermediate CA1` and `CA2` as trusted CAs. +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] ==== From ab9e24fdb0a7e604abaa120cf0653f6bb19c7517 Mon Sep 17 00:00:00 2001 From: Luana Dos Santos <84200607+luanamulesoft@users.noreply.github.com> Date: Wed, 21 Jan 2026 13:40:34 -0300 Subject: [PATCH 4/4] Update lb-cert-validation.adoc --- cloudhub/modules/ROOT/pages/lb-cert-validation.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc index 179fe6264..ea64e1525 100644 --- a/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc +++ b/cloudhub/modules/ROOT/pages/lb-cert-validation.adoc @@ -65,7 +65,7 @@ The DLB doesn't enforce client identity. It only verifies that the certificate i === Implement Client Identity Verification -To verify client identity beyond CA trust validation, inspect the client certificate details in your Mule application. Use the `X-SSL-Client-DN` header to verify the Subject DN or Common Name (CN), and use the `X-SSL-Client-Serial` header to match against authorized client certificate serial numbers. By validating these headers in your backend application, you can restrict access to specific authorized clients. +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