At a high level this is true, but in practice it's not what's happening, TLS 1.3 makes this tidier so let's use that example:
1. Alice proposes to send encrypted messages to Bob, she hopes this first, unencrypted, message reaches Bob (but if it doesn't she'll be fine, except that she reveals she wanted to talk to Bob) and it has a Diffie-Hellman Key Share inside it which is just basically a number Alice got by doing some mathematics on a (different) random number that Alice never tells anybody, even Bob.
2. Somebody receives Alice's message, they do the other half of the Diffie-Hellman Key Share, and send that to Alice. Both this somebody and Alice now (thanks to DH) have a set of symmetric encryption keys nobody else knows. So using symmetric encryption they immediately have an encrypted channel between Alice and whoever somebody is.
3. The somebody sends Bob's certificate over the encrypted channel. But Bob's certificate is a public document, it does NOT prove this is Bob.
4. If this is really Bob he wraps up everything they both said so far (message from Alice, reply from Bob, sending back a certificate etcetera) and Signs that with his private key which is paired with the public key inside his certificate. He sends the signature to Alice over the encrypted channel. He _could_ also demand a certificate & signature from Alice at this point but on the web basically nobody does this.
5. Now Alice knows this is really Bob and can safely send messages on the encrypted channel to Bob.
There's no need for any messages to be signed with Bob's key after step 4, all messages are protected with the symmetric encryption keys agreed in steps 1 & 2.
Simply "flagging" things if they're apparently changed isn't good enough, bad guys can use this to create an "Oracle" which destroys security eventually. Instead modern TLS with AEAD will simply abort the entire connection after decrypting a message which has been tampered with, and (correct implementations of) TLS refuse to give you partially decrypted messages, either the whole message arrives and is decrypted successfully, or it hasn't and you can't have the data. Thus an adversary learns nothing from tampering: They know they tampered with the message, and it's not a surprise this blew up the connection - doing it again, and again, and again teaches them nothing further.
If you want to see how it could go wrong otherwise, check out videos of "Lucky Thirteen" which gradually guesses bits of data your browser is wiling to send repeatedly over HTTPS connections while it improves the guess (e.g. cookies). A modern browser mitigates this attack by making the timing involved impractical, but AEAD is better.