Suppose I want to talk to
example.com over TLS the and server I am redirected to is
foo.com. But during the handshake it can prove it holds the private key that matches
Why does that trigger a warning in the browser?
Actually, the answer is within your question:
But during the handshake it can prove it holds the private key that matches example.com certificate
This outlines that that the common name in the SSL certificate doesn't match the address that is in the address bar of the browser (
foo.com). I mean the warning claims that the certificate that has been picked up by request is issued for
example.com, not for
It is like
foo.com is trying to intercept the communication between you and
example.com, and that is the reason of the legitimate security warning you got.
The problem is that the certificate is only valid for use with example.com. A redirect means that there is a completely new connection (to foo.com), and thus the browser treats it as a different server.
To see why this is important, lets look at a hypothetical (and slightly simplified) example. If the browser would accept the certificate belonging to example.com for foo.com, then you could enter your password for foo.com and send it to example.com -- if you imagine that example.com is an attacker, and foo.com is your online bank, then you just sent the attacker your bank password!
In general, redirects are a bit complicated for TLS, because there is no easy way to know whether foo.com and example.com are controlled by the same entity.
The certificate provides authentication. That is, some level of trust that you are connecting to the server that you intended to.
If a MITM redirects your plain HTTP connection from
https://foo.com instead of
https://example.com, it doesn't matter if
foo.com has the private key for the
example.com certificate - your browser will be looking for the authentication for
example.com - it does not care that you were redirected there from