[pyOpenSSL] Problem with pyOpenSSL 0.10 and OpenSSL 0.9.8m

[M.-A. Lemburg]

exarkun at twistedmatrix.com wrote:
> On 12:04 pm, mal at egenix.com wrote:
>> M.-A. Lemburg wrote:
>>> OpenSSL just released version 0.9.8m where they changed the
>>> SSL renegotiation scheme to now follow RFC 5746 instead of
>>> just disabling it completely:
>>>
>>>     http://tools.ietf.org/html/rfc5746
>>>
>>> pyOpenSSL compiles against the new version without problems,
>>> but one of the unit tests fails on Linux x64 (and perhaps
>>> other platforms as well):
>>>> python OpenSSL/test/test_ssl.py
>>> .......E....
>>> ======================================================================
>>> ERROR: test_set_default_verify_paths (__main__.ContextTests)
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>>   File "OpenSSL/test/test_ssl.py", line 253, in 
>>> test_set_default_verify_paths
>>>     clientSSL.do_handshake()
>>> Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate 
>>> verify failed')]
>>>
>>> ----------------------------------------------------------------------
>>> Ran 12 tests in 0.660s
>>>
>>> FAILED (errors=1)
>>>
>>> The test connects to https://verisign.com/
>>> I've tried a few other sites as well, but always get the same
>>> error.
>>
>> I tried the same on Linux x86 with the same results.
>>
>> I then also checked pyOpenSSL 0.9.0 with OpenSSL 0.9.8l
>> and again get the same results.
>>
>> Perhaps there's something wrong with my test setup ? I've
>> done the tests on two different machines.
> 
> This test depends on OpenSSL having been built so that it has access to 
> the platform-provided CA certificate database.  It sounds like your 
> builds weren't done this way.
> 
> I've never actually built OpenSSL this way myself, and I have very 
> little idea what is involved in doing so.  I know that Ubuntu's OpenSSL 
> builds have this enabled, but as far as I know none of the other widely 
> used builds for other platforms do (I've looked at OS X and Windows and 
> they don't, I'm not sure about other Linux distros).
> 
> Unfortunately I don't have much more info than that about the feature, 
> so I can't make any suggestions about how to check to see if this is 
> really the problem, or how to change the build in order to fix it.

Thanks for the hint. Here's the full background:

http://www.madboa.com/geek/openssl/#verify-system

Different OSes place the trusted certificate database files in
different places and non of them uses the OpenSSL default which
is /usr/local/ssl and a subdir certs/.

The only way to work around this appears to be to call
ctx.load_verify_locations() to point the context to the
right set of trusted certificates.

I believe that the test should apply such a setup for
the verisign.com certificate authority instead of
relying on a platform provided default setup, ie. use
its own certs/ subdir with the root CA certificates that
are used by verisign.com.

In any case, the above test failure is a problem with the test
setup more than anything else.

Here's a version of the test which works on OpenSUSE:

        # Arg, verisign.com doesn't speak TLSv1
        context = Context(SSLv3_METHOD)
        #context.set_default_verify_paths()
        context.load_verify_locations(None, '/etc/ssl/certs')
        context.set_verify(
            VERIFY_PEER,
            lambda conn, cert, errno, depth, preverify_ok: preverify_ok)

        client = socket()
        client.connect(('verisign.com', 443))
        clientSSL = Connection(context, client)
        clientSSL.set_connect_state()
        clientSSL.do_handshake()
        clientSSL.send('GET / HTTP/1.0\r\n\r\n')
        self.assertTrue(clientSSL.recv(1024))

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 15 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/