Mutual authentication with TLS in Application Load Balancer - Elastic Load Balancing
Before you beginHTTP headersConnection logs

Mutual authentication with TLS in Application Load Balancer

Mutual TLS authentication is a variation of transport layer security (TLS). Traditional TLS establishes secure communications between a server and client, where the server needs to provide its identity to its clients. With mutual TLS, a load balancer negotiates mutual authentication between the client and the server while negotiating TLS. When you use mutual TLS with Application Load Balancer, you simplify authentication management and reduce the load on your applications.

By using mutual TLS with Application Load Balancer, your load balancer can manage client authentication to help ensure that only trusted clients communicate with your backend applications. When you use this feature, Application Load Balancer authenticates clients with certificates from third-party certificate authority (CA) or by using the AWS Private Certificate Authority (PCA), optionally, with revocation checks. Application Load Balancer passes on client certificate information to the backend, which your applications can use for authorization. By using mutual TLS in Application Load Balancer, you can get built-in, scalable, managed authentication for certificate-based entities, that uses established libraries.

Mutual TLS for Application Load Balancers provides the following two options for validating your X.509v3 client certificates:

Note: X.509v1 client certificates are not supported.

  • Mutual TLS passthrough: When you use mutual TLS passthrough mode, Application Load Balancer sends the whole client certificate chain to the target using HTTP headers. Then, by using the client certificate chain, you can implement corresponding load balancer authentication and target authorization logic in your application.

  • Mutual TLS verify: When you use mutual TLS verify mode, Application Load Balancer performs X.509 client certificate authentication for clients when a load balancer negotiates TLS connections.

To get started with mutual TLS in Application Load Balancer using passthrough, you only need to configure the listener to accept any certificates from clients. To use mutual TLS with verification, you must do the following:

  • Create a new trust store resource.

  • Upload your certificate authority (CA) bundle and, optionally, revocation lists.

  • Attach the trust store to the listener that is configured to verify client certificates.

For step-by-step procedures to configure mutual TLS verify mode with your Application Load Balancer, see Configuring mutual TLS on an Application Load Balancer.

Before you begin configuring mutual TLS on your Application Load Balancer

Before you begin configuring mutual TLS on your Application Load Balancer, be aware of the following:

Quotas

Application Load Balancers include certain limits related to the amount of trust stores, CA certificates, and certificate revocation lists in use within your AWS account.

For more information, see Quotas for your Application Load Balancers.

Requirements for certificates

Application Load Balancers support the following for certificates used with mutual TLS authentication:

  • Supported certificate: X.509v3

  • Supported public keys: RSA 2K – 8K or ECDSA secp256r1, secp384r1, secp521r1

  • Supported signature algorithms: SHA256, 384, 512 with RSA/SHA256, 384, 512 with EC/SHA256,384,512 hash with RSASSA-PSS with MGF1

CA certificate bundles

The following applies to certificate authority (CA) bundles:

  • Application Load Balancers upload each certificate authority (CA) certificate bundle as a batch. Application Load Balancers don't support uploading individual certificates. If you need to add new certificates, you must upload the certificates bundle file.

  • To replace a CA certificate bundle, use the ModifyTrustStore API.

Certificate order for passthrough

When you use mutual TLS passthrough, the Application Load Balancer inserts headers to present the clients certificate chain to the backend targets. The order of presentation starts with the leaf certificates and finishes with the root certificate.

Session resumption

Session resumption is not supported while using mutual TLS passthrough or verify modes with an Application Load Balancer.

HTTP headers

Application Load Balancers use X-Amzn-Mtls headers to send certificate information when it negotiates client connections using mutual TLS. For more information and example headers, see HTTP headers and mutual TLS.

CA certificate files

CA certificate files must satisfy the following requirements:

  • Certificate file must use PEM (Privacy Enhanced Mail) format.

  • Certificate contents must be enclosed within the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- boundaries.

  • Comments must be preceded by a # character and must not contain any - characters.

  • There cannot be any blank lines.

Example certificate that is not accepted (invalid):

# comments

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 01
    Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
        Validity
            Not Before: Jan 11 23:57:57 2024 GMT
            Not After : Jan 10 00:57:57 2029 GMT
        Subject: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub: 
                    00:01:02:03:04:05:06:07:08
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                00:01:02:03:04:05:06:07:08
            X509v3 Subject Alternative Name: 
                URI:EXAMPLE.COM
    Signature Algorithm: ecdsa-with-SHA384
         00:01:02:03:04:05:06:07:08
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

Example certificates that are accepted (valid):

  1. Single certificate (PEM–encoded):

    # comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

  2. Multiple certificates (PEM–encoded):

    # comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

HTTP headers and mutual TLS

This section describes the HTTP headers that Application Load Balancers use to send certificate information when negotiating connections with clients using mutual TLS. The specific X-Amzn-Mtls headers that the Application Load Balancer uses depends on the mutual TLS mode that you've specified: passthrough mode or verify mode.

For information about other HTTP headers supported by Application Load Balancers, see HTTP headers and Application Load Balancers.

HTTP header for passthrough mode

For mutual TLS in passthrough mode, Application Load Balancers use the following header.

This header contains the URL-encoded PEM format of the entire client certificate chain presented in the connection, with +=/ as safe characters.

Example header contents:

X-Amzn-Mtls-Clientcert: -----BEGIN%20CERTIFICATE-----%0AMIID<...reduced...>do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID1<...reduced...>3eZlyKA%3D%3D%0A-----END%20CERTIFICATE-----%0A

HTTP headers for verify mode

For mutual TLS in verify mode, Application Load Balancers use the following headers.

This header contains a hexadecimal representation of the leaf certificate serial number.

Example header contents:

X-Amzn-Mtls-Clientcert-Serial-Number: 03A5B1

This header contains an RFC2253 string representation of the issuer's distinguished name (DN).

Example header contents:

X-Amzn-Mtls-Clientcert-Issuer: CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=US

This header contains an RFC2253 string representation of the subject's distinguished name (DN).

Example header contents:

X-Amzn-Mtls-Clientcert-Subject: CN=client_.com,OU=client-3,O=mTLS,ST=Washington,C=US

This header contains an ISO8601 format of the notBefore and notAfter date.

Example header contents:

X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Z

This header contains a URL-encoded PEM format of the leaf certificate, with +=/ as safe characters.

Example header contents:

X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0A

Connection logs for Application Load Balancers

Elastic Load Balancing provides connection logs that capture attributes about the requests sent to your Application Load Balancers. Connection logs contain information such as the client IP address and port, client certificate information, connection results, and TLS ciphers being used. These connection logs can then be used to review request patterns, and other trends.

To learn more about connection logs, see Connection logs for your Application Load Balancer