Introducing mTLS for Application Load Balancer

AWS recently announced support for mutually authenticating clients that present X509 certificates to Application Load Balancer (ALB). In this post, we discuss options for implementing this new feature, and things to consider while implementing.

ALB operates at the application layer (layer 7 in the OSI model) and load balances incoming HTTP/HTTPS requests to backend targets. It is commonly used to create scalable and secure web applications, and supports advanced routing rules that allow you to load balance based on application attributes like the host name, complete path, or route based on HTTP header conditions. Check out the Application Load Balancer documentation for more details.

From a security perspective, ALB allows you to create HTTPS listeners. With an HTTPS listener, the ALB will terminate the TLS session from the client. ALBs also have native integration with AWS WAF that allows you to create rules for your web application and protect the applications running behind an ALB.

mTLS concepts

Mutual Transport Layer Security (mTLS) extends the TLS protocol used to secure network communications. TLS is commonly used to establish secure connections over the internet, ensuring authentication, data confidentiality, and integrity. However, in traditional TLS, the authentication is one-sided, where the server authenticates itself to the client, and the identity of the client is not verified.

In contrast, mTLS adds an extra layer of security by requiring both the server and the client to authenticate themselves to each other, hence the term “mutual” or “two-way” TLS. Some concepts relevant to mTLS are:

• Certificate Authority (CA): An organization/entity that provides TLS certificates to businesses. The CA validates the domain name and owner details before issuing the TLS certificate.
• TLS Certificate: A digital object that allows systems (like web clients) to verify the identity of another system (like a web server). Details in the TLS certificate allow the client to establish an encrypted connection to servers.
• Server Certificate: TLS certificate that proves the server’s identity.
• Client Certificate: TLS certificate that proves the client’s identity.
• Certificate chain of trust: An ordered list of TLS certificates. The chain begins with the left certificate (or the client/server’s TLS certificate) and ends with the root certificate. Any certificates between the leaf and root certificates are called intermediate certificates. Each certificate in the chain is signed by the organization/entity identified by the next certificate. This is shown in figure 1.

Figure 1: Certificate chain of trust

• TLS Handshake: The process that allows the client and server to authenticate each other using their TLS certificates, agree on encryption standards, and create a secure channel for transferring date. Refer to TLS documentation for more details. Clients share their TLS certificates with the server during the TLS handshake. This allows the server to authenticate clients.
• Certificate Revocation List (CRL): List of blocklisted certificates that should not be trusted.

The mTLS process is commonly used to secure communication between smart devices, APIs, microservices, and any situation where both parties must establish trust in each other’s identity, such as meeting regulatory requirements. It’s also used in virtual private networks (VPNs) and for securing internal communication within organizations.

To implement mTLS, both the server and client must have digital certificates issued by trusted CAs. These certificates can be generated by the same or different CAs and are used to prove the authenticity of each party during the handshake process.

Using mTLS client authentication with Application Load Balancer

Application Load Balancer supports mTLS when the client’s certificate chain is within a certain depth and size. Check out the documentation for Quotas for your Application Load Balancers to see the current maximum supported size and depth. You can use Application Load Balancer’s ClientCertExceedsDepthLimit and ClientCertExceedsSizeLimit Amazon CloudWatch metrics respectively to track any requests that breach these limits.

Application Load Balancer supports two modes of operation with mTLS: mTLS verify mode and mTLS passthrough mode.

mTLS verify mode

To use mTLS verify mode with Application Load Balancers, you must create a trust store. A trust store has one CA certificate bundle that is used to verify client certificates. You can either bring your own certificate or use AWS Certificate Manager (ACM) to generate a certificate. You can use an AWS managed CA for the mTLS verify mode with Application Load Balancer. AWS Private Certificate Authority is a highly available, managed CA service that helps organizations secure applications and devices using private certificates. Refer to the ACM documentation on issuing and managing certificates to learn more.

To specify which client certificates not to trust, you associate one or more certificate revocation lists (CRLs) with a trust store. You upload the revocation lists into an S3 bucket and specify the bucket under the trust store. ALB imports the CRL from S3, and any CRL checks are performed by the ALB without fetching the CRL from S3 every time. Because of this, ALB does not add any latency while authenticating clients against a CRL. Check out the Mutual authentication with TLS in Application Load Balancer page in our documentation for more details of CRL configuration.

In this mode, Application Load Balancer will verify the client certificate using a trust store. This ensures that only clients authenticated by valid certificates may communicate with backend targets. The ALB blocks requests from unauthenticated users. This allows you to offload the compute-intense processing required for mTLS authentication to Application Load Balancer and use your backend targets’ processing resources for delivering your application’s services. Figure 2 shows the architecture for verify mode.

Figure 2: Application Load Balancer configured in mTLS verify mode

The stages of mTLS in ALB’s verify mode are:

[1] Upload CA certificate bundle into Amazon S3, and optionally upload the CRL.

[2] Create the Trust Store, and provide the Amazon S3 path to the CA certificate bundle. Optionally provide Amazon S3 path to the CRL.

[3] Client initiates a TLS session with the ALB. During the TLS handshake, the client presents its TLS certificate.

[4] TLS session terminates at the ALB. During the TLS handshake, ALB presents the server-side certificate and receives the client’s certificate.

[5] ALB consults the trust store and validates the certificate. Client authentication will fail if the client certificate is not signed by a trusted CA, if the certificate is listed in a certificate revocation list (CRL), or if the client certificate has expired. Refer to the Mutual authentication with TLS in Application Load Balancer page in our documentation for a complete list of scenarios where client authentication may fail in the Application Load Balancer’s mTLS verify mode. If client authentication fails, Application Load Balancer rejects the TLS connection. For expired certificates, you can optionally configure the ALB to allow such connections.

[6] TLS Session is established successfully between the client and the ALB

[7] ALB creates a separate session to the backend targets.

Since the Application Load Balancer terminates the TLS session, you can use any of ALB’s routing algorithms for load balancing traffic to the backend targets. For example, you can use the weighted round-robin rule to create blue/green deployments of your web applications.

Besides performing client authentication, the Application Load Balancer also sends the following certificate metadata to the backend targets:

X-Amzn-Mtls-Clientcert-Serial-Number – Hexadecimal representation of the leaf certificate, or the client certificate, serial number, for example, 0ABC1234
X-Amzn-Mtls-Clientcert-Issuer – Issuer distinguished name (DN) printed with X509_NAME_print_ex with XN_FLAG_RFC2253 flag
X-Amzn-Mtls-Clientcert-Subject – Subject DN printed with X509_NAME_print_ex with XN_FLAG_RFC2253 flag
X-Amzn-Mtls-Clientcert-Validity – ISO8601 format of notBefore and notAfter date, for example, NotBefore=2023-09-21T01:50:17Z; NotAfter=2024-09-20T01:50:17Z
X-Amzn-Mtls-Clientcert-Leaf – URL encoded PEM format of leaf cert

This information allows you to implement logic based on these metadata fields on the backend targets. For example, you can parse on the X-Amzn-Mtls-Clientcert-Leaf field to get the expiration date of the certificate and send a custom message to the client if the certificate is nearing its expiration date.

mTLS passthrough mode

In this mode, ALB forwards the entire certificate chain to backend targets for client authentication in an HTTP header called AMZN-MTLS-CLIENT-CERT. ALB inserts the entire certificate chain, including the leaf certificate, in URL encoded PEM format, with +,=, and / as safe characters. Here’s an example of the AMZN-MTLS-CLIENT-CERT header:

X-Amzn-Mtls-Clientcert: 

-----BEGIN%20CERTIFICATE-----%0AMIID&lt;...reduced<br />...&gt;do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICAT<br />E-----%0AMIID1&lt;...reduced...&gt;3eZlyKA%3D%3D%0A-----END%20CERTIFICATE---<br />--%0A

The backend targets must be able to parse this HTTP header, extract the certificate, and perform client authentication. Use this mode if you want to retain control of the client authentication process. Figure 3 shows this architecture.

Figure 3: Application Load Balancer configured in mTLS passthrough mode.

The stages of mTLS in ALB’s passthrough mode are:

[1] Client initiates a TLS session with the ALB. During the TLS handshake, the client presents its TLS certificate.

[2] TLS session terminates at the ALB. During the TLS handshake, ALB presents the server-side certificate and receives the client’s certificate.

[3] ALB creates a new session with the backend targets. This session can either be HTTP or HTTPS, based on user configuration. ALB includes the entire certificate chain in an HTTP header called AMZN-MTLS-CLIENT-CERT.

[4] The backend targets receive the client certificate, and must implement the logic to parse the client certificate chain from the AMZN-MTLS-CLIENT-CERT HTTP header. The targets must also implement the logic to perform client authentication.

If there are no client certificates present when mTLS passthrough mode is enabled, the Application Load Balancer will not add any additional HTTP headers. The backend targets must implement the logic to handle incoming requests without client certificates.

If client authentication fails on the backend targets, the targets must handle sending an HTTP error code back to the Application Load Balancer. The ALB relays this error code back to the clients.

For an HTTPS listener, the backend targets authenticate the clients based on the certificate, and Application Load Balancer terminates the TLS connection between the clients and opens another TLS session with the backend targets. The TLS session between the ALB and the backend targets is created by using the certificates you install on the targets.

Since the ALB terminates the TLS session, you can use any of ALB’s routing algorithms for load balancing traffic to the backend targets.

Some smart devices may be offline for an extended period, for example, a smart car that temporarily loses internet connectivity. In these cases, you’d want to ensure that the backend targets implement logic to work with expired TLS certificates.

Implementing application-based cookies is another use case for implementing passthrough mode. In this use case, the backend targets issue cookies for authenticated clients, and the clients can use these cookies for communication. This ensures that the backend targets don’t need to process the entire certificate chain for each incoming request. You can use open source libraries to implement cookies on the backend targets, and then implement the logic to track client authentication status based on the cookie.

Monitoring

Application Load Balancer provides connection logs for all the requests that are sent to the load balancer. These logs are sent to an Amazon Simple Storage Service (Amazon S3) bucket and include details like the client’s IP address, details about the TLS cipher, and the error code in case the request was denied. Refer to Connection logs for your Application Load Balancer for details.

A complete list of CloudWatch metrics for Application Load Balancer’s mTLS support is available at CloudWatch metrics for your Application Load Balancer.

Comparison of ALB’s mTLS modes with Network Load Balancer (NLB)

If you have an HTTPS application, we recommend you consider ALB if you’d like to perform application level routing. For example, performing weighted round robin load balancing for HTTPS requests, which will allow you to create blue/green style deployments. ALB will also allow you to offload the TLS/mTLS operations. Since the ALB terminates client’s TLS session, you’ll need to upload certificates for the ALB.

NLB, on the other hand, operates at the transport layer (layer 4 of the OSI model), and provides low latency load balancing of TCP/UDP connections. For an HTTPS application, we recommend using Network Load Balancer (NLB) if you have specific security compliance rules that need the server to terminate the client’s TLS connection.

Table 1 compares passthrough mode and verify mode support for Application Load Balancer with NLB, and the considerations for each option.

Conclusion

In this post, we discussed the mTLS verify and passthrough modes for Application Load Balancer, and things to consider when using each mode. You use mTLS verify mode on Application Load Balancer when you want to use an ALB for client authentication. mTLS passthrough mode is best suited when you would like to keep control of client authentication on the backend targets. There are additional charges for using a trust store, and there are Application Load Balancer pricing considerations when enabling mTLS. Visit the Elastic Load Balancing pricing page for details.

This feature is available today, so try it out and contact AWS Support to let us know if you have questions or comments.

About the Authors

April 3, 2024: An inaccurate reference to a CloudFront metric was removed from this post.