Certificates don’t exist in isolation. To be trustworthy, a certificate must be signed by an issuer; these issuers are called Certificate Authorities. Each browser (or operating system) maintains their own list of a few hundred trusted CAs (called Root CAs) that it already knows and trusts; and your employer or school may have their own private issuing root CA. If a certificate is signed by any issuer not known to a client, it is not trustworthy.
So long before the TLS handshake gets to the Finished part of the protocol, the server sent its public key in its certificate in the Server Hello message. The client is responsible for validating the whole certificate as soon as it gets it. Validation includes checking the certificate’s expiration date, its signature, AND the issuer’s signature and its issuing certificate. If the issuing certificate isn’t from a known, trusted issuer (one that the client has on that internal list of trusted root CAs), the client should reject the connection.
Therefore if an attacker substituted a different certificate that wasn’t signed by an authority the client already trusts, it would be rejected because the issuer wasn’t found in the list of trusted CAs. If the attacker tried to use their own key without sending the proper certificate, the client would be using the wrong key, and would not communicate properly during the Finished message.
If the attacker managed to add their fake root CA to your system’s list of trustworthy CAs, then yes, the attacker could perform a man in the middle attack, and view your communications. This is often deliberately done by companies looking to inspect all web traffic, to run anti-virus scans, to prevent malware, to prevent secrets from leaking, or to simply monitor their employees’ web surfing.