Windows and OpenSSL Woes

[webzoid]

I know that this has been covered many times, however, I'm literally pulling my hair out trying to get this to work...

So I'm trying to use the QNetworkReply to pull a file from a https URL.

The problem, as others have mentioned, is at some point, I get the following errors:

qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_CTX_new
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init
qt.network.ssl: QSslSocket: cannot call unresolved function ERR_get_error
qt.network.ssl: QSslSocket: cannot call unresolved function ERR_get_error

So I've added the following to my code, to check the version of OpenSSL used when Qt was compiled:

qDebug() << QSslSocket::sslLibraryBuildVersionString();       // Returns "OpenSSL 1.0.2j 26 Sep 2016"
qDebug() << QSslSocket::sslLibraryVersionString();            // Returns ""

I already have installed the most recent GnuWin32 OpenSSL libraries (0.9.8h) however other more recent OpenSSL versions do not work.

I've tried copying the libeay32.dll and libssl32.dll files to the System32, SysWOW64, Qt 5.10.1 MSVC2015 bin and both debug and release directories but nothing works. I've tried adding the GnuWin32 OpenSSL directory to the path, rebooted but still no joy.

Having download the pre-compiled binaries for version 1.0.2j for MSVC2015 32-bit (the Qt kit I'm using), these still don't work.

How and where is Qt attempting to resolve the OpenSSL libraries? This seems like an impossible task to get this working.

I've tried ALL solutions from many many posts found on Google yet all yield the same results. I've checked using depends that all versions of the OpenSSL libs contain the exported functions mentioned in the error - they do, the export tables are fine.

Someone, please help!

UPDATE

I've downloaded the OpenSSL 1.0.2j sources, ActivePerl and NASM and compiled the OpenSSL binaries into C:\Program Files (x86)\OpenSSL. I've added this folder to the path but still no joy. I've copied the binaries to the Qt 5.10.1 bin folder, still no joy. Copied them to my debug and release folders, still no joy.

[SGaist]

Hi,

First thing: don't copy the OpenSSL libraries in the Windows system libraries (that's valid for any application dependency in fact)

Are you using a pre-built version of Qt ?

[webzoid]

I removed them from the Windows system folder once I realised it made not a bit of difference.

Yes, using pre-built 5.10.1 for MSVC2015 32-bit.

Probably should update to the latest release.

[SGaist]

Did you check that the OpenSSL libraries had all their dependencies also available ?

[webzoid]

I did indeed.

There is an ‘OpenSSL.exe’ which I can run and call various OpenSSL functions from the libraries - this works fine.

[SGaist]

What did you use for that ?

Did you do it in the folder where start your application from ?

[webzoid]

To test that the libraries worked, that there was nothing “missing” from the OpenSSL installation.

I ran the executable from where it lives - in the same directory as the libraries.

To confirm, as it stands at the moment, the only link Qt has to the OpenSSL libs is via the PATH environment variable - I removed all duplicate copies of the libraries copied to various directories when it made no difference.

PATH contains C:/Program Files (x86)/OpenSSL/bin

[SGaist]

Where did you modify the PATH environment variable ?

And just in case, do you have other copies of OpenSSL on your system (could be coming from other software or depending on your computer builder, it could be pre-installed for one of their tools).

[webzoid]

@SGaist I modified the PATH in the usual way:

System Properties >> Advanced >> Environment Variables >> System Variables >> Path

There are no other versions of OpenSSL installed anywhere on my machine. Certainly nothing else exists within PATH that indicates any OpenSSL binaries are present (I've verified all directories in the path contain no OpenSSL binaries).

[webzoid]

Ok, so a bit more digging...

The source file qsslsocket_openssl_symbols.cpp has a function called loadOpenSslWin32 in which it attempts to load all of the exported symbols from a required version of the OpenSSL libs:

#if QT_CONFIG(opensslv11)
    // With OpenSSL 1.1 the names have changed to libssl-1_1(-x64) and libcrypto-1_1(-x64), for builds using
    // MSVC and GCC, (-x64 suffix for 64-bit builds).

#ifdef Q_PROCESSOR_X86_64
#define QT_SSL_SUFFIX "-x64"
#else // !Q_PROCESSOFR_X86_64
#define QT_SSL_SUFFIX
#endif // !Q_PROCESSOR_x86_64

    tryToLoadOpenSslWin32Library(QLatin1String("libssl-1_1" QT_SSL_SUFFIX),
                                 QLatin1String("libcrypto-1_1" QT_SSL_SUFFIX), pair);

#undef QT_SSL_SUFFIX

#else // QT_CONFIG(opensslv11)

    // When OpenSSL is built using MSVC then the libraries are named 'ssleay32.dll' and 'libeay32'dll'.
    // When OpenSSL is built using GCC then different library names are used (depending on the OpenSSL version)
    // The oldest version of a GCC-based OpenSSL which can be detected by the code below is 0.9.8g (released in 2007)
    if (!tryToLoadOpenSslWin32Library(QLatin1String("ssleay32"), QLatin1String("libeay32"), pair)) {
        if (!tryToLoadOpenSslWin32Library(QLatin1String("libssl-10"), QLatin1String("libcrypto-10"), pair)) {
            if (!tryToLoadOpenSslWin32Library(QLatin1String("libssl-8"), QLatin1String("libcrypto-8"), pair)) {
                tryToLoadOpenSslWin32Library(QLatin1String("libssl-7"), QLatin1String("libcrypto-7"), pair);
            }
        }
    }
#endif // !QT_CONFIG(opensslv11)

So, I guess my question is this - given that the version of OpenSSL Qt was built with (1.0.2j 26 Sep 2016), can I safely assume that the file names required are ssleay32 and libeay32.

A bit more digging through the Qt source tells me that Qt is looking in the PATH for libraries ending in dll (not lib), system directory AND also the application executable path.

The version of OpenSSL I am using at present is OpenSSL 1.1.1-pre8-dev xx XXX xxxx (don't know why the last fields are missing) so my conclusion now is that I need to use an older version of OpenSSL which uses the old file naming scheme.

I'll give that a go (again)!

[Pablo J. Rogina]

@webzoid said in Windows and OpenSSL Woes:

ssleay32 and libeay32.

Usually placing files ssleay32.dll and libeay32.dll in same folder as your application executable makes the trick.

[SGaist]

By default Qt is build to dlopen the OpenSSL dlls. This allows Qt to be build to support cryptographie while letting the developer handle all related paperwork for its application to be distributed (different countries have different rules regarding cryptographically enabled software).