Multiple SSL Client Profiles for one Virtual Server

I don't believe either need the default check box, but for SNI both profiles must have a unique server name attribute. SNI switches the client SSL profile based on the server name TLS extension in the CLIENTHELLO message during the SSL handshake.

Thanks for your response, Kevin. I added "collector.api.devabcdcentral.com" as the Server Name in the profile that I am newly adding but now I get an error saying "0107157c:3: Selected client SSL profiles do not match security policies for Virtual Server"

Could you please share some pointers/ideas about what it means?

Sorry I partly misread your response missing out on the part where you said 'both' profiles need to have unique server name. However, I don't really control the other profile - it belongs to other team(s). What could be my options in this case? Do we have some pattern matching there so that when the HTTP request says "collector.api.devabcdcentral.com" it will hit my new SSL client profile otherwise will go to the other profile?

Hmm. Well, here's what you need for SNI to work:

1. Each client SSL profile that you apply to the VIP needs a UNIQUE server name. One can be blank if it's set as the default profile, but it's generally a better idea to explicitly add the server name to each. This is the name that the client uses to address the server. <- it MUST match both the requested server name and the server name (or a subject alt name) in the client SSL profile's assigned certificate.

    

2. The client must support the TLS protocol, at the very least version 1.0, and the client and server must negotiate TLS (versus SSL).

    

For the sake of testing, you can do the following:

1. Apply each client SSL profile to the VIP individually and very that the profile and client meet each other's negotiation requirements.

    

2. Capture the traffic between the client and virtual server with SSLDUMP. This will provide additional insight into why the handshake may be failing.

    

There's nothing you can do in HTTP (layer 7) that can affect the SSL handshake (layer 5/6). You either need to set a server name in the other client SSL profile, or check its default SNI option. In either case you have to be able to modify it. You could alternately:

1. Request a new server certificate that has your server name as a subject alt name (a "SAN" certificate).

    

2. Put the applications on separate VIPs.

    

Just so that I understand you correctly, if the client will be using https://collector.api.devabcdcentral.com in curl then the server name in SNI with value "collector.api.devabcdcentral.com" should be correct, right?

Also, could you please elaborate on what you mean by "<- it MUST match both the requested server name and the server name (or a subject alt name) in the client SSL profile's assigned certificate." from you comment?

To give you a little background: The virtual server is "int_api.devabcdcentral.com_wildcard_443_dev" which handles any traffic matching *.api.devabcdcentral.com at 443. This already has an SSL Client profile (no client authentication set up) attached to it. To this I am adding a new SSL Client profile that will handle traffic intended for "collector.api.devabcdcentral.com" and this one needs a curl to present a certificate (client authentication on).

I am unable to follow point 1 from the testing suggestions because it is a shared virtual server and if I take off the original SSL client profile then it might break the existing services hosted there.

Ah, we'll that makes a lot of sense. The wildcard cert in the other profile is a catch-all. I honestly don't believe that SNI will work with a wildcard server name (haven't tested that), nor do I believe that a more specific server name SNI profile would be selected. I think your only option here is separate VIPs.

Also, could you please elaborate on what you mean by "<- it MUST match both the requested server name and the server name (or a subject alt name) in the client SSL profile's assigned certificate." from you comment?

The server name string in the client SSL profile must match what the client is asking for. The client will embed this name in the CLIENTHELLO TLS handshake message. It's also important, though not as important, that the server name in the certificate applied to that profile also uses the same server name.

There are actually two other options that I can think of:

1. iRule to force SSL renegotiation and client cert prompt based on the HTTP host name. This one tends to get a little complex depending on the environment, but not too bad.

    

2. Access Policy Manager (APM) module. If you can configure the cURL client to be able to follow HTTP redirects, APM can do this (SSL renegotiation and cert prompt) natively, among other things.

    

I was also fighting with the error message:

Selected client SSL profiles do not match security policies for Virtual Server

And I found out that the reason seems to be that all SSL profiles need to have the same parent. Is this really the case or is this depending on the differences between the parents? For me it was just a different Cipher String and Renegotiation was disabled.

Thank you!

Ciao Stefan 🙂