From Theory to Practice: mTLS in Action on AWS ALB – Part 2

Scenario Overview: mTLS Communication

To better understand how mTLS works in practice, let’s walk through a common infrastructure pattern that often appears in my articles.

Imagine an internal microservice‑oriented application running entirely inside a private Amazon VPC. The workloads are deployed on AWS EKS cluster. An Internet‑facing Application Load Balancer (ALB) anchored in the public subnets listens public clients’ requests on port 443, terminates TLS and forwards traffic to a target group that, in its turn, points at the public Istio Ingress Gateway (i.e. pods) running inside the cluster. Once inside the mesh, Istio Service Mesh enforces mutual TLS between microservices, applies fine‑grained authorization based on JWT claims. Additionally, the public Istio Virtual Service helps us to direct requests coming from the public Istio Ingress Gateway to the certain Kubernetes Service, backing the target microservice application pods – see Figure 1.

Suppose an IoT device deployed device deployed in the field needs to securely connect to a backend service. Since mutual TLS (mTLS) is required, both the IoT device and the backend application must authenticate each other before any data can be exchanged.

Before communication can happen, each side must generate and possess specific certificates and keys

On the IoT device side:

1. IoT device private key
2. IoT device certificate – proves the IoT device’s identity to the Backend application
3. IoT device CA certificate – to validate the “Backend applicaion certificate”. This CA certificate is top-level certificate in the chain of trust, issued by a trusted Certificate Authority (CA). It is used to validate the authenticity of all certificates in the chain (in our case – the Backend application certificate) and must be present in the trust store.

On the Backend applicaion side:

1. Backend application private key
2. Backend application certificate – proves the Backend’s application identity to the IoT device
3. Backend application CA certificate – to validate the “IoT device certificate”. This CA certificate is top-level certificate in the chain of trust, issued by a trusted Certificate Authority (CA). It is used to validate the authenticity of all certificates in the chain (in our case – the IoT device certificate) and must be present in the trust store.

Once both parties have the necessary certificates, an mTLS handshake can begin. The process is identical regardless of which side initiates the connection, the only difference is which party acts as the client and which as the server.

Lets consider both directions.

IoT Device Acts as the Client, Backend Application Acts as the Server

1. Client → Server – Client Hello
   The IoT device starts the handshake and advertises the TLS versions and cipher suites it understands.
2. Server → Client – Server Certificate
   The backend presents its X.509 certificate chain.
3. Client – Validate server
   The device checks that the chain is signed by a CA in its local trust store. If the chain is valid and the hostname matches, the handshake continues.
4. Server → Client – CertificateRequest
   The backend asks the device to prove its own identity.
5. Client → Server – Client Certificate
   The device sends its certificate chain and a CertificateVerify message proving it holds the private key.
6. Server – Validate client
   The backend verifies the device’s chain against the CA certificates it trusts.
7. Both sides – Key exchange & Finished
   After mutual validation, they derive shared session keys and switch to encrypted application data.

Backend Application Acts as the Client, IoT Device Acts as the Server

Exactly the same seven steps occur, but the order of certificate presentation flips:

1. Client Hello – The backend starts the handshake.
2. Server Certificate – The IoT device (now acting as the server) responds with its certificate.
3. Client Validation – The backend verifies the device’s certificate.
4. CertificateRequest – The IoT device requests the backend’s certificate.
5. Client Certificate – The backend sends its certificate chain and proves ownership.
6. Server Validation – The IoT device validates the backend’s identity.
7. Key Exchange & Encrypted Communication – Both sides derive session keys and begin secure traffic.

In both cases, what separates mTLS from regular TLS is the mutual authentication step, i.e. each side verifies the other’s certificate chain using a trusted CA. Once that trust is established, all communication occurs over an encrypted and tamper-proof channel.

AWS ALB in the mTLS

Based on the infrastructure shown in Figure 1, let’s walk through how to configure mutual TLS (mTLS) using AWS Application Load Balancer (ALB), specifically for the case where the IoT device acts as the client and the backend application is hosted behind the ALB.

In the reverse scenario, where the backend application initiates the connection (acting as the client), it simply includes its own certificate in each request. The IoT device then verifies the backend’s identity before accepting or processing any data.

According to the AWS ALB mTLS documentation, there are two supported modes for mutual TLS:

Mutual TLS passthrough.

In passthrough mode, the ALB does not perform client certificate validation. Instead, it forwards the entire client certificate chain to the target (backend application in our case) via HTTP headers.

This mode is useful when, for instance, compliance reason we want full control over client certificate validation and authorization.

Mutual TLS verify.

In verify mode, the ALB validates the client certificate itself during the TLS handshake. If the certificate is valid and signed by a trusted CA (that we in advance configure in the ALB trust store), the connection is allowed to proceed.

This mode is useful when:

• We want the ALB to block unauthenticated clients before traffic even reaches a backend application
• We prefer to manage trust at the edge, reducing the load on backend applications

Both modes support advanced use cases, but verify mode is often the preferred option when security needs to be enforced early and consistently. Passthrough mode, on the other hand, offers more flexibility for environments where custom logic is required.

AWS ALB Mutual TLS verify

In this article, let’s focus on implementing AWS ALB mTLS in verify mode for our use case scenario, where the IoT device acts as the client and the backend application sits behind an ALB.

In this setup, the AWS ALB is responsible for authenticating the IoT device’s certificate during the TLS handshake before any traffic is forwarded to the backend service. This offloads the responsibility of client validation from the application and helps block untrusted requests right at the edge.

To configure this, we need to use a few AWS services.

First, we use the AWS Trust Store, which is backed by Amazon S3, to store the CA certificate that signed the IoT device’s certificate. This CA will be used by ALB to verify IoT device certificates.

In our case, we upload the IoT device CA certificate to the S3 bucket and reference to it while creating a Trust Store. This is the root (or intermediate) certificate that issued the IoT device’s identity certificate.

Next, we configure the AWS ALB listener to enable mutual TLS and specify that it should use the Trust Store for IoT device’s authentication.

During this step, we:

• Select “Mutual TLS authentication” as the connection type
• Choose “Verify with trust store” as the mode
• Link early created Trust Store

This configuration ensures that only clients presenting a valid certificate signed by CA can complete the handshake and reach backend application.

Conclusion

Mutual TLS (mTLS) offers a powerful way to establish two-way trust between clients and servers, making it a perfect fit for environments where identity assurance is critical, such as IoT, internal microservices or B2B integrations. While standard TLS secures the channel and verifies the server, mTLS goes a step further by authenticating the client as well.

In this article, we explored the foundations of TLS and mTLS, including how trust is built using digital certificates and PKI. We walked through an example with an IoT device acting as the client and explained how the mTLS handshake ensures mutual authentication before any data exchange occurs.

We then focused on how to implement mTLS using AWS Application Load Balancer (ALB) in verify mode. By leveraging AWS Trust Store and enabling certificate validation at the ALB level, we can shift the trust boundary closer to the edge, leading to simplifying backend logic while improving security and control.

Whether you’re dealing with smart devices, private APIs or regulated systems, AWS ALB with mTLS gives you a scalable and centralized way to manage client authentication and protect sensitive traffic.

Links

Mutual authentication with TLS in Application Load Balancer – Elastic Load Balancing

By Pavel Luksha, Senior DevOps Engineer, Klika Tech, Inc.