Mutual TLS at the edge for regulated integrations

Client-certificate-authenticated endpoints for integrations with national tax and credit-registry authorities, terminated on an internet-facing Application Load Balancer that validates the full client certificate chain before a single request reaches the application layer.

ALB mTLSAWS ACMAWS WAFEKSOpenSearch

Overview

A handful of integrations — a government tax authority's exchange service, a national credit registry, and an internal partner platform — require mutual TLS: the server proves who it is (as usual), but the client also has to present a certificate the server trusts before the connection is allowed at all. This write-up covers doing that validation at the load balancer, so an unauthenticated client never reaches the application.

[ External clients ] ──► [ Application Load Balancer ]  ← validates client cert
                                    │                        against trust store (S3)
                          (default TLS cert: ACM,           ← default cert for
                           *.example-finance.com)               non-mTLS listeners
                                    │
                          [ AWS WAF ]  ──► [ OpenSearch — request logging ]
                                    │
                          [ internal NLB ]
                                    │
                          [ ingress-nginx — EKS ]
                                    │
                          [ application pods ]

1. Request flow

An external DNS request for the integration hostname resolves to the ALB.
The ALB has mTLS enabled on the relevant listener. It checks the presented client certificate against a CA bundle (clients-ca.pem) held in an S3-backed AWS trust store.
If the chain validates, the request is forwarded to an internal Network Load Balancer, then to ingress-nginx running inside EKS, and on to the relevant application pods.
If the chain doesn't validate, the connection is rejected at the ALB — it never reaches ingress-nginx or the application.
AWS WAF sits in front of the ALB for OWASP Top-10 coverage and bot mitigation; request logs are shipped to an OpenSearch cluster for investigation and alerting.

2. ALB & trust store configuration

Component	Purpose
ACM certificate — `*.example-finance.com`	Default server-side TLS cert for the listener
AWS Trust Store	Holds the CA bundle used to validate incoming client certificates
S3 object — `clients-ca.pem`	Source of truth for the trust store; update here to rotate or add a partner CA
ALB listener rule	mTLS mode set to verify (reject unless the client cert validates) rather than passthrough

Keep the trust store's source CA bundle in version control (even if it's just the S3 object with versioning enabled) — rotating or revoking a partner's certificate should be a reviewable change, not a manual edit no one remembers making.

3. Staged environments per integration

Each integration partner gets its own DEV, TEST, and PROD hostname, so one partner's certificate rollover or schema change can be validated end to end without any risk to the others. The full endpoint matrix for the three mTLS-protected integrations in scope:

Integration	Environment	Domain pattern (illustrative)	Description
National tax authority exchange service	DEV	dev-taxexchange.example-finance.com	Development and internal testing against the authority's sandbox
	TEST	test-taxexchange.example-finance.com	Integration testing with the authority's official test environment
	PROD	taxexchange.example-finance.com	Production endpoint for secure communication with the tax authority
Core banking platform internal/partner core	DEV	dev.core-platform.example-finance.com	Development endpoint for internal core-services integration
	TEST	test.core-platform.example-finance.com	Testing environment for core platform integration
	PROD	core-platform.example-finance.com	Production endpoint for secure communication between internal services and the core platform
National credit registry cross-border registry	DEV	dev-creditregistry.example-finance.com	Development and internal testing endpoint for the registry integration
	TEST	test-creditregistry.example-finance.com	Integration testing environment for the registry
	PROD	creditregistry.example-finance.com	Production endpoint for secure communication with the national credit registry

Three government- and partner-facing integrations, nine hostnames total, each independently issuable, testable, and revocable — a certificate problem on one integration's TEST hostname has zero blast radius on another integration's PROD traffic.

4. WAF and logging

AWS WAF is attached to the ALB with a mix of AWS managed rule groups (OWASP Top-10 coverage, known bad-bot signatures) and a small number of custom rules specific to these integrations — mostly rate-limiting, since these are low-volume, high-value B2G/B2B endpoints rather than public consumer traffic.

All WAF and access log data is shipped to a dedicated OpenSearch cluster, giving a single place to investigate a blocked request, confirm a partner's IP range, or build an alert on an unusual spike in rejected mTLS handshakes.

Go-live checklist

ACM certificate issued and validated for the integration's default listener hostname
Partner CA bundle uploaded to the S3-backed trust store and referenced by the ALB
ALB listener rule set to enforce (not passthrough) client certificate verification
WAF attached with managed rule groups plus any integration-specific rate limits
OpenSearch logging confirmed to be receiving both WAF and ALB access logs
DEV and TEST hostnames validated with the partner before cutting PROD over
Certificate expiry monitored — partner-issued client certs are outside your own renewal automation

Mutual TLS at the edge for regulated integrations

Overview

1. Request flow

2. ALB & trust store configuration

3. Staged environments per integration

4. WAF and logging

Go-live checklist

References