Masking 2-Way “Mutual” SSL Authentication using F5 LTM or HAProxy

Hello folks,

So a recent post I published talked about 1-Way vs 2-way SSL Authentication in some decent detail. We learned that 2-Way “Mutual” SSL Authentication can be used to enforce both parties attempting to communicate securely to provide authenticity. In other words, prove to each other that they are who they say they are. This can be very powerful from a security standpoint, but is it practical? The answer is, yes and no. The constraint comes from the aspect of administration (actually create certificates for each client) and manageability (keep accounting and maintaining actively lists of trusts) with the trade-off of proper authenticity. For example at first administering and managing 10 client certificates may be okay, but then imaging 100, or even a 1,000! So in this post I wanted to approach the idea of utilizing some tools we can use to offload some of this administration and management while maintaining Mutual Authentication with another entity. The idea revolves around one major assumption, users of a particular service (In this case a web-server) reside on a privately controlled and trusted network

My idea is if we have a group of clients residing on an internal privately addressed network, we can use either an F5 LTM or HAProxy to proxy our users’s connections destined for a service that is enforcing 2-Way SSL “Mutual” Authentication. The F5 LTM or HAProxy would perform the 2-Way SSL Mutual Authentication on behalf of each connecting user, eliminating the technical need to generate certificates for each client, while maintaining an element of mutual trust to the end service.

The basic idea is: (notice only our F5 LTM/HAproxy and the web-server perform 2-Way “Mutual” Authentication)

Preliminary Steps:

For the following steps please read my 1-Way vs 2-Way SSL Authentication Post.

  1. Create a the web-server’s CSR and Key

     

  2. Create the F5 & HAproxy Server-Side CSR and Key

     

  3. Create the F5 & HAproxy Client-Side (connection the client will actual connect to)

  4. Using our CA from my previous ariticle, sign all three of these certificates

    Sign the web-server’s CSR

    Sign the F5 & HAProxy Server-Side CSR (This is the connection the F5 makes to our backend pool members)

    Sign the F5 & HAProxy Client-Side CSR (This is the connection our users will connect to, the VIP)

     

  5. Configure Apache web-server to enforce the 2-Way “Mutual” Authentication

    Apache Config from previous post.

    Restart Apache

    For Troubleshooting create this index.php file

     

Masking with F5 LTM:

  1. Importing Certificates

    • Import virtual-service certificate
    • Import ha-client1 certificate
      • Use the same steps from above.
    • Import the rootCA certificate (used to authenticate the web-server)
      • Use the same steps from above.
    • All 3 Certificates imported
  2. Create the SSL Profiles
    • Create the client-side-connection SSL profile
    • Create the server-side-connection SSL profile
  3. Create the Server Pool
  4. Create the Virtual Server aka VIP
  5. Test by using Chrome to connect to our virtual-service

  6. Certificate revocation
    • Revoke the ha-client1.crt (The certificate the F5 authenticates with when connecting to the web-server)

    • Re-generate the CRL

      Notice the Serial Number 1005 is revoked in the CRL file now.

    • Replace the rootCRL.crl file on the web-server and restart Apache

    • Test using the virtual-service VIP on the F5 again.

Masking with HAProxy:

If you are unfamiliar with HAProxy, I recommend checking out my article on setting up HAProxy. Or my articles on using HAProxy as a F5 LTM replacement.

  1. Before we being, we have to generate and sign another certificate and key because we revoked the ha-client.crt perviously.

    And Sign it
  2. Copy All 3 certificates to our HAProxy server
  3. We need to chain the virtual-service certificate with the root CA certificate for HAProxy to accept it. (For help reference this)

    And ha-client2
  4.  Edit your haproxy.conf file to match
  5. Success!!
  6. Revocation test
    • Revoke and re-generate the rootCRL.crl file

      And re-generate the CRL
    • Reload Apache on our web-server to pick up the new CRL file
    • Now we test….

 

 

 

 

 

 

 

Leave a Reply

Time limit is exhausted. Please reload CAPTCHA.