Forum Discussion
Verify Valid Client Certificate
Have a current 4.x config as follows:
proxy 10.10.10.6:443 unit 1 {
target virtual 127.0.201.6:80
clientssl enable
clientssl key test.key
clientssl cert test.crt
clientssl ca file roots.crt
clientssl client cert ca roots.crt
clientssl client cert insert validity
clientssl client cert request
redirects rewrite matching
ocsp responders test_eva
}
Pretty simple..just adding checkbox header for "validity"
Then the rule block client without a valid certificate..
rule test_rule {
if (http_header("SSLClientCertStatus") == "OK") {
use pool test_pool
}
else {
redirect to "http://www.error.com/nocert.html"
}
}
My first issue is even getting a valid "value" from the header I'm inserting for example I've tried in my http profile:
SSLClientCertStatus: [X509::verify_cert_error_string [SSL::verify_result]]
SSLClientCertStatus: [SSL::verify_result]
In either case my value does not change whether a provide a valid cert or if we cancel the client cert dialog box from the browser.
I'm also tried using the HTTP::header insert_modssl_fields with a rule and I can't even get the syntax correct. I've tried numerous variations and can't get it right. Even when I have a normal HTTP::header insert working I can't work w/ what I would assume is the same syntax to get this working. I also have the modssl enable in my clientssl profile as the manual indicates.
Once I get the value of the header to change for the client presenting a valid cert I think my rules might work...
Please help.
- Also, wanted to mention that with 9.x this config containing over 200 rules (1 for each proxy) can now be condensed by using this 1 rule!!
- Good to hear... I thought it may be necessary to do some more trickery. I'm getting the rest of the rule posted in the code share section as soon as it is approved.
You'll see all the crazy tricks when that comes out. - I thought I would just add another rule I obtained from the ENEs. This rule did not work in my customer's environment (they're using the previous rule in this post) but thought I would include it here. It would be nice to know which rule is more efficient/secure/etc. Basically what are the pros/cons of each.
custom auth rule. tracks the OCSP responder's result in the SSL session table. rule oscp_authonly_gomes { when CLIENT_ACCEPTED { set tmm_auth_ssl_ocsp_sid [AUTH::start pam default_ssl_ocsp] } when CLIENTSSL_CLIENTCERT { AUTH::cert_credential $tmm_auth_ssl_ocsp_sid [SSL::cert 0] AUTH::cert_issuer_credential $tmm_auth_ssl_ocsp_sid [SSL::cert issuer 0] AUTH::authenticate $tmm_auth_ssl_ocsp_sid SSL::handshake hold set id [SSL::sessionid] } when AUTH_SUCCESS { if {$tmm_auth_ssl_ocsp_sid eq [AUTH::last_event_session_id]} { SSL::handshake resume set Z "success" session add ssl $id $Z } } when AUTH_FAILURE { if {$tmm_auth_ssl_ocsp_sid eq [AUTH::last_event_session_id]} { SSL::handshake resume set Z "redirect" session add ssl $id $Z } } when AUTH_WANTCREDENTIAL { if {$tmm_auth_ssl_ocsp_sid eq [AUTH::last_event_session_id]} { reject } } when AUTH_ERROR { if {$tmm_auth_ssl_ocsp_sid eq [AUTH::last_event_session_id]} { SSL::handshake resume set Z "redirect" session add ssl $id $Z } } }http rule that checks the ssl session table for the OCSP responder's result rule ocsp_http { when HTTP_REQUEST { set id [SSL::sessionid] set y [session lookup ssl $id] log local0. "y is: $y" if { $y contains "redirect" }{ HTTP::redirect "http://192.168.104.25/certerror.html" } } } - Do you happen to know off hand how the customer tested their rule? In my tests, SSL::verify_result is never updated to include the OCSP responder’s response, so any cert that chains up to a trusted client cert CA comes back with a result of “ok”, even if it has been revoked by the OCSP responder. The only way to capture the OCSP responder’s response and use it to make a load balancing decision in HTTP_REQUEST seems to be to use the modified auth rule to store a flag that lets us know whether AUTH_SUCCESS or AUTH_FAILURE happened.
