OCSP and new AUTH::status response codes

All,

 

 

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