This is the unfortunate flaw with SSL and TLS. The certificates are bound only to the "domain name" which is a wobbly concept at best without DNSsec to validate your DNS responses.
Anyone clever enough to create a DNS redirector that turns paypal.com into 10.0.0.2 on their closed network could also create an accompanying SSL certificate that they own for paypal.com and you'd be none the wiser as they proxy all of your traffic through their server, logging every bit of it.
Wait, what? No they can't. The whole point of SSL/TLS is that you don't trust the DNS.
The only way an attacker can redirect DNS for Paypal and have a valid-looking CA for Paypal is if they compromise a CA root certificate. That's the point of SSL/TLS.
Before you suggest "but we can't trust the CAs", note two things: (1) if you don't trust the CA, SSL/TLS isn't doing anything for you anyways, and (2) DNSSEC also has a hierarchical PKI in which you are required to trust commercial enterprises --- or governments, explicitly.
SSH has more robust security than SSL seems to if only because once you've established a connection with a remote host, whereupon their public key is displayed and validated, it can be saved as "trusted".
The same principle doesn't seem to apply for SSL in browsers where, so long as it's signed by a "trusted" authority, there's no question the certificate is valid.
And even if the IP address is unaltered - what will prevent the owner of the closed network from routing every http(s) request silently through a proxy on its way out to the Internet?
Anyone clever enough to create a DNS redirector that turns paypal.com into 10.0.0.2 on their closed network could also create an accompanying SSL certificate that they own for paypal.com and you'd be none the wiser as they proxy all of your traffic through their server, logging every bit of it.