APM Session Variable Not Being Cached

Generally speaking, session.ssl.cert.cn isn't a session variable that gets populated. Try:

session.ssl.cert.subject

If you're wondering which variables are getting set in the access policy, try this from the command line:

sessiondump -allkeys

I updated my Client Inspection rule to be: * expr { [mcget {session.ssl.cert.subject}] == "subject.domainname.com" } I also updated my Logging and Message Box rules to include %session.ssl.cert.subject%

The Cert Inspection failed and the client cert subject was neither written to the log event nor the message windows. After that I tried updating the expression to read: * expr { [mcget {session.ssl.cert.subject}] == * }

The Client Inspection rule failed stating it encountered an unexpected value "*". After that I tried updating the expression to read: * expr { [mcget {session.ssl.cert.subject}] conaints ".domainname.com" }

In all attempts the session variable value was not written to the log nor message window.

I also executed sessiondump -allkeys from the command line however nothing was returned.

The first thing I'd do is remove all of the special conditions from your Client Cert Inspection agent and test again (as in set it back up to evaluate for a valid certificate). Assuming that evaluation passes, you should see all of your session.sl.cert.* data in the sessiondump. By the way, you are getting prompted for a client certificate, yes? The session.ssl.cert.subject value is going to be the full distinguishedName of the subject. Example:

cn=bob.user,ou=mycompany,o=myorg,dc=mydc,dc=com

so you'll either need to modify your conditional a little, or strip off what you need from this before the evaluation.

The first thing I'd do is remove all of the special conditions from your Client Cert Inspection agent and test again (as in set it back up to evaluate for a valid certificate). Assuming that evaluation passes, you should see all of your session.sl.cert.* data in the sessiondump. By the way, you are getting prompted for a client certificate, yes? The session.ssl.cert.subject value is going to be the full distinguishedName of the subject. Example:

cn=bob.user,ou=mycompany,o=myorg,dc=mydc,dc=com

so you'll either need to modify your conditional a little, or strip off what you need from this before the evaluation.

I tried the default Client Cert Inspection rule initially but with no success. My workstation would get prompted for a client certificate and would present a firstname.lastname@im.companydomain.com certificate.

I believe the problem was that the LTM does not have the necessary CA to enter in the VIP SSL client profile "Trusted Certificate Authority" configuration setting.

I tried importing certificates to my Windows 7 workstation whose CAs exist on the LTM but was still unsuccessful. Although I successfully imported the certificates to my workstation, when prompted for a client certificate the only option available was that same firstname.lastname@im.companydomain.com.

Since the real objective was to ensure end user clients presented a specific client certificate (not just any client certificate whose CA matches what's configured in the VIPs SSL client profile "Trusted Certificate Authority" setting) I abandoned efforts to evaluate for a 'valid' certificate.

Understood. The Client Certificate Inspection agent in the visual policy relies on settings in the Client SSL profile. Specifically, you need to:

1. Set Client Certificate (under Client Authentication) to Request or Require. This can also be done with the On-Demand Cert Auth agent, but it's somewhat redundant to use this and the Client Certificate Inspection agent.

    

2. Set the Trusted Certificate Authorities option to either a single CA or a bundle of CAs. When the client presents its certificate to the server (BIG-IP), the server must be able to validate that certificate based on validity, expiration, and trust. The CA or CA bundle in this option is used to built the trust chain from the client's certificate through an explicitly trusted chain of CAs.

    

3. Optionally you can set the Advertised Certificate Authorities option. When the server sends its CertificateRequest message to the client, it can optionally send a list of supported CAs, called a "root hint", that most browsers will check before prompting the client to send a certificate. In this way you can potentially limit the choices that a user can make by filtering the list of possible client certificates to just the ones issued by the CAs in the root hint.

    

What I would do at this point is simply remove the access policy and ensure that basic mutual PKI authentication happens - that you get a certificate prompt, that you send a certificate, that the server (BIG-IP) validates that certificate, and that you get to the web server behind the BIG-IP. Once that works, you can re-apply the access policy. The session.ssl.cert.* session variables will be populated as soon as the client sends its certificate and the client SSL profile accepts it. You could therefore add a message box at the beginning of the visual policy to look at session.ssl.cert.subject.

We got past the client cert validation issue and got things working.

Thank you very much for your help.