The StrongAuth KeyAppliance TM (SAKA) utilizes Transport Layer Security (TLS) to protect sensitive information on the network between a calling client Application and the appliance. By default, each newly installed SAKA generates a key-pair and self-signed digital certificate to use for establishing TLS connections. At most sites, this setup is sufficient for the application to make secure connections to the SAKA.

When a Load Balancer is introduced in the network between the Application and the SAKA, it may become necessary to adopt a more sophisticated kind of certificate to allow connections passed through the Load Balancer to make a secure connection to whichever SAKA node the Load Balancer picks.

TLS Certificates

The TLS protocol is intended to provide secure and trusted data transmission between clients and servers. One of the key features of the TLS protocol is to unambiguously confirm the identity of the server and client during the TLS Handshake through the use of TLS digital certificates. The certificate the server presents to the client must be trusted by the client in order to establish a connection.

The problem created by introducing a Load Balancer into this environment is that the client application is making a connection to the Load Balancer before it establishes a secure connection with the SAKA. When the SAKA presents its certificate to the client, if the SAKA is using a self-signed digital certificate, the client will reject the certificate even if it is trusted. This is because the Application is trying to connect to the fully qualified domain name (FQDN) of the Load Balancer but is being presented a certificate that contains the FQDN of the SAKA.

While it may be tempting to solve this problem by creating a certificate for all SAKA nodes to present the FQDN of the Load Balancer, this approach is also problematic. While the TLS connection between the Application and the SAKA will be successfully established, Key Custodians and Domain Administrators will no longer be able to make direct connections to the SAKA to perform their administrative tasks (without having to manipulate host file entries on their client device).

Certificate Extensions

X.509 Digital Certificates, of which TLS certificates are a subset, offer many types of certificate extensions that can be used to restrict or enhance a certificate's usage. To solve the problem created by the introduction of a Load Balancer, a new certificate can be created for the SAKA utilizing the subjectAlternativeName (SAN) extension. The SAN wascreated by the Internet Engineering Task Force (IETF) to allow a digital certificate to present additional names to the client application without having to reconfigure network tables. The additional names can be of the types DNS Names, IP Addresses, and Directory Names.

The SAN extension in a TLS certificate allows a server to present multiple aliases for the FQDN to identify the server. Therefore, creating a certificate for the SAKA, that includes a SAN extension with additional FQDN in the DNS Name – typically that of the Load Balancer - solves both the problem of the application connecting to the SAKA and Key Custodians and Domain Administrators connecting directly to the appliance.