certificate based authentication using LTM

When you say "the certificate based authentication is not working", are you referring to the certificate-based authentication to the CAS server? If so, that is to be expected. While this does NOT specifically apply only to LTM, any time you terminate (and optionally re-encrypt) the SSL communications between a client and server with a proxy device, you will lose the client's certificate in the SSL handshake. The client sends its certificate with a digital signature signed with its private key, and since the proxy does not have access to the client's private key, the proxy cannot send the client's certificate in the server side SSL handshake. There are, however, many options to consider:

1. The LTM is a full proxy between OSI layers 4 through 7, so it not only proxies at layer 4 (TCP/UDP) and layer 7 (HTTP, etc.), but also at layers 5/6 (SSL/TLS). This allows the LTM to apply separate SSL "profiles" to each side of the conversation, each with potentially different authentication and cipher requirements. Further, once the LTM terminates the client side SSL, it has full access to the X.509 attributes of the client certificate. With this you can perform additional CRL, CRLDP, and OCSP revocation checks, and any other X.509 attribute evaluations you can think of, within iRules.

    

2. Exchange CAS servers also support Kerberos authentication, so with the Access Policy Manager (APM) module, you could offload client side SSL, request a client certificate, and then transform that into Kerberos authentication on the server side.

    

3. If none of the above are options for you, there is another method called "ProxySSL" that may do what you need. This method provides an SSL "man-in-the-middle" capability so that the client and server can continue to negotiate SSL between each other, and the LTM can "see" inside this encrypted payload. This would be useful for implementing content inspection security and cookie-based persistence.

    

4. If all else fails, you can remove the client and server SSL profiles from the LTM virtual server and let the client-server SSL pass through the proxy unaltered. Because you have no insight on the payload at the proxy layer, you'll be limited to things like source address persistence and anything you can evaluate at layer 4 (TCP).