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.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Aug 15, 2019 at 12:45

3 Answers 3


... 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.

  • It can solve this, because the attacker can't sign own public key with CA's private key. But i was using wireshark to understand ssl handshake before the topic. There was a "subjectPublicKey" segment in the data. I tought the signature doesn't include the public key. Is public key in the signature?
    – Grey
    Commented Aug 7, 2019 at 7:54
  • 1
    @Grey As you've noticed yourself, it has to include the public key (and the certificate chain), otherwise the whole HTTPS system would be pretty much useless. If you could take a valid certificate and change the subject or public key without invalidating the certificate... where's the trust? :) Anyone could pretend to be Google.com just by obtaining a valid certificate for Mysite.com and changing the public key :)
    – Luaan
    Commented Aug 7, 2019 at 10:56

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.

  • 4
    If the MitM attack was successful, surely the attacker can overcome the mentioned check? Or is something else in play here?
    – Moo
    Commented Aug 6, 2019 at 8:59
  • 3
    @Moo: Agree, this needs some more explanation (also, certificate chains would be quite useless if it was just that easy, it seems unplausible). Someone doing a MitM has seen everything that went over the wire unencrypted and is able to decrypt/re-encrypt the now encrypted traffic (including Finished message). So obviously, the attacker could as well forward a fake hash to each side, which corresponds exactly to what the respective side has seen.
    – Damon
    Commented Aug 6, 2019 at 10:30

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.

  • 1
    There is not one standard CA list; Microsoft has one, Apple has one, and Mozilla (Firefox) has one. Unix (including Linux) vendors often use Mozilla's but sometimes modify it. Oracle Java has its own, although OpenJDK can and often does use whatever is 'native' on the target platform. And all of these evolve over time, while a particular copy/install may or may not get updated. However, they are all similar. Commented Aug 6, 2019 at 1:46
  • 6
    The CA/Browser Forum cabforum.org is a group of CAs that maintains a list respected by most OS and browser manufacturers. Vendors are free to use it whole, add to or subtract from it, or ignore it as they will. It’s not technically a standard, but it’s the basis for most lists. The distinction isn’t terribly important in the context of this question. Commented Aug 6, 2019 at 1:57
  • I used the words “official list” trying to imply that each vendor has their own official list. Commented Aug 6, 2019 at 1:59
  • cabforum, which as the name says has both CA and 'browser' (really, client) vendors as members, maintains several standards that CAs should meet and clients should accept, but I see no evidence they maintain their own CA list. In fact cabforum.org/browser-os-info explicitly points to the (separate, but similar) browser/OS programs and lists. Saying 'an official list' is ambiguous; 'an' means one and 'official' suggests some authority imposes the same one on everybody. Commented Aug 6, 2019 at 10:36
  • @dave_thompson_085 , thanks, I fixed the answer. Commented Aug 6, 2019 at 14:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .