Client cert for IIS getting dropped

Are you saying that the IIS server needs to get the actual client's certificate? If so, understand that once the SSL session is terminated on the client side, with client SSL profile, the client can no longer send its certificate to the server. This is because the client will sign its certificate (and other data) with its own private key. The BIG-IP wouldn't have access to the client's private key, so it cannot send it to the server in the SSL handshake. You basically have three options then:

1. Remove the client and server SSL profiles and let end-to-end SSL pass through the BIG-IP. You lose a significant amount of flexibility with this approach since you can no longer see the unencrypted payload.

    

2. If you're running BIG-IP version 11.1 or higher (11.3 HF5+ preferred), you can use a feature called "ProxySSL", which is an SSL man-in-the-middle. The client and server SSL profiles have a copy of the server's private key and can transparently decrypt the payload. You gain back some application layer insight, but you have to be careful with some things as the SSL session is made between the client and a specific server, and that can not be altered once established.

    

3. Consider another way to authenticate at the IIS server. There are a many ways that you can pass validated credentials to a web server, including HTTP headers, server side cookies, and all of the SSO functions that Access Policy Manager (APM) can provide.

    

I think we're still talking about the same things, and without completely restating the Microsoft article, allow me to make a few points.

1. SSL communications are ultimately dependent upon the server certificate and private key. A client certificate, if any, is ONLY used to authenticate the client. A client certificate is NOT required when doing SSL, but a server certificate and private key are absolutely necessary. The app guys are correct about "the client certificate used for IIS is completely separate than the SSL certificate we terminate on the F5". A client certificate is issued to a client and is used to authenticate the client, while the server certificate planted in the client SSL profile on the F5 is used to build the encrypted SSL session.

    

2. An SSL session is initiated when a client sends a CLIENTHELLO message and a list of the cipher suites it supports. The next two messages are the server's SERVERHELLO message with the chosen cipher, and then the server's public certificate (which the client must validate). The client will generate a random seed value that it'll encrypt with the server's public certificate and send that back to the server. Both parties will then independently derive the session encryption key from that random seed value. Only then, and only if it's required, will the server request the client's certificate. That certificate is only used to validate the identity of the client.

    

3. When the client sends its certificate, it'll digitally sign it (and some other data) with its private key. The client certificate authentication settings in the LTM client SSL profile are basically the same as the SSL settings in IIS that allow you to choose ignore, request, or require a client certificate. A digital signature is a hash of some data that is encrypted with a private key, which only the corresponding public key can decrypt. The server receives the data from the client, creates a new hash, decrypts the digital signature, and then compares the two hashes to prove 1) that the data wasn't modified in transit [integrity], and that 2) the user is who they claim to be based on the idea that only the possessor of the private key could have encrypted this data [non-repudiation and authentication].

    

4. The important take-away from the above is that the entity that terminates the SSL session (be it the LTM or IIS server) also destroys the digital signature of the client's certificate. If the LTM terminates the client side SSL and consumes/validates the client certificate, it CANNOT pass that same certificate to the server in a server SSL session, simply because the LTM does not possess the client's private key to generate a new digital signature. It is not possible to send a client certificate to a server on the other side of a proxy if the proxy terminates the client side SSL. The ProxySSL feature doesn't change that fact. ProxySSL allows the LTM to be a silent partner in the SSL handshake and derive the same session encryption key that the true end points will use. With this the LTM can see inside the encrypted payload and do some somewhat limited layer 7 processing on that data (ie. traffic inspection, cookie insertion, etc.). And because the end points are the client and IIS server, the client can send its certificate directly to the server in the SSL handshake. The only other alternative is to allow the SSL to pass unproxied through the LTM (no client and server SSL profiles), which subsequently eliminates your ability to do anything useful with the layer 7 data.

    

5. A final option, as I related earlier, is to simply choose a different authentication mechanism at the IIS server and let the LTM (the trusted proxy) vet the users on its behalf. Consider also that IIS is simply the web server and is separate from the application that it hosts. Ultimately the web server will collect some credential and present it to the application. To that end, the application can often be oblivious to how the identity is collected, and could just as easily use values passed to it from any other authentication method.

    

Well we ended up just passing that traffic through the F5, no proxySSL or anything since we didn't really need to see the data on F5. Just did SSL persistence. Works great now. Thanks Kevin!

Well we ended up just passing that traffic through the F5, no proxySSL or anything since we didn't really need to see the data on F5. Just did SSL persistence. Works great now.

Just be aware that using SSL persistence with a browser-based app is a slippery slope. Persistence is based on a session ID that is generated in the handshake and maintained throughout the session. The client browser and/or server can, and very often will, renegotiate the SSL at fixed or random intervals, which changes the session ID. Each browser is different, but you're almost guaranteed to run into this at some point.