Client-authenticated TLS

A "client-authenticated" TLS connection (sometimes referred to as a "shared certificate" TLS connection) provides a way for the server to limit communication to trusted clients only. For example, an HIE network which houses PHI can ensure that only trusted client connections are allowed by using client-authenticated TLS connections. Using client-authenticated TLS connections would not be feasible for a bank because it would require that every member of the bank obtain a verified certificate and associated private key.

In a client-authenticated TLS connection, both the client and the server (HIE) must obtain their own certificates and private keys. During the initial handshake, both the client and the server (HIE) must send their certificates (public keys) to each other. In addition, the client must be able to show proof that it has access to the private key associated with the certificate that it sent to the server. As part of the handshake mechanism, the server provides a list of all trusted organizations (usually certificate authorities). The client then attempt to find a certificate and private key associated with one of the server's trusted organizations. If the client can provide such a certificate, along with proof that it has the private key associated with it, the TLS connection is established and behaves from that point on just the same as a normal SSL/TLS connection.

The diagram below shows that both the client and the server must have obtained their own certificate and private key. The certificates are then exchanged with each other in order for the client-authenticated TLS connection to work. As with the standard SSL/TLS connection, the server's public key is used to establish an agreed upon communication session that then be used by both the client and the server to encrypt all data that is exchanged back and forth. The purpose of the client's public key is only to authenticate that the client is trusted.