Windows and OpenSSL Woes
-
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 ahttps
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
andlibssl32.dll
files to theSystem32
,SysWOW64
, Qt 5.10.1 MSVC2015bin
and bothdebug
andrelease
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.1bin
folder, still no joy. Copied them to mydebug
andrelease
folders, still no joy. -
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 ?
-
Did you check that the OpenSSL libraries had all their dependencies also available ?
-
What did you use for that ?
Did you do it in the folder where start your application from ?
-
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
-
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).
-
@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). -
Ok, so a bit more digging...
The source file
qsslsocket_openssl_symbols.cpp
has a function calledloadOpenSslWin32
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
andlibeay32
.A bit more digging through the Qt source tells me that Qt is looking in the
PATH
for libraries ending indll
(notlib
), 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)!
-
@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.
-
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).