Using QSslSocket with custom OpenSSL
-
I want to use QSslSocket and QSslCertificate with my latest OpenSSL build. I built OpenSSL 1.1.0 with VS2015 and added its bin directory into %PATH, also added its LIBS to my .pro file:
LIBS += -LC:/openssl_1.1.0/lib/ -llibcrypto -llibssl
When I run my application, QSslSocket::supportsSsl() returns false and QSslSocket::sslLibraryBuildVersionString() returns OpenSSL 1.0.2g 1 Mar 2016, even though I built OpenSSL 1.1.0. Also I get error messages like this:
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
What is the problem? How can I use my built OpenSSL libraries and binaries?
P.S. I use Windows 10, Qt 5.7, OpenSSL 1.1.0, Visual Studio 2015 Enterprise.
Thank you
-
@MChelik
Qt loads the OpenSSL libs on demand. Where the DLL name is hardcoded and the methods are resolved "manually".
So linking against OpenSSL wont make any difference. -
@raven-worx So why QSslSocket::supportsSsl() returns false? Lets forget about my custom OpenSSL.
-
@MChelik
on windows they are called ssleay32.dll and libeay32.dll -
@raven-worx Since QSslSocket::sslLibraryBuildVersionString() returns "OpenSSL 1.0.2g 1 Mar 2016", I downloaded OpenSSL_1.0.2g source code and compiled it, but inside bin directory there was only openssl.exe. So I copied ssleay32.dll and libeay32.dll from C:\Qt\Tools\QtCreator\bin to C:\Windows. But still I get same error, nothing changed.
What should I do use QSslSocket? I'm really confused. I searched a lot but nothing helped. -
Hi and welcome to devnet,
Don't copy .dlls like that in the Windows folder, that's very bad practice.
If Qt shows you a different version of OpenSSL, it likely means that you have an application that also provides these files and can be found before yours.
I've successfully used the prebuilt packages from Shining Lights Production.
Hope it helps
-
@MChelik said in Using QSslSocket with custom OpenSSL:
So I copied ssleay32.dll and libeay32.dll from C:\Qt\Tools\QtCreator\bin to C:\Windows
don't do that, as @SGaist said. Copy them next to your application exe instead.
-
Thank you SGaist. Copying next to application executable didn't help either.
Gentlemen, let's forget my OpenSSL; forget everything. Just assume that I want to use QSslSocket and QSslCertificate. What should I do? Should I compile Qt myself? Should I install OpenSSL? What should I do exactly? Qt documents doesn't say any specific thing about this. Documents say only how to use mentioned two classes.
Thank you -
Hi, just a quick note on OpenSSL with Qt, I think because you're building a 64-bit Qt app that's why you're having problems. Because those 2 DLLs s stored in C:\Qt\Tools\QtCreator\bin are built with MSVC2013 32-bit compiler (same as for Qt Creator itself) so they are not kosher for 64-bit :-(
-
To add to @hskoglund, the prebuilt packages I've mentioned earlier also provide "OpenSSL-Win64" which are pre-built for 64bit development.
-
@hskoglund That was my problem! I didn't pay attention to that. But I a have a question: The only libeay32.dll and ssleay32.dll files that are in my %PATH% is C:\Win64-OpenSSL\bin directory. So why my application only works when mentioned DLLs are beside my application (doesn't work when are in %PATH)?
-
Are you sure you don't have any other application that has these libraries and that can be found in your PATH environment variable ?
-
How did you modify PATH ? In your Windows settings or in Qt Creator ?
-
Hi, also, they could be loaded via some other means than their directories being listed in %PATH%, either that some other dll that your .exe loads explicitly pulls in the bad (i.e. 32-bit) ones, or perhaps they're hiding in c:\windows or c:\windows\system32.
To debug this. you could try download Dependency Walker and load your app into it. Then start profiling with F7, that'll get you a trace of all the dlls loaded.
-
This post is deleted!