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 example.com
certificate.
Why does that trigger a warning in the browser?
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 example.com
certificate.
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 foo.com
.
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 example.com
to 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 foo.com
not example.com
- it does not care that you were redirected there from example.com
.