tl;dr - plan to focus on client side SSL sockets first, so as to support pip, requests, and other client libraries.
My expectation is that an example like the following use of ssl.wrap_socket should work:
This code snippet, which does *not* work on Jython currently, uses a mode of operation similar to what pip now requires: blocking client sockets, wrapped with SSL. Instead this code snippet fails because of an uninitialized underlying Java socket in Jython's socket module. I'm just trying to get my head around this code, but it seems that the design, so as to support nonblocking sockets, does not expect initializations to be completed; but in this particular case, this is required. So some debugging required.
This bug is almost certainly related to why pip currently fails when it's using SSL, and such client support seems to be the most important target for SSL support. It would also help support requests over SSL. So your use cases should then work. These are also *my* use cases for Jython, so it's important to me to get this to work :)
Digging beyond this set of cases, there's a note by Alan Kennedy on the possibility of other modes of SSL support, such as with server sockets see http://wiki.python.org/jython/NewSocketModule#SSL_Support
; note this was written maybe prior to when ssl was added to CPython 2.6. At this point, there's a clear API, just a need to implement it. I'm not certain who would work on this however.
But while client compatibility is important for tools like pip, if I were implementing something high performance in Jython that required SSL server sockets, I would stick with using the underlying Java ecosystem. Maybe use Netty and its SSL support. In particular, a Twisted reactor using that would make more sense, much like other reactors for say libevent.
Hope that helps!