client and server ssl profile

You can actually just use the built-in serverssl profile on the server side. There's usually no need to define any certificates in the server side connection. Also, depending on your web server's ability to handle secure renegotiations, you may need to switch to the serverssl-insecure-compatible profile. You should errors in the LTM log if this is the case. So just to level set:

1. LTM VIP listening on port 443
2. Client SSL profile
3. Server SSL profile
4. Pool pointing to port 443 servers

As Pete states, this is referred to as "SSL bridging". If you completely remove the SSL profiles, where the client and server perform a direct SSL handshake across the F5, this is often referred to as "SSL tunneling". It may be a worthwhile test to see if SSL tunneling actually works. If it does, then re-apply the client and server SSL profiles and take a look at the traffic on either side of the F5. Do you see any traffic on the server side (SSL or otherwise) when it fails? If you don't, that's usually an indication that client side SSL is failing. If you do, then the problem is likely on the server side. One of the best tools to examine this traffic in detail is ssldump. Fire that up from the command line and watch the actual SSL handshake between the client and F5, and between the F5 and server.

ssldump -k [path to private key] -i 0.0 -AdNn port 443 [and any additional filters]

The private key on the client side will be the private key assigned to the client SSL profile. The private key on the server side will be the private key assigned to the web server. If this it an SSL handshake error, it should make itself evident in one of these captures.