The communication is not encrypted during the SSL handshake. If an attacker conducts a man in the middle attack between server and client to capture the certificate, and change the public key in the certificate and send it to client, then the digital signature is same, all the properties except public key are same.
So how can a browser understand the difference? If browser validates it, the attacker can use his/her own key pair and doesn't need the private key of the server.
... change the public key in the certificate and send it to client. Digital signature is same, all the properties except public key are same. So how can browser understand the difference?
The browser checks that the signature of the certificates fits the certificate. Since the public key is included in the signature and the public key is changed, the signature no longer fits the certificate. Therefore the validation will fail.
At the end of the TLS negotiation (the "Finished" message), the client and the server take a hash of the entire conversation they've had so far, and they compare it. If it differs - as it would if someone performed a MitM attack on the certificate - then the connection is dropped.
To quote RFC 5246:
The Finished message is the first one protected with the just
negotiated algorithms, keys, and secrets. Recipients of Finished
messages MUST verify that the contents are correct. Once a side
has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.
To address comments by @Moo and @Damon, the Finished message will not prevent a full MitM ("SSL Interception") attack, where the MitM can directly intercept and proxy all TCP and has a valid certificate in the name of the target. It only prevents discrete tampering with the stream between the client and server - as was proposed by the OP.
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.
