Currently, the only workaround is to use transport._sock.getpeercert(True) on the Transport returned by loop.create_connection(), which is not something to be encouraged. It is useful to get such information, for example to perform a manual certificate check against a previously recorded certificate or hash.

I attached a trivial patch adding an extra 'peercert_bin' info, but I do not know if this is the right approach, as other issues of feature disparity might arise when more people try to switch to asyncio. Exposing a proxy SSLSocket object for read-only functions might be more beneficial.

Thanks for the patch!

other issues of
feature disparity might arise when more people try to switch to asyncio.
Exposing a proxy SSLSocket object for read-only functions might be
more beneficial.

I'm not sure that would make a difference. We still have to implement the proxy SSLSocket, which is no easier than adding the extra info by hand. Or did I misunderstand you?

I'm not sure that would make a difference. We still have to implement
the proxy SSLSocket, which is no easier than adding the extra info by
hand. Or did I misunderstand you?

The difference would be that exposing methods can be more future-proof, as some methods take parameters (like the offender getpeercert(bool), or get_channel_binding() that takes an element of ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need to be covered in the properties. But the API of SSLSocket is stable and small so I don't think it really matters.

some methods take parameters (like the offender getpeercert(bool), or
get_channel_binding() that takes an element of
ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need
to be covered in the properties

That's a good point. I don't have any strong feelings either way. Perhaps other people want to chime in?

As for the patch, it will need to add a unit test as well.

Maybe

transport.get_extra_info('socket').getpeercert(True)

would be okay, no patch needed?

On Thu, Oct 30, 2014 at 11:56 AM, Antoine Pitrou <report@bugs.python.org>
wrote:

Antoine Pitrou added the comment:

> some methods take parameters (like the offender getpeercert(bool), or
> get_channel_binding() that takes an element of
> ssl.CHANNEL_BINDING_TYPES, list that may grow in the future) that need
> to be covered in the properties

That's a good point. I don't have any strong feelings either way. Perhaps
other people want to chime in?

As for the patch, it will need to add a unit test as well.

----------
stage: -> patch review
versions: +Python 3.5 -Python 3.4

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue22768\>

---

Maybe
transport.get_extra_info('socket').getpeercert(True)
would be okay, no patch needed?

Thanks, that indeed works; I don't know why I missed it while reading the source. Maybe the docs could use some clarification, though? (users are not supposed to know that _SelectorTransport is subclassed by _SelectorSslTransport, which thus gets the extra info of both)

Maybe
transport.get_extra_info('socket').getpeercert(True)
would be okay, no patch needed?

That will be problematic with bpo-22560. The clear-text socket object and the SSL object become unrelated, and it would be logical for get_extra_info('socket') to return the clear-text socket, so either a get_extra_info('ssl') would be needed, or we should expose the SSL properties directly as extra info members.

Thanks, that indeed works; I don't know why I missed it while reading the source.

Ok, it looks like we can close the issue.

That will be problematic with bpo-22560.

In this case, it should be discussed there.

In Python 3.5, it's no more possible to get the peer certificate as binary. See the issue bpo-25114 for a general fix.