Big-IP: SSL Client Cert Pass Through iRule

You have to understand that an SSL "session" is (generally) between two parties, and the SSL handshake between those two parties sets up all of the cryptography that they'll use throughout that session. In other words, the handshake establishes the keys that are used to encrypt and decrypt data between the client and server. Before talking about "ProxySSL", it's necessary to establish that for an intermediary to communicate inside an SSL channel between the client and server, it must establish two separate SSL sessions: as the server to the client and client to the server. As you pointed out, the proxy can't send the client's certificate to the server because it doesn't have the client's private key. More specifically, during the SSL handshake the client sends a CertificateVerify message that is a) a hash of all previous messages (which would technically be between it and the proxy), and b) the hash is digitally signed by the client's private key. The server couldn't validate that message hash and the proxy couldn't sign it anyway. ProxySSL, if that's indeed what you meant by "proxy SSL" is a special SSL man-in-the-middle function that, with knowledge of the server's private key and an RSA-based key exchange, can silently (non-interactively) "watch" the actual key exchange between the client and server, collect the client's random number, the server's random number, and decrypt the premaster secret with the server's private key to arrive at the same shared master secret key. With that the proxy can decrypt and re-encrypt the bulk symmetric crypto between the parties without either knowing it. The most important thing to understand here is that the proxy has no control over the handshake process, and that's where certificates are exchanged. To put it more bluntly, BIG-IP SSL events (like CLIENTSSL_CLIENTCERT) do not get triggered inside of a ProxySSL session because the BIG-IP is not a party to any of the handshake. ProxySSL will certainly allow the client to pass its certificate to the server, directly. But it does not allow the proxy itself to collect the certificate.

That said, it is completely non-trivial but certainly possible to collect the client's certificate in an initial handshake using OSI layer 4 events. The client's Certificate message is sent in cleartext in an initial handshake, but encrypted in renegotiation handshakes. You'd be digging in binary data, but once you had it you could then push it out to the server in, for example, and HTTP header.