Forum Discussion
Tobias_G_
Nimbostratus
NimbostratusiRule to compare Client Certificate with HTTP authentication
Hi all,
we currently have some problems with the following iRule. This iRule works in addition with a SSL profile requiring client certificates to be presented, which are issued by the correct CA.
The iRule parses the certificate's subject (which is of format "CN=common name,OU=my ou, O=organization") and compare the OU part to a hard-coded string and the CN part to the username presented in the HTTP authorization header for ActiveSync connectivity.
When testing this out with a single device, everything is working fine, as soon as several hundred devices connect to the virtual server, many of those devices experience connectivity problems.
When I enable debug logging, I noted the following:
- No "mismatch" was presented, so every connection which made it to the logfile, presented matching credentials
- I got many many errors, which tell me, that the "subject_dn" is empty, which I do not understand, because how can the iRule reach the "when HTTP_REQUEST" without a valid SSL client certificate presented, when the SSL profile is set to require the certificate??
Maybe anyone can point out some obvious errors or ways to do things more efficient (like the parsing of the cert subject).
when CLIENTSSL_CLIENTCERT {
session add ssl [SSL::sessionid] [X509::subject [SSL::cert 0]] 1200
}
when HTTP_REQUEST {
set client_ip [IP::client_addr]
set subject_dn [string tolower [session lookup ssl [SSL::sessionid]]]
set ssl_ou " "
set ssl_username " "
scan $subject_dn {%[^=]=%[^,],%[^,],%[^,]} ssl_cn ssl_username ssl_ou ssl_org
if { $ssl_ou != "ou=my ou" } then {
HTTP::respond 495 content "Organization mismatchWe are sorry, but your provided organization does not match your identity certificate" noserver
} else {
set http_username [string tolower [HTTP::username]]
if { $ssl_username != $http_username} then {
HTTP::respond 495 content "Username mismatchWe are sorry, but your provided username does not match your identity certificate" noserver
}
}
}
2 Replies
- nitass
Employee
- I got many many errors, which tell me, that the "subject_dn" is empty, which I do not understand, because how can the iRule reach the "when HTTP_REQUEST" without a valid SSL client certificate presented, when the SSL profile is set to require the certificate??could it be 1200 seconds timeout?
Maybe anyone can point out some obvious errors or ways to do things more efficient (like the parsing of the cert subject).what version are you running? starting from 10.1.0, it is no longer needed to store client certificate in session table.
In BIG-IP versions prior to 10.1.0, it is necessary to store the client’s certificate in the session table because the SSL::cert iRule command returns information about the client’s certificate only during the TCP connection in which the certificate is actually presented. For example, if the client resumes an SSL session, the SSL::cert iRule command does not return any information.
Beginning in BIG-IP 10.1.0, the BIG-IP system automatically caches the client’s certificate along with the SSL session ID. Therefore, as of BIG-IP 10.1.0, it is no longer needed to store the client’s certificate in the session table.sol11479: If the session iRule command is used to add binary data to the session table, the data will be corrupted
http://support.f5.com/kb/en-us/solutions/public/11000/400/sol11479.html 
IheartF5_45022Nacreous
To address the parsing of the cert subject to extract the Common Name, try;-
set client_cn [lindex [split [X509::subject [SSL::cert 0]] ",="] 1]
