How to configure mTLS on xdr-proxy with NLB

Context

AWS Application Load Balancer (ALB) operates at Layer 7 and expects HTTP/HTTPS traffic. 
Because the Aerospike XDR proxy communicates using raw TCP with TLS, ALB cannot be used for TLS passthrough in this scenario.

AWS Network Load Balancer (NLB) operates at Layer 4 and supports TCP passthrough, allowing TLS connections to terminate directly on the XDR proxy.
This allows the proxy to perform mutual TLS authentication with clients.

Method

To enable mutual TLS on the XDR proxy, configure the TLS service section in the aerospike-xdr-proxy.yml configuration file.

Set mutual-auth to true and configure allowed-peer-names with the list of client certificate names that are allowed to connect. These values must match the Common Name (CN) or Subject Alternative Name (SAN) contained in the client certificate.

Example configuration:

service:
  tls:
    port: 8443
    mutual-auth: true

    allowed-peer-names:
      - nlb.aws.aerospike.com

    protocols:
      - tlsv1.3

    trust-store:
      store-file: tls/ca.aerospike.com.truststore.jks
      store-password-file: tls/storepass
      key-password-file: tls/keypass
      store-type: JKS

    key-store:
      store-file: tls/connector.aerospike.com.keystore.p12
      store-password-file: tls/storepass
      key-password-file: tls/keypass

Determine the certificate Common Name (CN)

To verify the CN or SAN values in a certificate:

openssl x509 -in example.client.crt -noout -subject

Example output:

Subject: CN = nlb.aws.aerospike.com, O = "Aerospike, Inc.", C = US

These names must match entries in the allowed-peer-names configuration.

Documentation

Additional details about configuring TLS for the XDR proxy can be found here:
https://docs.aerospike.com/server/operations/configure/xdr-proxy/configuration/service#configuring-tls

Information about creating Java KeyStores and TrustStores is available here:
https://aerospike.com/docs/develop/client/java/mtls

Notes

To troubleshoot connectivity, you can test the TLS endpoint using curl:

curl https://nlb-name:8443 \
  --cert client.cert.pem \
  --key client.key.pem \
  --cacert ca.cert.pem

If you receive an error such as:

no alternative certificate subject name matches target host name

then the hostname used to connect does not match the CN or SAN fields in the certificate.
In this case, create a DNS record (for example using AWS Route 53) that maps the hostname used in the certificate to the NLB endpoint.

Applies To Earliest Version

Applies To Latest Version