user-guides

TLS & mTLS Architecture FAQ

For RC System Using Azure CR‑LB + Standard LBs

This FAQ explains how TLS and mTLS are implemented in the RC system architecture using Azure Cross-Region Load Balancer (CR‑LB) and Standard LBs. It covers certificate placement, sample commands, renewal flow, and how the FQDN maps to the certificates.

1. Do we bind SSL/TLS certificates on CR‑LB or Standard LB?

No.
Azure Cross‑Region Load Balancer (CR‑LB) and Standard Load Balancer operate strictly at Layer 4 (TCP). They do not support:

Encrypted traffic simply passes through to the Broker unchanged.

TLS/mTLS terminates ONLY on the Broker instance.

2. Where are certificates installed?

Certificates are installed on the Broker instances

Each Broker has its own unique server certificate matching its FQDN:

Types of certificates needed:

Certificate Used By Purpose
Server Certificate Broker Authenticates Broker to Controller/Target
Client Certificate Controller & Target Authenticates clients to Broker (mTLS)
CA Certificate / Intermediate CA All Trust validation for mTLS

CN/SAN must match the Broker hostname.

3. Where should certificates be stored?

Use Azure Key Vault (per region)

Each Broker VM/Pod retrieves from the local-region Key Vault:

Access method:

4. How does mTLS work in this architecture?

Step 1 — Client initiates TLS

Controller/Target opens outbound TCP 443 → CR‑LB → Standard LB → Broker.

Step 2 — Broker presents its server certificate

Client validates:

Step 3 — Client presents certificate

Broker validates:

Step 4 — Secure mTLS session established

LBs do not inspect the packets.

5. Does the LB need the Broker certificate?

No.
LBs are transparent TCP routers.

6. Certificate File Formats

7. Sample: Import Broker Cert to Key Vault

az keyvault certificate import   --vault-name kv-us   --name broker-us-1-cert   --file broker-us-1.pfx   --password "<pfx-password>"

8. Sample: VMSS or any other way of Broker Access to Cert

Assign Managed Identity

az vmss identity assign   --resource-group rg-us   --name vmss-b1-us

Grant Key Vault permissions

az keyvault set-policy   --name kv-us   --object-id <MSI_OBJECT_ID>   --certificate-permissions get list

9. Certificate Renewal / Rotation Process

Step 1 — Upload new cert to Key Vault

az keyvault certificate import   --vault-name kv-us   --name broker-us-1-cert   --file new-cert.pfx

Step 2 — Update VMSS extension or AKS Secret Store

Broker loads new cert on restart or via signal.

Step 3 — Drain and roll instances

az vmss update-instances   --instance-ids <ids>   --resource-group rg-us   --name vmss-b1-us

10. Do we need SAN entries for CR‑LB IPs?

No.

TLS validation uses the hostname used by the client. CR‑LB IP is internal routing only.

Example:

Client connects to: broker-us-1.company.com
LB forwards traffic → Broker B1
Broker presents cert for broker-us-1.company.com

No IP-based SAN needed.

11. Do we need separate certificates per Broker?

Yes.
Each Broker exposes its own hostname → each requires a certificate:

12. Do we configure SSL on CR-LB or Standard LB?

No. 100% unnecessary.

Both are TCP pass‑through devices.

Only the Broker handles TLS.

13. Example Broker Certificate Configuration

For broker-in-3.company.com:

Subject CN = broker-in-3.company.com
SAN = DNS:broker-in-3.company.com
Issuer = Your Private CA
Extended Key Usage = Server Authentication
Key Size = 2048 or 4096

14. TLS Flow Diagram

image

LBs simply route TCP packets.

15. Summary