Issue with certificates using public F5 presence to internal resource

If possible, can you post configuration snippets? I'm guessing *.wildcardcert.com is your public SSL certificate? If so, you want that in a client-ssl profile assigned to the first hop. Then, the default serverssl profile assigned to that vip. Then, on 10.1.104.56, I think you can use teh default client-ssl profile with NO serverssl profile (assuming port 5011 is meant to receive unencrypted traffic?).

The intention is to have the traffic encrypted end to end.

What is the purpose of decrypting and re-encrypting across multiple devices if you want end-to-end SSL? Are you performing some functions on the F5s that require access to the unencrypted data?

I'll assume for the moment that you're doing something with the unencrypted data (maybe inserting HTTP persistence cookies or adding WAF inspection services). In this case you have THREE separate SSL sessions: client to external F5, external F5 to internal F5, and internal F5 to server. The client to external F5 configuration is pretty straight forward. But understand that when the BIG-IP re-encrypts, via server SSL profile, it is the CLIENT in that SSL session. So in the case of the interior SSL session, the external F5's server SSL profile doesn't really need a certificate and key applied, as that would be treated like a client certificate and key and only needed if the server side required mutual authentication (which I'm assuming you're not doing). Your best option here is probably to use the default server SSL profile on the external and default client SSL profile on the internal. If you need additional security in this channel (probably not), then make sure you modify both profiles accordingly. As for the internal-to-server SSL session, again the BIG-IP is the client in this case, so the insecure-compatible server SSL profile is only needed if the server explicitly requires it. For the most part, the insecure-compatible profile disables strict secure renegotiation and slightly modifies the available ciphers.

You can tell if a server is capable of RFC5746 Secure Renegotiation by issuing an openssl s_client command to it form another system.

openssl s_client -connect 192.168.1.1:443

It'll list this setting in the output. Example:

...
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated 
...

Other than that, if you're still having issues, I'd inspect the SSL handshakes at each of these three places and look for errors.

ssldump -AdnN -i <0.0 for all interfaces or a single VLAN/interface name> port   

If I understand correctly, the following diagram depicts the location of the SSL profiles. I'm sort of confused as to which profile is used where. Please help me get some clarity.

That's exactly right. A client SSL profile is used when the server the BIG-IP is the server side of the SSL session. A server SSL profile is used when the BIG-IP is the client side of the SSL session. That's not confusing at all! [sarcasm] 😉

So in your case, you have a client SSL profile applied to the external F5 to establish an SSL session with the client. You have a server SSL session applied to the internal F5 to establish an SSL session with the server. And you have a server SSL profile applied to the external F5 that acts as the client side when talking to the client SSL profile on the internal F5. The beauty of the proxy design is that these three SSL sessions are completely independent of one another. You could encrypt to the client and/or to the server and not do encryption in the middle for example.

client --(ssl)--> F5 -------(clear)-------> F5 --(ssl)--> server

Or simply not encrypt past the external F5. The reason I'm bringing this up is that you might find some value in simply turning off SSL between the F5s to allow for more isolated troubleshooting of client and server side SSL.

In any case, the only SSL profiles that really require any specific attention are the profiles that touch the client and server. Client browsers are generally very flexible with regard to cryptography, so a simple client SSL profile based on the default profile is probably a good start. The server SSL profile, the one connecting to the server, may need tweaking if an older server can't handle secure renegotiation or more modern ciphers. As for the SSL session between the F5s, I'd just use the default client and server SSL profiles here.