Forum Discussion
Scot_86001
Nimbostratus
NimbostratusiRule Optimization w/ Certificates?
The iRule below functions and performs as it should. I have been told that what I have below may not be efficient or optimized. I am looking to see if anyone can make some suggestions on how to better optimize. I would also like to know if session persistence and timeout are being maintained as they should. This iRule performs client side cert authentication only when a certain URI is sent. Upon successfull login, header information from the cert is passed to the receiving application. The code below was pieced together from other iRules on DevCentral.
when CLIENTSSL_CLIENTCERT {
set cert [SSL::cert 0]
HTTP::release
if { [SSL::cert count] < 1 } {
reject
}
}
when HTTP_REQUEST {
set v1 [URI::query [HTTP::uri] "p"]
if { ($v1 contains "ESAT") || ($v1 contains "311") } then {
if { [SSL::cert count] <= 0 } {
HTTP::collect
SSL::session invalidate
SSL::authenticate always
SSL::authenticate depth 9
SSL::cert mode request
SSL::renegotiate
}
}
}
when HTTP_REQUEST_SEND {
clientside {
if { [SSL::cert count] > 0 } {
HTTP::header insert "X-SSL-Session-ID"[SSL::sessionid]
HTTP::header insert "X-SSL-Client-Cert-Status"[X509::verify_cert_error_string [SSL::verify_result]]
HTTP::header insert "SSL_CLIENT_S_DN"[X509::subject [SSL::cert 0]]
HTTP::header insert "SSL_CLIENT_I_DN"[X509::issuer [SSL::cert 0]]
}
}
}
21 Replies
Scot_86001Aaron,
In our environment, we deal w/ 2 sets of certificates. DoD CAC and Verisign ECA. As a result, I have 2 responders.
I dont understand what you mean by "command line request from LTM direct to the server to see if the TCP connection works and if so whether you get an HTTP response". I can telnet over port 80 to the host address from an LTM ssh session. But that is just telling me that there is a path. I am not seeing any traffic using TCPDUMP for that host. Its very frustrating!- Scot_86001Aaron,
My testing seems to show that the Verisign responder only works if it is the only responder in the configuration. The DoD responder seems to work regardless of whether one or both are added to the configuration. What I am finding is that the Verisign responder does not work when the DoD responder is in the configuration. Any idea why this might be? http://eca-client-ocsp.verisign.com
Any idea on maybe how to work around this? - hoolio
Cirrostratus
There are a few options, but I'm not sure which is best. Let me do some preliminary testing and get back to you.
Aaron - Scot_86001Aaron,
I dont know if this helps but the ECA OCSP responder has the following attributes:
Verisign
URL of OCSP Service http://eca-client-ocsp.verisign.com
Port for OCSP Service- 80
Model of Operation- Delegated Trust
Supported CAs- Verisign Client External Certification Authority, original and version G2
Would being a Delegated trust have anything to do with these type issues? - Scot_86001Aaron,
I have added in more debug (add in AUTH::subscribe along with AUTH::response_data). The following is now being displayed for the ECA Responder:
Feb 24 15:04:54 tmm tmm[1710]: Rule client_cert_request_by_uri_with_ocsp_checking : client IP:port=192.168.1.152:2671; VIP=test_vs: [AUTH::response_data]: ocsp:response:status unknown;
AUTH::status = 1;l - Scot_86001Aaron,
I think we has an issue/bug. It appears as though the second responder is not being checked (based on status returned). What is happening is that the ECA cert is being tried on the DoD responder (apparently the responders are choosen in alpha order). It is making a successful connection but returned an error of unknown certificate. As a result, ECA responder is not being tried.
Is there a way for me to test the cert being presented and then denote which responder to send it too?
Is there a way, if a status of unknown is returned, to initiate the second responder? somehow change the status as if the first was not reachable?
It appears to me as though the multiple responder concept is for multiple IP's of the same type cert.
You seem to be the top resource for this type of stuff. Any ideas? - Scot_86001Aaron,
Last post for the evening. When the first responder cannot be reached, the second responder is not tried.
Feb 24 23:00:18 tmm tmm[1710]: Rule client_cert_request_by_uri_with_ocsp_checking : client IP:port=192.168.1.154:56480; VIP=test_vs: [AUTH::response_data]: ocsp:response:status {Error (Could not connect to server)} ocsp:response:status unauthorized;
Is there a way to have the iRule always check the second responder unless the first returns a 0 or success. - hoolioI'd guess that the DoD client certs need to be checked against the OCSP server and the Verisign client certs need to be checked against the Verisign OCSP server. There are two options I can think of for handling this:
1. On the OCSP servers VIP, add an iRule which checks the request and selects the OCSP pool member based on the request. I think this is probably the simplest and most efficient option. But I'd need to set this up and test to see how easily it would be to determine which CA's client cert is being checked based on the OCSP request.
You can check RFC2560 sections 2.1 and 4.1.1 and/or capture tcpdumps of the OCSP requests to see what in the requests could be used to differentiate the DoD and Verisign requests.
http://tools.ietf.org/html/rfc2560
2. Configure two separate auth profiles--one for each OCSP responder. As you don't know which client cert the client will present until the SSL handshake is done, I think you'd need to use three iRules for this: one to handle the cert requesting and then another each to handle the auth depending on which client cert is provided. I think this would be complicated with three rules.
3. On the OCSP servers VIP, add an iRule which tries each OCSP server until a successful response is received or there are no more OCSP servers to make the request to. Doing this would be inefficient as you'd potentially be making two side band requests to a remote server for each authentication attempt.
Note, the default action for load balancing (if you're testing with the OCSP servers VIP and pool) is to select one pool member for each connection. By default LTM doesn't try multiple pool members for one client request. Or are you testing with multiple responders configured and not a single VIP pointing to the responders? If so, LTM will use the responders in alphabetical order. This is described in SOL7746. I'm not sure what criteria LTM uses to determine when to check another responder. It might just be if a TCP connection can't be established to the prior responder.
SOL7746: Ordering Online Certificate Status Protocol (OCSP) responders in the SSL OCSP profile
https://support.f5.com/kb/en-us/solutions/public/7000/700/sol7746.html
I am a bit swamped this week, so I don't think I'm going to have time to test this. I can try later next week though. Else, if you try any of these options and run into issues, let me know.
Thanks,
Aaron - Scot_86001Aaron, you are correct. When a DoD cert is presented, I want to use the DoD Reponder. When a Verisign ECA is presented, I want to use the ECA responder.
I am using one VIP (one virtual server) with multiple responders in an OCSP configuration. Just like your test scenario.
Option 1 is what I am trying to figure out but am getting no where. I do believe we have the knowledge on this end to figure out which cert is incoming. I would just need to know how to control which responder is called. It sounds to me like we are now breaking the responders out into there own configs and calling them from a different place. if you can place some breadcrumbs, I might be able to follow. - Scot_86001Aaron,
Is there a way to get/contract you as a resource to work through and resolve this issue.
