Well, a client SSL profile on the internal target VIP is the server side of the TLS session. If you have a server SSL profile on the outer VIP, then it's the outer VIP's server SSL negotiating with the inner VIP's client SSL. In a typical one-way-auth TLS handshake, only the client is doing any validation here, so the outer VIPs server SSL profile would be doing that. In other words, you can do whatever you want. The "default" behavior of a default server SSL profile is to ignore validation errors. Look under the Server Authentication section of the server SSL profile to define how it handles server cert validation. If you really want, you can apply a real cert/key at the client SSL profile of the inner VIP, and have the outer VIP's server SSL do full CA trust validation of that cert (with a CA bundle).
But I would possibly suggest that you don't need to do this. VIP targeting is an internal process that can be used for many different scenarios. For example, we often use VIP targeting to get around filter ordering in the BIG-IP proxy hud chain. Access happens before HTTP in the hud chain, so a VIP target would let you do HTTP on the outer VIP (first) before the Access on the inner VIP. Or Access before WAF, etc. Or we use VIP targeting to do traffic steering, where the outer VIP steers traffic to one of multiple inner VIPs performing some unique function. VIP targeting is super flexible and solves A LOT of challenges. That said, it's not generally optimal to do decryption on a target VIP, especially if you're also doing it at the outer VIP. It's better to offload decryption at the outer VIP, steer unencrypted traffic to inner VIPs, and then let the inner VIPs optionally re-encrypt to pool members.
client (HTTPS) -> outer VIP (HTTP) -> inner VIP (HTTPS) -> pool
And in this case, your inner VIP can simply apply its HTTP iRules without needing to worry about TLS.