Forum Discussion
Problem inserting SSL client certificate subject into a header of an HTTP session
Hello DevCentral Community,
I have run into a problem in a v4.x to v9.x migration where I we are trying to insert an X509 client cert subject as an http header to the backend using the following iRule. After performing some testing we have identified several cases where we are passing requests to the backend servers with a blank subject header value. We suspect that a client is attempting resume SSL connections after the 1200 sec timeout period (hence the SSL::renegotiate command) and causing the session lookup to fail.
We did make some assumptions when writing this iRule that I would confirm with the community.
Assumption 1 - Once we execute the SSL::renegotiate command we will re-execute the logic contained in the CLIENTSSL_CLIENTCERT and HTTP_REQUEST events with the new SSL session ID.
Assumption 2 – Re-adding the SSL subject into the session table will reset the timeout counter.
rule ssl-sub-insert-v4 {
when CLIENTSSL_CLIENTCERT {
set ssl_cert [SSL::cert 0]
set subject [X509::subject $ssl_cert]
session add ssl [SSL::sessionid] $subject 1200
}
when HTTP_REQUEST {
set ssl_subject [session lookup ssl [SSL::sessionid]]
if { $ssl_subject equals "" } {
SSL::renegotiate
} else {
HTTP::header insert SSLClientCertSubject $ssl_subject
session add ssl [SSL::sessionid] $ssl_subject 1200
}
}
Any thoughts or words of wisdom would be greatly appreciated.
Thanks,
Brian
3 Replies
- I can't help too much with your problem, except to say that calling SSL::rengotiate will not (or at least definitely should not) make the HTTP_REQUEST event fire again. In general, one layer should not affect another. Just like a TCP retransmission should not make HTTP_REQUEST fire again, so too should an SSL renegotiation not make it fire again.
If you need to do something in the HTTP layer that depends on SSL renegotiation that itself depends on something in the HTTP layer (for example, checking the requested URI to determine if an SSL cert is required, and then renegotating for one, and then inserting an HTTP header based on that cert), then you may need to investigate the HTTP_REQUEST_SEND event. - Thanks for your reply. We have added logic in the rule to account for not re-executing the HTTP_REQUEST event. However, in this version we are still assuming that issuing the SSL::renegotiate command will retrigger the CLIENTSSL_CLIENTCERT event. According to our testing so far we seen that the CLIENTSSL_CLIENTCERT will not retrigger. If we cannot re-execute the event, do you have any thoughts on how to re-add the subject into the session table within the HTTP_REQUEST event?
Also, I would still like to know if re-adding the SSL subject into the session table will reset the timeout counter (assumption 2 from original post)?
when CLIENTSSL_CLIENTCERT {
set ssl_cert [SSL::cert 0]
set subject [X509::subject $ssl_cert]
session add ssl [SSL::sessionid] $subject 1200
}
when HTTP_REQUEST {
set ssl_subject [session lookup ssl [SSL::sessionid]]
if {$ssl_subject equals ""} {
SSL::renegotiate
set ssl_subject [session lookup ssl [SSL::sessionid]]
}
session add ssl [SSL::sessionid] $ssl_subject 1200
}
when HTTP_REQUEST_SEND {
clientside {
HTTP::header insert SSLClientCertSubject $ssl_subject
}
} 
dimka___104021Nimbostratus
Hi,
I have also struggled with ssl::renegotiation, but none of solutions offered by support worked.
Finaly last letter from support was "This really falls outside the realm of technical support".
May be someone here can clarify about ssl::renegotiation & client cert.
tia,
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}