ssl.wrap_socket() always uses the SSL certificate associated with the raw IP address, rather than using the server_host feature of TLS. Even when wrap_socket is used before calling "connect(port, host)", the "host" parameter isn't used by TLS.

To get proper TLS behavior (which only works in recent Python versions), it's necessary to create an SSLContext, then use

context.wrap_socket(sock, server_hostname="example.com")

This behavior is backwards-compatible (the SSL module didn't talk TLS until very recently) but confusing.  The documentation does not reflect this difference.  There's a lot of old code and online advice which suggests using ssl.wrap_socket().  It works until you hit a virtual host with TLS support. Then you get the wrong server cert and an unexpected "wrong host" SSL error.

Possible fixes:

1. Deprecate ssl.wrap_socket(), and modify the documentation to tell users to always use context.wrap_socket().

2. Add a "server_hostname" parameter to ssl.wrap_socket().  It doesn't accept that parameter; only context.wrap_socket() does.  Modify documentation accordingly.

Not sure why you're using wrap_socket() directly. Most of the time you should be using a higher-level library instead (for example a HTTP(S) library).

In any case, the doc already mentions that "Starting from Python 3.2, it can be more flexible to use SSLContext.wrap_socket() instead".

I leave this open in case other people feel positively about it.

I'm using wrap_socket because I want to read the details of a server's SSL certificate.  

"Starting from Python 3.2, it can be more flexible to use SSLContext.wrap_socket() instead" does not convey that ssl.wrap_socket() will fail to connect to some servers because it will silently check the wrong certificate.

ssl.wrap_socket() will be deprecated in 3.6. Please use a context. You can still inspect the server cert with a context. In fact ssl.wrap_socket() uses a context internally.