Forum Discussion
Jason_Jernigan_
Nimbostratus
NimbostratusClient SSL Insert
I've got a site using client SSL cert inserted to the header for authentication with the backend web server. The irule is as follows.
when CLIENTSSL_CLIENTCERT {
if { [SSL::cert count] > 0 } {
session add ssl [SSL::sessionid] [X509::cert_fields [SSL::cert 0] [SSL::verify_result] whole] 450
}
}
when HTTP_REQUEST {
set certfields [session lookup ssl [SSL::sessionid]]
if { $certfields != "" } {
HTTP::header insert $certfields
}
}
This is followed by another irule that chooses which pool based on active members. This inserting of the header works fine when the pool that is choosen in the next irule is the same as the default pool that is listed for the virtual server. However if it chooses another pool then the session lookup fails? Any help would be greatly appreciated.
Thanks,
Jason
Jason_Jernigan_I added some logging to figure out what was going on. Below is the irule with the logging enabled.
when CLIENTSSL_CLIENTCERT {
log "begining"
log "ssl cert count = + [SSL::cert count]"
if { [SSL::cert count] > 0 } {
session add ssl [SSL::sessionid] [X509::cert_fields [SSL::cert 0] [SSL::verify_result] whole] 450
log "session ID: + [SSL::sessionid] + [X509::cert_fields [SSL::cert 0] [SSL::verify_result] whole]"
log "certfields lookup = [session lookup ssl [SSL::sessionid]]"
}
}
when HTTP_REQUEST {
log "http_request sessionid= + [SSL::sessionid]"
set certfields [session lookup ssl [SSL::sessionid]]
log "certfields before if + $certfields"
if { $certfields != "" } {
HTTP::header insert $certfields
}
log "Ending"
}
Attached are the logs that this irule produced. The section of logs labeled incorrect is when the default pool was not the same pool that the next irule chose. You can see by looking at the logs that the session lookup command fails under the HTTP_REQUEST section but works fine in the CLIENTSSL_CLIENTCERT section.- This may sound a little bizzare, and will eventually be fixed in a future release. The session table actually utilizes the persistence table and as a result, some of the behaviors of the persist table have made there way into how the session table behaves. The issue that is getting you here is what's known as "persist across ...". Since the pool is different, persistence would normally not use the entry unless persist across services or persist across pools is enabled. Obviously, this really isn't appropriate behavior for the session table.
However, you should be able to easily work around it by changing your session lookup like so:set certfields [session lookup ssl {[SSL::sessionid] any}]
Please let us know if this corrects your problem so we can get it fixed in a future release.
Thanks! - Jason_Jernigan_Ok I changed the code to this:
when CLIENTSSL_CLIENTCERT {
log "begining"
log "ssl cert count = + [SSL::cert count]"
if { [SSL::cert count] > 0 } {
session add ssl [SSL::sessionid] [X509::cert_fields [SSL::cert 0] [SSL::verify_result] whole] 450
log "session ID: + [SSL::sessionid] + [X509::cert_fields [SSL::cert 0] [SSL::verify_result] whole]"
log "certfields lookup = [session lookup ssl {[SSL::sessionid] any}]"
}
}
when HTTP_REQUEST {
log "http_request sessionid= + [SSL::sessionid]"
set certfields [session lookup ssl {[SSL::sessionid] any}]
log "certfields before if + $certfields"
if { $certfields != "" } {
HTTP::header insert $certfields
}
log "Ending"
}
But it appears that something is off becuase now none of the lookups are working. Including the log statement immediatly following the session add. Your help is greatly appreciated. Please see logs attached.
Thanks,
Jason - Ok, I'll need to try to reproduce this. What version + hotfixes are you running?
- Jason_Jernigan_We are running version 9.1 with no hotfixes.
b version
Kernel:
Linux 2.4.21-9.1.0.3.0smp
Package:
BIG-IP Version 9.1.0 6.2
Final Edition
Thanks,
Jason - The session cmd is broken in 9.1 & 9.1.1 (CR56247). You should call support and get the latest hotfix that is available for 9.1.1 which includes the fix for this.
- Jason_Jernigan_We installed 9.1.1 along with a hotfix. Our current build information is as follows.
cat /VERSION
Product: BIG-IP
Version: 9.1.1
Build: 54.6
Edition: Final
Built: 051121210929
We are still seeing the same problem were the session lookup command is failing. Below is the logging information from a test run. If you can tell me exactly which hotfix is needed that would help becuase support orginally told me there were no hotfixes for 9.1.1 untill this i-rule caused the LTM to reboot then they gave me a hotfix but I'm not sure it is the right one. Any help is greatly appreciated.
Thanks,
Jason Jernigan
Mar 16 14:30:32 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : begining
Mar 16 14:30:32 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : ssl cert count = + 1
Mar 16 14:30:32 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : session ID: + 99f96f36f6ef44a096e8bc06
af9a9ea75846f1c703d755323d428e38b67184ee + SSLClientCertStatus OK SSLClientCert {-----BEGIN CERTIFICATE----- MIIEFzCCAv+gAwIBAgIKEbk
KYAAAAAAT0zANBgkqhkiG9w0BAQUFADAWMRQwEgYD VQQDEwtWZXJpZEJldGFDQTAeFw0wNjAzMDIxNTQxNTlaFw0wNzAzMDIxNTUxNTla MD0xFzAVBgNVBAMTDmpqZXJua
Wdhbi1iZXRhMSIwIAYJKoZIhvcNAQkBFhNqamVy bmlnYW5AdmVyaWQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0Ilpg G3WFpknKR9a5MqUlY8SsylHBzyH
ImB9if/uPGqS26R+kbaRCnkfExygFLVsizJAi VOUg3MLDqn9W+ncd3WqEOzM0fDg+udHxUo5Zsws4EjOzVRoaKrazmFXZfcDWHETL L9XKSx2HsDJklbJkLXTSlGNx2T1vg
v1QyQe1YQIDAQABo4IBwjCCAb4wDgYDVR0P AQH/BAQDAgbAMB0GA1UdDgQWBBQmIYmH4lNknCLa8XU9c9wZ4+HCIDATBgNVHSUE DDAKBggrBgEFBQcDAjAfBgNVHSMEGDA
WgBRn1eSwkQZVMYFLE0THG6NsBNARFTA5 BgNVHR8EMjAwMC6gLKAqhihodHRwOi8vY3JsYmV0YS52ZXJpZC5iaXovVmVyaWRC ZXRhQ0EuY3JsMIIBGgYIKwYBBQUHAQEEg
gEMMIIBCDCBqgYIKwYBBQUHMAKGgZ1s ZGFwOi8vL0NOPVZlcmlkQmV0YUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1T
Mar 16 14:30:32 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : certfields lookup =
Mar 16 14:30:35 tmm tmm[778]: 01220002: repeated 66 times
Mar 16 14:30:36 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : http_request sessionid= + 99f96f36f6ef44a096e8
bc06af9a9ea75846f1c703d755323d428e38b67184ee
Mar 16 14:30:36 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : certfields before if +
Mar 16 14:30:36 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : Ending
Mar 16 14:30:38 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : http_request sessionid= + 99f96f36f6ef44a096e8
bc06af9a9ea75846f1c703d755323d428e38b67184ee
Mar 16 14:30:38 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : certfields before if +
Mar 16 14:30:38 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : Ending
Mar 16 14:34:28 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : http_request sessionid= + 99f96f36f6ef44a096e8
bc06af9a9ea75846f1c703d755323d428e38b67184ee
Mar 16 14:34:28 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : certfields before if +
Mar 16 14:34:28 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : Ending - CR56247 is included in 9.1.1 (as noted in the CR, "Fixed in 9.1.1.54.0". This is the released 9.1.1)
CR26247 also seems to be an issue with the response being NOT FOUND, which doesn't seem to match this problem
I own the subcase for this customer and it looks like the problem is related to the parsing of the expression.
It looks like the Session ID is being interpreted as a command.
Mar 16 14:23:47 tmm tmm[778]: 01220001:3: TCL error: Rule
Cert_Update_Incert_log - invalid command name
"99f96f36f6ef44a696e8bc06af9a9ea15846f1c703d755323d428e38b6718a85" while
executing "[SSL::sessionid] any" - CR56247 is included in 9.1.1 (as noted in the CR, "Fixed in 9.1.1.54.0". This is the released 9.1.1)
CR26247 also seems to be an issue with the response being NOT FOUND, which doesn't seem to match this problem
I own the subcase for this customer and it looks like the problem is related to the parsing of the expression.
It looks like the Session ID is being interpreted as a command.
Mar 16 14:23:47 tmm tmm[778]: 01220001:3: TCL error: Rule Cert_Update_Incert_log - invalid command name "99f96f36f6ef44a696e8bc06af9a9ea15846f1c703d755323d428e38b6718a85" while executing "[SSL::sessionid] any"
Mar 16 14:23:47 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : http_request sessionid= + 99f96f36f6ef44a696e8bc06af9a9ea15846f1c703d755323d428e38b6718a85
Mar 16 14:23:47 tmm tmm[778]: 01220001:3: TCL error: Rule Cert_Update_Incert_log - invalid command name "99f96f36f6ef44a696e8bc06af9a9ea15846f1c703d755323d428e38b6718a85" while executing "[SSL::sessionid] any"
Mar 16 14:23:47 tmm tmm[778]: 01220002:6: Rule Cert_Update_Incert_log : http_request sessionid= + 99f96f36f6ef44a696e8bc06af9a9ea15846f1c703d755323d428e38b6718a85
So, the question appears to be whether this is valid:
set certfields [session lookup ssl {[SSL::sessionid] any}]
The rule info:
rule Cert_Update_Incert_log {
when CLIENTSSL_CLIENTCERT {
log "begining"
log "ssl cert count = + [SSL::cert count]"
if { [SSL::cert count] > 0 } {
session add ssl [SSL::sessionid] [X509::cert_fields [SSL::cert 0] [SSL::verify_result] whole] 450
log "session ID: + [SSL::sessionid] + [X509::cert_fields [SSL::cert 0] [SSL::verify_result] whole]"
log "certfields lookup = [session lookup ssl {[SSL::sessionid] any}]"
}
}
when HTTP_REQUEST {
log "http_request sessionid= + [SSL::sessionid]"
set certfields [session lookup ssl {[SSL::sessionid] any}]
log "certfields before if + $certfields"
if { $certfields != "" } {
HTTP::header insert $certfields
}
log "Ending"
}
}
Thanks,
Michael - You could try this instead:
set certfields [session lookup ssl [list [SSL::sessionid] any]]
