Skip to content

W-18989901-DLB-2way-cert-validation #838

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
luanamulesoft merged 4 commits into from
Jan 21, 2026
Merged

W-18989901-DLB-2way-cert-validation #838

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
6f17ff4
W-18989901-DLB-2way-cert-validation
luanamulesoft Jan 17, 2026
907ff9d
removed repetition
luanamulesoft Jan 17, 2026
2cb32d0
Update lb-cert-validation.adoc
luanamulesoft Jan 21, 2026
ab9e24f
Update lb-cert-validation.adoc
luanamulesoft Jan 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions cloudhub/modules/ROOT/pages/lb-cert-validation.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,40 @@ 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.
Expand Down