Virtual Server with public CA Cert and Internal CA Authentication

Actually, all of this is done in the client SSL profile.

 

 

There are two sections to the client SSL profile:

 

 

(top) Configuration - this is the section you configure for the server side of the SSL negotiation. It specifies the (public) CA certificate and key that is referenced by the HTTPS://FQDN. The only values that are absolutely necessary in this top section are the server certificate and key. When the client starts the SSL conversation with the server, the first response from the server (SERVERHELLO) contains the server's certificate. It is the client's responsibility to validate this certificate based on its local (browser) trusted certificate store.

 

 

 

Client Authentication - this is the section you configure for the client certificate side of the SSL negotiation. Here you specify that you want to request or require the client certificate. Depending on your BIG-IP version, the "Trusted Certificate Authorities" drop down box is either in the top of the client SSL profile or in this section. For all intents and purposes it should be in this section and was moved here appropriately in v11. After the SERVERHELLO message the server (BIG-IP) will request the client certificate. Once the client's certificate has been received, it is the BIG-IP's responsibility to validate that certificate (build the entire trust chain from entity to root and verify information in all chained certs) by virtue of the Trusted Certificate Authorities file. This file is either the single PEM certificate of the root CA that issued the client certificate, or a text file containing all of the PEM-based certificates necessary to build a complete trust chain (root CA -> subordinate CA -> entity).

 

 

So to more directly answer your question, the public CA will have absolutely nothing to do with client certificate validation. Your Trusted Certificate Authorities bundle only needs to contain your internal Microsoft CA file (in PEM format).