Forum Discussion
0_11329
Nimbostratus
NimbostratusValid certificate is identified as revoked by "OCSP Authentication error redirect" IRule
Hi,
As part of the implementation of a PKI, I try to use the "OCSP Authentication error redirect" IRule in a BigIP 1500 LTM (version 9.3.1) intended to redirect the Client browser toward a specific web page in the case where the authentication failed (no Client certificate, expired certificates, revoked certificate, others)
I have installed the relevant CA in the BigIP.
And...
We meet an authentication problem that we do not explain : a valid certificate is identified by the IRule as revoked, what does not seem correspond to a normal functioning, according to me.
However, the "OCSP Authentication error redirect" IRule is classified as ***** 2nd Place Customer Winner ***** !!! So I tell myself that the rule must work properly...
Missed something ?
Will apreaciate your point of you & experiences ;7) Thanks a lot in advance.
"OCSP Authentication error redirect" IRule
-----------------------------------------------------------------------------------
SSL::handshake resume
lset ssl_array 1 "auth_failure"
session add ssl $id $ssl_array 21600
}
}
when AUTH_WANTCREDENTIAL {
if {$tmm_auth_ssl_ocsp_sid eq [AUTH::last_event_session_id]} {
reject
log "[IP::client_addr] WANTCREDENTIAL"
}
}
when AUTH_ERROR {
if {$tmm_auth_ssl_ocsp_sid eq [AUTH::last_event_session_id]} {
lset ssl_array 1 "auth_failure"
session add ssl $id $ssl_array 21600
log "[IP::client_addr] AUTHERROR"
}
}
when HTTP_REQUEST {
set id [SSL::sessionid]
set ssl_array1 [session lookup ssl $id]
set ssl_data0 [lindex $ssl_array1 0]
set ssl_data1 [lindex $ssl_array1 1]
if { $ssl_data0 contains "expired" } {
set fail_payload_part1 ""
set fail_payload_part2 "You appear to have a certificate that has expired."
set fail_payload_part3 "If you feel you have received this message in error,"
set fail_payload_part4 "please contact the appropriate help center"
set fail_payload [concat $fail_payload_part1 $fail_payload_part2 $fail_payload_part3 $fail_payload_part4]
HTTP::respond 200 content $fail_payload
} elseif { $ssl_data1 contains "auth_failure" } {
set fail_payload_part1 ""
set fail_payload_part2 "You appear to have a certificate that has been revoked."
set fail_payload_part3 "If you feel you have received this message in error,"
set fail_payload_part4 "please contact the appropriate help center"
set fail_payload [concat $fail_payload_part1 $fail_payload_part2 $fail_payload_part3 $fail_payload_part4]
HTTP::respond 200 content $fail_payload
} elseif { $ssl_data0 contains "ok" } {
HTTP::header insert SSLCLientCertStatus $ssl_data1
} else {
set fail_payload_part1 ""
set fail_payload_part2 "It appears that you either do not have a valid DoD PKI certificate installed"
set fail_payload_part3 "and functioning in your browser or your session has timed-out. If you feel you have received"
set fail_payload_part4 "this message in error, please try connecting again or contact the appropriate help center"
set fail_payload [concat $fail_payload_part1 $fail_payload_part2 $fail_payload_part3 $fail_payload_part4]
HTTP::respond 200 content $fail_payload
}
}
-----------------------------------------------------------------------------------
Justin_18188I have used this iRule successfully. I'm not sure I understand your question but do all certificates get rejected or just some?
I'm actually looking for an iRule that is a little more custom. Even a redirect on OCSP verification failure to a page we built would be cool. Anyone have anything to suggest?
hoolioCirrostratus
There is a bug where AUTH::status returns the same status code (1) for an unreachable OCSP server as a revoked cert. It's possible this was the cause of the reported symptoms.
This is noted in CR126501:
CR126501 - enhancement to log server connect failure separately from cert revoked.
And a related CR:
CR126517 - enhance OCSP to log the information without iRule.
F5 Support suggested the following workaround:Instead of pointing the OCSP responder object directly at the responder, I point it to another VIP (thanks to v9.4.7 I believe - we used to have to point to another BigIP). That VIP pools to the real responder, but also has access to intelligent load balancing, monitors, iRules, etc. This is still very basic, but in that iRule I do this: ================= when RULE_INIT { set :CSP_AVAIL 1 } when HTTP_REQUEST { if { [active_members ocsp_pool] < 1 } { set :CSP_AVAIL 0 } else { set :CSP_AVAIL 1 } } ================ So I’m setting a global variable that other iRules can see: ================ when AUTH_RESULT { if { $:CSP_AVAIL == 1 } { ... } else { log local0. "OCSP Offline" } } ================ You could perform your normal logic in your AUTH_RESULT event handler inside the code block for the "$:CSP_AVAIL==1" condition, and do whatever is needful in the else clause to note the absence of available OCSP responders.
Aaron- Kevin_Stewart
Employee
You don't have to create the global variable.
So you still create an OCSP responder VIP with pool and associated health monitors. Simply query the active_members count from anywhere else and take action accordingly if it's less than 1...
Kevin - hoolioThat makes sense. Thanks for the tip. I guess you could even forget the VIP and just check the pool state from the OCSP iRule. You'd need to configure the OCSP responders as usual instead of using an OCSP virtual server.
Aaron 
Randy_AbramsIn reference to:
"Instead of pointing the OCSP responder object directly at the responder, I point it to another VIP (thanks to v9.4.7 ..."
Exactly how is this done? I can't seem to find any documentation.- hoolioHi Randy,
It would be easier to configure the OCSP server(s) in a pool and then add logic to your OCSP auth iRule which checks [active_members $ocsp_server_pool] > 1 before trying the OCSP authentication. You could send an HTTP response or TCP reset back to the client if the pool was down.
If you do want to create a VIP, you could do it on a free loopback IP address like 127.0.0.100 and then configure this internal VIP address as the OCSP responder address.
Aaron - Randy_AbramsAaron,
When defining a VIP (LTM 9.4.7) on a loopback address, the following message is returned:
BIGpipe virtual server operation error:
01020061:3: IP Address 127.0.0.100 is invalid, loopback not allowed.
Is defining a VIP on a loopback address a common technique? Do special options need to be set?
Thanks,
Randy - hoolioSorry, not loopback--I just picked a random range that wouldn't be routable on the customer's network, like 2.2.2.1/24.
Aaron
