How does AWS Application Load Balancer Work

AWS has announced that mutually authenticating clients that provide Application Load Balancer with X509 certificates will now be supported. You can now ensure that only trustworthy clients communicate with their backend apps by offloading client authentication to the load balancer with this new functionality. Based on AWS’s open-source Transport Layer Security (TLS) implementation S2N, this new feature protects developers against zero-day vulnerabilities and provides strong encryption.

B2B applications like online banking, automobile, and gambling use mutual authentication (mTLS) using digital certificates. Businesses commonly use it with a private certificate authority (CA) to authenticate consumer identities before providing information and services.

Customers have adopted third-party or self-developed solutions for mutual authentication, which come with extra effort and administrative overhead. These clients dedicate engineering resources to integrating the feature into their backend, maintain code updates to incorporate the most recent security patches, and make significant infrastructure investments to generate and swap out certificates.

You may use your developer resources to focus on other important projects with your completely managed, scalable, and affordable solution mutual authentication on Application Load Balancer. Revocation checks will be employed by your ALB to authenticate clients, and client certificate information will be sent to the target for application authorization.

Using Application Load Balancer to begin mutual authentication

Using the Amazon EC2 console, select Create Application Load Balancer from the ALB wizard in order to activate mutual authentication on ALB. In the Listeners and routing section, additional settings including security policy, default server certificate, and a new client certificate handling option to facilitate mutual authentication are shown when you select HTTPS.

You can specify how listeners respond to requests that include client certificates when mutual authentication (mTLS) is enabled. This covers certificate authentication performed by your Application Load Balancer as well as the volume of certificate metadata transmitted to your backend destinations.

There are two methods for mutual authentication. With the Passthrough option, your backend application receives all of the client certificate chains that were sent by the client via HTTP headers. After establishing a TLS connection and obtaining the client certificate during the handshake, the mTLS-enabled Application Load Balancer sends the requested content to the target application in HTTPS headers. For the client to be authenticated, the application must validate the client certificate chain.

When the Verify with Trust Store option is selected, the Application Load Balancer and the client authenticate one another and create a TLS connection to encrypt communication. With AWS new trust store capability, you may validate your client certificates by uploading any CA bundle containing roots and/or intermediate certificates produced by AWS Private Certificate Authority or any other third-party CA.

It needs choosing an already-existing trust store or starting a brand-new one. Your trusted certificates, certificate revocation lists (CRLs), and CAs are all stored in trust stores. For mutual authentication with clients, the load balancer makes use of a trust store.

In the Amazon EC2 interface, select Trust Stores from the left menu, then select Create trust store to utilize this option and establish a new trust store.

Amazon S3 Bucket CA Certificate Bunlde

An Amazon Simple Storage Service (Amazon S3) bucket containing CRLs and a CA certificate bundle in PEM format are your options. A trust store uses a collection of root or intermediate CA certificates, which are referred to as CA certificate bundles. When a CA revokes a client certificate due to compromise and you need to deny the revoked certificate, you can use CRLs. Once the trust store is created, you can add or remove CRLs and swap out CA bundles.

AWS CLI may be used to deliver user certificate information to targets, enable mutual authentication mode on the Application Load Balancer listener, and upload CA information. New APIs like create-trust-store can also be used with AWS CLI.

$ aws elbv2 create-trust-store –name my-tls-name \

–ca-certificates-bundle-s3-bucket channy-certs \

–ca-certificates-bundle-s3-key Certificates.pem \

–ca-certificates-bundle-s3-object-version <version>

>> arn:aws:elasticloadbalancing:root:file1

$ aws elbv2 create-listener –load balancer-arn <value> \

–protocol HTTPS \

–port 443 \

–mutual-authentication Mode=verify,

TrustStoreArn=<arn:aws:elasticloadbalancing:root:file1>

To enable mutual authentication, you can upload your own private CA’s bundle or CRLs to the Application Load Balancer trust store. Examples of private CAs that you may already have are AWS Private CA, third-party CA, and self-signed CAs.

In order to verify mutual authentication on Application Load Balancer, create a self-signed CA bundle and client certificate using OpenSSL, upload them to the Amazon S3 bucket, and utilize them with an ELB trust store, as per the detailed instructions.

The client certificate can be sent as part of the request using curl and the –key and –cert parameters:

$ curl –key my_client.key –cert my_client.pem https://api.yourdomain.com

In the event that a client fails to offer a certificate, presents an invalid or expired certificate, cannot locate a trust chain, any links in the trust chain expire, or the certificate is on the revocation list, mutual authentication may not succeed.

Whenever it cannot authenticate a client, Application Load Balancer will shut the connections and create new connection logs that contain comprehensive information about the requests made to your load balancer. Every log includes data on the client, including the IP address, handshake latency, TLS cipher, and client certificate information. These connection logs can be used to diagnose problems and examine request trends.