Forum Discussion

Tim_E_299773's avatar
Tim_E_299773
Icon for Nimbostratus rankNimbostratus
Feb 23, 2017

Mutual Authentication over public internet

I'm having a little trouble finding configuration steps for mutual authentication over the public internet with a SaaS provider. See topology below.

 

(Inside Hosts) <--> F5 Serverssl <--> F5 Clientssl <--> Internet mutual authentication <--> (SaaS provider)

 

When building the clientssl profile, I understand that I use 'require' certificate for client authentication and select the CA which to authenticate against. Does the CA reference the certificate and key chosen above? I have my URL using "mutualauthenication.mycompanyname.org" and my cert is a *.mycompanyname.org. does the SaaS provider also have to have my cert and key on the other end for this to work? What I've read is, a cert on the SaaS server, the cert in the SSL profile need to be signed by the same Cert Authority?

 

LTM
security

4 Replies

Sort By
  • Fadly_Tabrani_1's avatar
    Fadly_Tabrani_1
    Icon for Nimbostratus rankNimbostratus
    Feb 23, 2017

    Based on the example configuration, I am assuming you are providing the service which the SaaS server is connecting to and you have wired up the virtual server with a publicly signed certificate.

     

    To answer your question,

     

    Mutual authentication is essentially based on trust, in this scenario:

     

    1. The certificate on the virtual server needs to be trusted by the Saas server. As this is a publicly signed certificate, that should be pretty straight forward.

       

    2. The certificate that the Saas server presents needs to be trusted by the virtual server. It is your choice which trusted CAs these certificates are issued from.

       

    For greater control, these should be issued by your internal PKI. You could also trust third-party CAs that issue certificates on your behalf.

     

    Do take note that any CAs you choose, needs to have its CRL available and imported to the F5 if you have the requirement of revocation checking.

     

    • domokos_23867's avatar
      domokos_23867
      Icon for Nimbostratus rankNimbostratus
      Feb 24, 2017

      When I first looked at the diagram I thought the internal server would initiate the connection towards the SAAS provider. In that case serverssl and clientssl need to be inversed. If the flow is from SAAS towards internal server as you assumed than it is correct. Some notes on the question if the answer provided was not clear enough :

       

      "Does the CA reference the certificate and key chosen above?" The certfificate and key you configured are not used in authenticating the SAAS provider - so no, it does not. The certificate you configured under clientssl is presented to SAAS when they connect to your virtual server. It is signed with your private key and if the certificate was issued by a trusted CA the SAAS should have no issues accepting it.

       

      "does the SaaS provider also have to have my cert and key on the other end for this to work" NO. When they connect to your virtual server you do reply with the certificate. And very important the key on the F5 is your private key. It should never, never leave the F5 :-)!!! If anybody gets a hold of it they can sign communication as if coming from you.

       

    • Tim_E_299773's avatar
      Tim_E_299773
      Icon for Nimbostratus rankNimbostratus
      Mar 07, 2017

      So then, does the SaaS provide their certificate and public key to me and I import them into my F5 SSL certificate list? How does the F5 validate that they are the only public host to access this connection?

       

    • Fadly_Tabrani_1's avatar
      Fadly_Tabrani_1
      Icon for Nimbostratus rankNimbostratus
      Mar 08, 2017

      You can validate by checking the certificate that is presented by the client (Saas) during the TLS handshake. The most unique attribute that you can check is the thumbprint of the certificate. The iRule below will check if the thumbprint is listed within a data group, disconnecting if its not in the list.

      You need to make sure the client SSL profile you are using is set to require/request.

      when CLIENTSSL_CLIENTCERT {

    binary scan [sha1  [SSL::cert 0]] H* _sha1_thumbprint

    if {! [class match $_sha1_thumbprint equals allowed_certsha1_dg] } {
        SSL::session invalidate
        reject
    }
}