SSL/TLS Client Authentication is being used more and more for communications between different enclaves. This addition to the server based SSL/TLS handshake involves the Client presenting credentials to the Server in the same manner as the Server does to the Client. If the credentials presented by the Client are not trusted, then the Server will sever the connection just as the Client would have if the situation was reversed. Since a Client initiates contact with the Server, the Server’s credentials are simply to validate it is who the Client was trying to contact. This is accomplished through Certificate Authorities (CA) and the Trust Hierarchies built into the Public Key Infrastructure (PKI). Even though you can optionally add a particular Server’s credentials directly into a Client so that it will implicitly trust a particular Server essentially bypassing the distributed trust mechanism in favor of a more direct one, this is the only way to build a relationship for a Client to a Server.

In the following steps, the client will refer to the entity sending the request, and the server will refer to the entity receiving the request. If you are setting up client authentication for requests inbound to Repose, then the entity sending the request is the client and Repose is the server. If you are setting up client authentication for requests outbound from Repose to the origin service, then Repose is the client and the origin service is the server.

With your certificates in the right spot it’s time to turn authentication on for Valve. This is achieved with a simple tweak to the container.cfg.xml.

To turn on authenticated communication to your origin service, you’ll need to tweak the default pool in your HTTP Connection Pool service config. There is nothing stopping you from similarly tweaking any of your other pools if you have a need to use client authentication in other outbound communication.