homepage

Here is a short example to reproduce the error:
>>> import socket, ssl
>>> sock = socket.socket()
>>> sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_REQUIRED, ca_certs=u'ä.crt')
>>> sock.connect((None, None))
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "C:\Python27\lib\ssl.py", line 322, in connect
 self._real_connect(addr, False)
 File "C:\Python27\lib\ssl.py", line 305, in _real_connect
 self.ca_certs, self.ciphers)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0:
ordinal not in range(128)

Seems to work fine in Python 3.2+.
Two possibilities:
 1. document ca_certs is str only
 2. encode with sys.getfilesystemencoding() if unicode
Would have to be fixed in ssl.get_server_certificate too and maybe even more, I did just a quick glance.

There are other paramaters that take optional 'files'. Whatever change is made should be done uniformly for all.
'File' is unfortunately vague, as it could mean file object or file name or both. If file name, it could be str only or (for 2.7), str and unicode. I an not sure of what the 2.7 standard is, if there is one.
Allowing unicode could be seen as an enhancement, but it depends on the original intention and/or default 2.7 interpretation of 'file'.

Indeed, it would probably be a new feature to accept unicode there, and we don't add new features to 2.7.
As Hynek said, Python 3 is fine.

So are we going to add something to the docs or just close as rejected?

Honestly, I'm not sure it is worth documenting. How to use the ca_certs argument is clear when reading the examples further in the ssl doc page, and detailing the quirks of each and every argument would make the text much less readable.

I'd just add some general catch-all phrase at the top that all paths are expected to be encoded strings.

I'm closing it as won't fix. I don't think it needs to be documented, but I won't mind if it is.

Well, the Unicode HOWTO states:
When opening a file for reading or writing, you can usually just provide the Unicode string as the filename, and it will be automatically converted to the right encoding for you
This is really an unexpected behavior which could be easily missed by a test case so I would really vote for making this clear in the documentation.

For example it is broken in the well known requests library:
>>> import requests
>>> requests.get('x', cert=u'öäü.pem')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 ...
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)