It's unclear from your question if you're asking about a hypothetical or an actual scenario that you've observed. In the former case, you should read about how TLS works in general, and in the latter case somebody has screwed up big-time. My answer below explains what would have to go wrong (and hopefully thus, if this isn't hypothetical, what went wrong and thus how to fix it) in either case.
By default, what you describe wouldn't work at all unless for some reason you set up F and A with the same private key (don't do that; never reuse or expose private keys!). C connects to some server (F in this case) and says "Hey, are you server A? Prove it". F sends A's certificate (which is public knowledge and contains A's public key). Skipping ahead a few steps, F then has to send a cryptographically signed piece of data (ECDHE public parameter for key exchange) to C. However, since F doesn't know A's private key, F can't produce a signature that C will accept based on A's public key, so C will reject the key exchange, close the connection, and report a cryptographic error likely to be due to a man-in-the-middle.
F could attempt to modify A's certificate to have F's own public key (corresponding to F's private key, which is the only one F knows). However, this modification of A's certificate would invalidate the signature on the certificate, and by default, C would reject the certificate immediately, without even getting to the key exchange step.
The only ways an attack like you describe could be possible are:
- The private keys of F and A are the same. This will never happen by chance (not literally impossible but still, trust me, your mind can't properly conceive of how unlikely it is to happen).
- C has been configured to not validate certificates, so that F can freely modify A's certificate and C won't notice. This is possible and some unwise people do it for development testing (and inevitably some of those forget to fix it before release) but is a major security flaw and requires active effort on the developer's part; cert validation is enabled by default.
- C for some reason has been configured to allow "anonymous" TLS connections, where it doesn't attempt to verify the server's identity at all. Most people don't even know TLS supports this; it's almost never used and would be extremely weird to find in an Android app.
- F has cracked A's public key, enabling F to generate signed messages that appear to legitimately come from A. Nobody has come close to cracking the length of keys (RSA or ECDSA/EdDSA) conventionally used in certificates these days, and it would be a major disaster for a lot of Internet security if that were to change. Older SSL/TLS implementations allowed smaller or weaker keys, such that if the owner of A were very foolish they could have used a weak enough public key that modern computers could crack it, but modern TLS implementations don't allow the use of keys that weak.
- F has directly stolen A's private key somehow (for example, via an attack like Heartbleed or Spectre/Meltdown/Downfall/etc., or because A put the private key somewhere that was exposed, like a source code repository).
- F has gotten a valid certificate (signed by a trusted certificate authority) issued for A but with a public/private key pair that F knows. (This could happen by suborning a CA, or stealing their signing key, or exploiting a vulnerability in their domain verification process, but none of these are common.)