Forum Discussion
Kevin_Stewart
Employee
EmployeeOCSP and new AUTH::status response codes
All,
According to the wiki, the AUTH_ERROR, AUTH_FAILURE and AUTH_SUCCESS events are being deprecated in favor of the new AUTH_RESULT event, and is evident in the default ocsp irules in the 9.2* and above releases. Also, according to the wiki, you should be able to determine the specific results of the AUTH_RESULT event by looking at the AUTH::status return code, where:
0 = success
1 = failure
-1 = error
2 = not authed
Using the original AUTH events on a 9.1.* box, I am able to capture incidences of each, given bad cert, error in processing cert, and good cert check. Using the new event on a 9.2.* box, I am only able to capture a success or failure (0 or 1). I have not been able to simulate the other 2 response codes. I'm less concerned with the not_authed status, but I would like to capture the error event.
My question then is what would cause an AUTH::status of -1 or 2?
Thank you.
Kevin
- Kevin_StewartAll,
If I may add more...
I tried both the old and the new ocsp code base on a 9.4.* box and found something I didn't expect.
To begin though, the whole purpose of this is to generate meaning from certificate processing errors so that our help desk can better serve the customers. This relates back to "OCSP Authentication error redirect" iRule at http://devcentral.f5.com/Default.aspx?tabid=108. This iRule worked well in 9.1.* systems. I was able to trap Good, Revoked, Expired, and Error returns.
Now back to the story. I set debug statements in each of my events (CLIENT_ACCEPTED, CLIENTSSL_CLIENTCERT, HTTP_REQUEST, and in each of the AUTH events.) On a 9.4.* system, a revoked cert triggers the AUTH_FAILURE event in the old code and AUTH::status of 1 in the new code. Likewise, a good cert triggers the AUTH_SUCCESS event in the old code and AUTH::status of 0 in the new code. Here's where it gets weird though. An expired certificate, in both versions of the code, stops at the CLIENTSSL_CLIENTCERT event, with no other events triggered (except CLIENT_CLOSED of course). Reasonably it never triggers an AUTH event. But on a 9.1.* system it does.
The bottom line is this. Previously I was able to capture the occurrence of an expired certificate and generate an HTTP::respond with some HTML to the user. This meant that an expired certificate still triggered an AUTH event, and subsequently (using SSL::handshake hold and SSL::handshake resume) an HTTP_REQUEST event that I could use for the respond content. On a 9.4.* system, and I presume 9.2.*, an if { $::DEBUG } { log local0. "PXDEBUG: tmm_auth_status = 0: success" }
expired cert stops at the CLIENTSSL_CLIENTCERT event, and then completely closes the connection. I am then limited to displaying only a revoked certificate status to the client.
In all reality, it isn't as big a deal for the help desk to verify the expiration of the certificate as it is validating the its revocation status, but it would be nice to have both, and I have to assume this is by design. In the standard ocsp rule that ships with the system, connections are rejected if ocsp verification fails. That is, the rule has the responsibility (and flexibility) to reject the connection.
Apologies for rambling so long. And any ideas will be appreciated.
Thank you.
Kevin Stewart 
dimka___104021Nimbostratus
Hi,
I'm dealing with same problem.
Is there any solutions, workarounds or HF, which may solve this issue?
tia,- Kevin_StewartHey dimka,
As you can tell, no one has responded to this question. As far as I know there is no solution. When I client presents an expired certificate, all processing stops at the clientcert_clientssl event and the user gets an uninformative white screen.
Kevin - Do you have your client certificate "peer cert mode" set to "request" or "require"? If it's set to "require", then the certificate presented must pass all of the internal checks that the BIG-IP does before we continue with the connection, so that may be the behavior that you're (all) seeing. You should be able to set it to "request" and have processing continue. Note that you will need to ensure that your auth processing iRule handles the case where the client does not present any certificate at all.
If you have it set to "request", and you're still seeing clients with expired certificates having their connections be closed (and the iRule events not firing), then that is a bug, and you should open up a case with F5 support.
Hope this helps!
