SNI and Client certificate authentication

A bit more investigation. Without any authentication profile enabled and just a default SNI ssl client profile and another ssl client profile that uses SNI and a simple irule:

when CLIENTSSL_HANDSHAKE { log local0.debug "My selected sslprofile [PROFILE::clientssl name]" }

I always get the sslprofile name of the profile that is on top in the list in my VS->SSL Profile (Client) even though I send in SNI in my handskake and I get the correct server certificate back.

I would have expected to get the profile name in the log that is corresponding to my SNI clientssl profile...

I've no doubt where the iRule is concerned it's simply a matter (as used to be the case with HTTP::uri and others) that what's logged doesn't actually reflect changes that have occurred during LTM (and iRule) processing. Perhaps change the event to a serverside one (but specify clientside operation) to get the real picture. Of course, logically, this may just be how things work for now.

Regarding the ClientSSL issue, I assume you've specified different CA's in each profile?

This one is definitely unusual. For all intents and purposes, if the SNI-based profile selection is based on the CLIENTHELLO message, I would think the parts of the individual profiles shouldn't matter and certainly shouldn't have to match. I would also comment that trying to do anything in an iRule under the CLIENTSSL_ commands is too late in the process. For that reason I put together a potential workaround that relies on capturing the CLIENTHELLO server_name data in the (still unencrypted) TCP payload. Here's what it looks like:

when CLIENT_ACCEPTED {
    TCP::collect
}
when CLIENT_DATA {
    if { [info exists selected_profile] } { 
         use specified client SSL profile if set
        catch { eval "SSL::profile $selected_profile" } 
    } else {
         look for CLIENTHELLO message in the TLS handshake (SSL bypassed)
        binary scan [TCP::payload] cSSc tls_xacttype tls_version tls_recordlen tls_handshake_type
        switch -- $tls_version {
            "769" -
            "770" -
            "771" { 
                if { $tls_handshake_type equals 1 } {
                     CLIENTHELLO message
                    binary scan [TCP::payload] H* hexdump
                    if { [class match $hexdump contains my_ssl_profile_dg] } {
                         use client SSL profile from data group
                        set selected_profile [class match -value $hexdump contains my_ssl_profile_dg]
                        catch { eval "SSL::profile $selected_profile" }
                    }
                } 
            }
        }
    }
    TCP::release
    TCP::collect
}

Essentially what's happening is that I'm capturing the TCP payload and looking for a CLIENTHELLO message inside a TLS (1.0, 1.1, or 1.2) handshake. I toyed with a few different approaches, but for the sake of simplicity I hex-encoded the server names and added them to a data group with the corresponding client SSL profile name. Example:

6d79736572766572312e646f6d61696e2e636f6d := myserver1.domain.com_clientssl
6d79736572766572322e646f6d61696e2e636f6d := myserver2.domain.com_clientssl

You can get these values with the following code:

when RULE_INIT {
    binary scan "myserver1.mydomain.com" H* tmp
    log local0. $tmp
}

Another option would have been to loop through the literal server name strings in the data group and hex encode them on the fly. Ultimately, instead of trying to binary parse the CLIENTHELLO payload to find the exact server_name value, I'm simply looking for this particular hex string in the hex-encoded payload. Once I find and match the payload value to a data group entry, I extract and use the defined client SSL profile. The SSL::profile command isn't technically supported in the CLIENT_DATA event, so I wrapped in an eval command, and again in a catch command. I also set the profile name to a local variable so that subsequent requests in the same TCP session will use the same profile. You need at least one client SSL profile applied to the VIP, and all non-TLS-capable clients should simply fall through to this default profile.

The one thing it doesn't seem to support is flipping back and forth between the SSL VIPs in a single browser session. I don't imagine that'll happen often and I haven't figured out how to fix that yet. This workaround does seem to work well though. It also supports client SSL profiles with different client cert auth settings.

Thanks for the excellent reply Kevin!

In my case I ended up with two SSL profiles and one OCSP authentication profile and an iRule that send traffic to the correct pool for the type of client as determined by the iRule looking at the certificate in CLIENTSSL_CLIENTCERT.

It seems to work reasonably well. I think we can live with not being able to set different cipher suites on the two SSL profiles.

Hi all,

it seems I'm running into the same issue, but I'm not sure if I really understand the above answers correctly.

We also have a VS with currently seven different clientSSL-profiles (and might be more in the future). One of it should be configured with Client Authentication, but if I try to enable it I get the following error message.

0107157c:3: Selected client SSL profiles do not match security policies for Virtual Server /Common/.

The default SSL profile contains a self-signed wildcard certificate and all other six profiles just have its cert-key-chain configured and the appropriate "Server Name". The chain is equal for all six "real" certificates and I also tried to include it for the default wildcard profile, but the error message is still the same.

Right now I don't see the reason for this error message and therefor don't know where to search for. And I also don't really understand if the answer from Kevin is the solution/workaround for my setup as well.

We have another VS with just one clientSSL-profile active and there Client Authentication can be enable without any issues.

By the way we are using 11.5.3

Thank you for your help or further ideas!

Ciao Stefan 🙂