For this demo, we are going to need a TLS Certificate that is going to be issued just for testing purposes.
Click on "Generate Certficate" which will return the contents for both private-key.pem and certificate.crt. Save them in your local computer.
Certificate details:
Step 1: Lets first send a request to ALB without a client certficate and we will notice TLS handshake fails.
curl -v https://mtls.exampleloadbalancer.com
Step 2: Now, after downloading the certificate and private key, we will test again providing them in the curl command.
curl -v https://mtls.exampleloadbalancer.com --key private-key.pem --cert certificate.crt
In the example above, the mTLS handshake happens successfully and ALB sends the client certficate information to the target using following HTTP headers:
Header | Description |
---|---|
X-Amzn-Mtls-Clientcert-Serial-Number | A hexadecimal representation of the leaf certificate serial number. |
X-Amzn-Mtls-Clientcert-Issuer | An RFC2253 string representation of the issuer's distinguished name (DN). |
X-Amzn-Mtls-Clientcert-Subject | An RFC2253 string representation of the subject's distinguished name (DN). |
X-Amzn-Mtls-Clientcert-Validity | An ISO8601 format of the notBefore and notAfter date. |
X-Amzn-Mtls-Clientcert-Leaf | URL-encoded PEM format of the leaf certificate, with +=/ as safe characters. |
When you use mutual TLS passthrough mode, ALB sends the whole client certificate chain to the target using HTTP headers. Then, by using the client certificate chain, you can implement corresponding authentication and authorization logic in your application.
curl -v https://mtls.exampleloadbalancer.com:8443 --key private-key.pem --cert certificate.crt
In the example above, the mTLS handshake happens successfully and ALB sends the entrire client certficate chain information to the target using following HTTP header:
Header | Description |
---|---|
X-Amzn-Mtls-Clientcert | URL-encoded PEM format of the entire client certificate chain presented in the connection, with +=/ as safe characters. |