Client cert for IIS getting dropped

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.