SSL cert in the F5 and in the respective web server

If you offload SSL to the F5 and do not re-encrypt send communicating with the web server it reduces the CPU load on the web server.

By ending the SSL tunnel on the F5 you have access to the data stream in case you need it for some reason. We need access to the data so we can make load balancing decisions and to maintain session persistence.

Now if you have to re-encrypt to communicate with the web server, then you are not reducing the overhead on the web server and unless you have to have the F5 examine the data steam you would just be adding overhead.

Even if you are re-encrypting to the backend servers, you can reduce the SSL key sizes on the backend, compress and cache data on the BIG-IP, and use one connect, all reducing utilization on the backend servers.

You can also then utilize cookie Persistence, perform URI switching, as well as implement additional security services.

In general, even if you need to encrypt to the backend servers there are numerous benefits to placing certificates on the BIG-IP.

I forgot all about caching and compression.

One of the biggest adavantages is the simplification of the certificates management. Among the others advantages already told previously, you may centralize the management of your SSL certificates by placing them at the same location, ie on your Big-IP. Even then, if you have a wildcard certificate, then you could create a profile at the Common level and use it for any Client SSL profile that would need it, instead of recreating a specific SSL profile for each VS.

The Big-IP will be a client to the backend server, and does not deal with interactive warnings you would get in a browser, so you can easily deploy a self-signed cert on your backend server and not really care about it. Of course, it depends on the level of your security standards in your organization.