Client certificate authentication can be broken into two primary categories: revocation and validation.
Revocation is the process of determining if a certificate has been revoked by its issuer and involves processes like OCSP, CRLDP, and direct CRL lookup.OCSP and CRLDP are available in the Access Policy Manager module, and direct CRL lookup is available in the client SSL profile. Revocation is not explicitly required for client certificate authentication.
Validation on the other hand is the process of checking the client certificate for correct attributes. At the very least it's concerned with a) validity dates - that the certificate is not being used before or after a certain range of dates, and b) trust. Based on the notion that PKI (public key infrastructure) is a "three-party" system where two of the parties who trust a common authority, by transition will trust each other, certificate trust establishment is the cryptographic mechanism that an entity will use to establish a trusting "link" to that common authority. So for example, imagine a server (www.example.com) is issued a certificate by a subordinate certificate authority (ca-sub1.example.com), which was issued its certificate by the root certificate authority (ca.example.com).
www.example.com <-> ca-sub1.exmaple.com <-> ca.example.com
In this example you've established a chain of trust from the server certificate all the way to the (self-signed) root certificate by way of cryptographic signatures in each parent-child relationship. Now suppose a client is issued a certificate from another subordinate authority (ca-sub2.example.com) which was also issued its certificate from the same root CA (ca.example.com). When the client presents its certificate to the server, the server must build a chain from the client's certificate to the common root in order to establish "trust". On the BIG-IP, this is done using a bundle file that is assigned to the Trusted Certificate Authorities option in the client SSL profile. A bundle is a simple text file that contains the base64 PEM-encoded certificates of ALL of the possible client certificate issuers up to and including the self-signed root. The bundle would look something like this:
-----BEGIN CERTIFICATE-----
MIIDejCCAmKgAwIBAgIBBTANBgkqhkiG9w0BAQUFADBgMQswCQYDVQQGEwJVUzEY
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFxzCCBK+gAwIBAgICALEwDQYJKoZIhvcNAQEFBQAwYDELMAkGA1UEBhMCVVMx
...
-----END CERTIFICATE-----
...
So in the above example, the bundle should contain, at a minimum, ca.example.com and ca-sub2.example.com. If you've ever looked at the certificate store in your browser, the bundle file is the client certificate equivalent of that - an explicit list of certificates to trust. So in summary, in the client SSL profile, set Client Certificate to request or require and then select your CA bundle in the Trusted Certificate Authorities drop down. One other really cool feature of the BIG-IP client SSL profile, and something that many web servers can't do on their own is the notion of "root hints". If you apply a bundle file to the Advertised Certificate Authorities drop down, when the BIG-IP, as part of the SSL negotiation, requests the client's certificate, it will include a list (this list) of acceptable issuers. If you're in an organization that issues different certificates for different things from different issuers, and a user may have two or more of these certificates, this is a great way to selectively eliminate certificates from the list that the browser presents.