APM portal mode and On Demand Certificate Authentication

There shouldn't normally be a difference between the processes. Are you applying certificate authentication and LDAP before assigning the portal resource? How do you have it all configured?

I am doing certificate authentication before assigning portal resources. It doesn't pass On demand certitificate authentication so I don't get to OCSP or LDAP, SSL session brakes. LTM says something like:

Apr 29 09:43:46 bigipteste info tmm1[8674]: 01260013:6: SSL Handshake failed for TCP from 10.10.10.100:49322 to 10.10.10.10:443Apr 29 09:43:58 bigipteste debug tmm[8674]: 01260006:7: Peer cert verify error: unable to get local issuer certificate (depth 0; cert /DC=ro/DC=test/CN=Users/CN=test 01)Apr 29 09:43:58 bigipteste debug tmm[8674]: 01260009:7: Connection error: ssl_shim_vfycerterr:2912: unable to get local issuer certificate (42)Apr 29 09:43:58 bigipteste info tmm[8674]: 01260013:6: SSL Handshake failed for TCP from 10.10.10.100:49323 to 10.10.10.10:443

while APM says:

Apr 29 09:43:46 bigipteste info apd[5814]: 01490006:6: 0d2c7fe9: Following rule 'fallback' from item 'Logon Page' to item 'On-Demand Cert Auth'Apr 29 09:43:46 bigipteste info apd[5814]: 01490004:6: 0d2c7fe9: Executed agent '/Common/Portal_act_ondemand_cert_auth_ag', return value 3Apr 29 09:43:46 bigipteste debug apd[5814]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "_executeOneAgent()" line: 108 Msg: user input is requiredApr 29 09:43:46 bigipteste info apd[5814]: 01490007:6: 0d2c7fe9: Session variable 'session.ssl.cert.valid' set to '1'Apr 29 09:43:46 bigipteste debug apd[5814]: 01490000:7: ./AccessPolicyProcessor/Session.h func: "setSessionInactive()" line: 887 Msg: 0d2c7fe9: done with request processingApr 29 09:43:46 bigipteste debug apd[5814]: 01490000:7: AccessPolicyD.cpp func: "sendAccessPolicyResponse()" line: 1532 Msg: send 'redirect to EUIE' code, redirect URL="/agent_aaa_clientcert_form.cca"

I've tried the same debugging with policy for LTM VS and I can see the entire SSL certificate parameters and on demand authentication succesfull. I'm using the same client SSL profiles for both access policies, chain trust certificate is installed and set on client authentication section. Difference between them is just the type of access policy.

Just spitballing here, but what F5 version and do you also have the client SSL profile set to request/require client certificate?

I'm using 11.4.1, in client ssl profile on client authentication I use ignore since On Demand Certificate Authentication is used in access policy. Configuration manual for APM indicates to set it on ignore for On Demand to work and it does work but not in portal access. I've tried with request, haven't tried with require, I can do that but that is not the behavior I am expecting. I would like for client to be able to see the logon page and only after he hits login the APM should ask for client certificate and to do SSL renegotiation and after that to pass the certificate details forward in the policy. If set to request or required the client certificate is asked as soon as the clients hits the logon page.

There is something different between the two modes because in portal access the session is maintained by the APM, I have session ID, I can do logout, etc, while just authenticating for LTM as soon as that is done session ID is no longer available, I cannot clear that session, traffic is offloaded to LTM. There must be something different on how APM handles the SSL renegotiation in portal access mode or full portal access.

I'm using on demand certificate authention for Network Access (SSL profile set to ignore) and had some early 'teething' troubles with it and someone recommended ensuring that the On Demand Cert Auth is before any Logon Page/AD Auth.

Moving On Demand Cert Auth entry in the graphical policy to before the Logon Page fixed my issues!

If we step back a little, could you please clarify your definitions of full portal and portal access? Would you consider full portal where you create portal resources and add those and a webtop to a resource assignment? Would you consider portal access where you define the portal resource in the webtop itself and just apply that to the resource assignment?

May  5 06:02:01 bigipteste info apd[30089]: 01490007:6: 4cd4576e: Session variable 'session.ssl.cert.end' set to 'May 23 08:53:21 2014 GMT'
May  5 06:02:01 bigipteste info apd[30089]: 01490007:6: 4cd4576e: Session variable 'session.ssl.cert.exist' set to '1'
May  5 06:02:01 bigipteste info apd[30089]: 01490007:6: 4cd4576e: Session variable 'session.ssl.cert.issuer' set to 'C=**,O=****,OU=****,CN=*****'
May  5 06:02:01 bigipteste info apd[30089]: 01490007:6: 4cd4576e: Session variable 'session.ssl.cert.serial' set to '123123123123123123'
May  5 06:02:01 bigipteste info apd[30089]: 01490007:6: 4cd4576e: Session variable 'session.ssl.cert.start' set to 'May 23 08:53:21 2013 GMT'
May  5 06:02:01 bigipteste info apd[30089]: 01490007:6: 4cd4576e: Session variable 'session.ssl.cert.subject' set to 'CN=*****,serialNumber=232323,O=****,L=*****,C=****'
May  5 06:02:01 bigipteste info apd[30089]: 01490007:6: 4cd4576e: Session variable 'session.ssl.cert.valid' set to '27'

It seems that the certificate is there but on demand doesn't set valid to 0. I don't have any errors on the certificate validation, it does have a proper trust certificate chain. I will try this on 11.5 and if it doesn't work I will end up opening a support case.

I ran into this problem too.

To make 'session.ssl.cert.valid" = 0 and not 27 I had to set the client SSL profile to "ignore" (which it already was) but then also configure the CA Cert/Bundle as a Trusted Certificate Authority.

Once I did that then 'session.ssl.cert.valid' value was "0"

For more security I also changed the On-Demand Cert auth successful expression to..

expr { [mcget {session.ssl.cert.valid}] == "0" && [mcget {session.ssl.cert.serial}] == "

That makes total sense Kris. Any time that you receive a client certificate, either via the client SSL profile or APM's On-Demand Cert Auth agent, you MUST provide a trusted certificate authorities cert/bundle. If you think about it, when the server sends its certificate to the client as part of the SSL handshake, the browser's CA trust list is used to validate that server certificate. If the cert subject name doesn't match the server name in the URL, the cert is expired, or the browser can't establish a trust path with any of the CA certs in its list, the user will get a certificate error. The same applies for the other end. When the client sends its certificate to the server, the server (BIG-IP) must validate it against an explicit CA trust chain - the CA bundle. Except in this case, if no trust path can be created, the SSL handshake fails. This is also a difference between Request and Require. With Request, validation can fail and the connection will continue. With Require, if the validation fails the connection is ended.