Client authentication random failure - 11.6 HF4

What have you done to troubleshoot cert auth?

1. Removed the CRL check?

    

2. Enable debug logging for SSL?

    

3. Enable debug logging for APM?

    

4. Are you doing cert auth in the client SSL profile or APM on-demand cert auth?

    

5. Are you extracting any information from the cert before launching the VPN? If so, what and do you know if that's working?

    

1 & 4) The CRL check I noted was no longer in the "certificate revocation list" under client authentication of the SSL client profile for the VPN connection. Originally (under 11.3) the client authentication options were set to use the parent profile "clientssl". On consultation with F5 support, we were advised to leave the clientssl profile as is and customise the client authentication for the VPN connection (which has been done). As it stands a loan device we have from F5 has this customisation and no CRL check but doesn't exhibit the problem.

2 & 3) Debug logs were sent to F5. I will likely do another debug check on SSL when I get a chance today. The APM logs previously had indicated that on the non-working machine, the certificate check returned a "1" and hence the certificate check process breaks.

5) Not sure where this would be configured or how to determine this.

1 and 4: just want to confirm that on the broken platform, that there is no CRL checking done in the client SSL profile (or parent profile) applied to the VIP. Are you requesting the client certificate from the client authentication section of the client SSL profile, or are you doing an On-Demand Cert Auth in the APM visual policy?

2 and 3: Can you elaborate on "certificate check"?

5: I'm asking what you're doing with the certificate information. Do you do any sort of authentication in the access policy based on the client's certificate?

Correct, there is no CRL checking occurring. We are doing on-demand cert auth in the APM Visual policy yes.

Regarding the "certificate check", I have enabled SSL debugging and this is what I am seeing (also on the loan device now). I extended handshake to 30 seconds in the interim.

*********** working example ***********

Session variable 'session.ssl.cert.valid' set to '1' Session variable 'session.ui.mode' set to '7' Executed agent '/Common/[apname]_act_ondemand_cert_auth_ag', return value 0 Following rule 'Successful' from item 'On-Demand Cert Auth' to item 'Assign Logon Variable for Logs' Username 'XXXX' Username 'xxxx' Executed agent '/Common/[apname]_act_variable_assign_ag', return value 0 Following rule 'fallback' from item 'Assign Logon Variable for Logs' to item 'Full VPN Access' Connectivity resource '/Common/[networkaccess]' assigned

*********** non working example ***********

Session variable 'session.clientcert.ssl_rehandshake_pending' set to '2' Session variable 'session.server.landinguri' set to '/' Session variable 'session.ssl.cert.exist' set to '0' Session variable 'session.ssl.cert.valid' set to '1' Session variable 'session.ui.mode' set to '7' Executed agent '/Common/[apname]_act_ondemand_cert_auth_ag', return value 0 Following rule 'fallback' from item 'On-Demand Cert Auth' to item 'Logon Page'

In the visual policy configuration, effectively the following happens:

On-Demand Cert Auth check is performed, this check is as follows:

Auth Mode is set to "Request" <-- so this seems to conflict with the AP profile setting. The branch rule has an expressions being "expr { [mcget {session.ssl.cert.valid}] == "0" }" If successful is moves to the assign logon variable for logs......and provides access to the VPN connection.

If not successful it moves to the fallback path where the Logon page is presented.

The logs above seem to indicate that while the same validation is being done and the same the end result is different.

So it appears that the On-Demand Cert Auth agent is failing. Let's try a few things:

1. After the successful and fallback branches of the On-Demand Cert Auth agent, add some message boxes. After successful:

   "Success: %{session.ssl.cert.subject}"
   

   After Fallback:

   "Fallback: %{session.ssl.cert.subject}"
   

   If you see the certificate subject in the fallback branch message, then you know the client sent a cert, and that the SSL handshake succeeded.

2. You have "Request" set in the access policy On-Demand Cert Auth agent and the in the client SSL profile? If so, don't do that. The client SSL profile should be set to Ignore.

On my loan device (which now no longer breaks!!!), I will get the certificate subject for the user account (FQDN, i.e. user, usergroups, domain). I noticed that if I set the CRL (as was being done on the 11.3 instance), this would cause a failure. The same certificate subject is returned.

I will get the certificate subject for the user account (FQDN, i.e. user, usergroups, domain).

You're talking about in the message box, yes? This should be the subject value directly from the user's certificate.

I noticed that if I set the CRL (as was being done on the 11.3 instance), this would cause a failure.

It would probably be most helpful while troubleshooting to leave the CRL disabled.

The same certificate subject is returned

Let's focus on the broken platform. No CRL set, APM On-Demand Cert Auth agent set to request with message boxes following each branch, and the client SSL profile set to Ignore. So in this statement are you saying that you see the certificate subject in the fallback branch?

yes

Actually I got an alternate user to try and login via a Windows 8 machine.

On my session I have the following certificates expiring

"USERID" Expires 18/10/2016; 2/08/2016; 13/10/2016; 01/09/2016

"USERID2"

Expires 12/10/2016; 11/06/2016; 14/10/2016

With the loan device, USERID (me) works fine. I noticed that my certificate subject says "user_fqdn". This is without the CRL enabled.

With the load device, USERID2 breaks. I noticed that it does fail and there is no certificate subject. Hence this process goes to the fallback path and goes to the logon page option.