Ok, thanks for the reply. It pointed me in the correct direction and after many failures I finally figured it out.
I guess you only learn when you need to dig deep.

The only thing I had to do was install the correct version of openSSL. Since it is my first time I had no idea what the letter actually meant, I picked the first build, which was version g, I had to install version n.

For all future wanderers, the only thing you need to do to make the client work is one of the two options:

Just copy ssleay32.dll and libeay32.dll to working directory OR Install the latest version and set PATH to the folder where the two dlls are located.

After that you can use QWebSocket without even knowing SSL exists. Just call:

QWebSocket socket; socket.open( QUrl("someaddress") );

And, when the dlls are found the warnings disappear.

That's it.

For anyone finding this thread via Google OpenSSL actually has a somewhat detailed description about the workaround: https://wiki.openssl.org/index.php/Android#Wrapper_Shared_Objects

Hi and welcome to devnet,

Understand the licensing constraints of using a static build of Qt and be ready to abide by them Install an up to date version of OpenSSL (the system version is just too old) Install MariaDB Download Qt's source Read documentation about static building Pass the -openssl-linked as parameter to configure Pass -sql-mysql as parameter to configure Pass the -I and -L parameters as needed in order for Qt to find the MariaDB and OpenSSL libraries. Call make -jX where X is the number of cores of your machine multiplied by 2 plus 1. Go grab <insert favorite beverage> and look at your processors heating up Call make install Enjoy development

Hi, and welcome to the Qt Dev Net!

@NulledPointer said in Force system QT libraries to use openssl libraries shipped with the application:

Can I force QT libraries to somehow use openssl shipped along with my application?

May I ask why you want to do that?

OpenSSL is a security library. Old versions can contain known, exploitable security holes, so it sounds like a good idea to use the latest version whenever it's available. This way, when the end user upgrades OpenSSL on their system, your Qt application will automatically pick up the new OpenSSL.

@kfrosty Thank you! Did work for me too! :)

The problem with such an example is that it doesn't allow to replicate your problem correctly and triggers others that are not related to yours thus it's not possible to offer sensible help.

There's an initial release of the VS-AddIn here

Sure there is, just build qtbase statically then build only the modules you want by hand or exclude all the modules you don't want when calling configure.

@Chris-Kawa Sometimes you forget to update deploy dlls, in that case runtime vs compiletime versions in "about window" would be helpful.
Even if you use auto windeployqt command, you'll still need to copy other dlls (OpenSSL, etc) by hand, there you'll forget.

IIRC there was a renaming of the libraries of OpenSSL so you'll have to double check.

https://www.openssl.org/policies/releasestrat.html
"Minor releases that change the last digit, e.g. 1.0.1 vs. 1.0.2, can and are likely to contain new features, but in a way that does not break binary compatibility."

So I don't believe what "1.0.2d vs 1.0.2c" itself causes a problem.

@Ni.Sumi
I mean the compiler invocation, not the error (I saw the error in your first post). It should look something like this:

g++ -c -pipe -g -std=gnu++0x -Wall -W -D_REENTRANT -fPIC -DQT_QML_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I../../myproject -I. -I../../../qt/qt-5.6/qtbase/include -I../../../qt/qt-5.6/qtbase/include/QtWidgets -I../../../qt/qt-5.6/qtbase/include/QtGui -I../../../qt/qt-5.6/qtbase/include/QtCore -I. -I../../../qt/qt-5.6/qtbase/mkspecs/linux-g++ -o somesource.o ../../myproject/somesource.cpp

/ I've taken it from g++, but you get the idea - the compile line, the call that compiles the offending source. /

Kind regards.

I am not involved in the encoding part. I did not write one single code for encoding. I get 3rd party XML files and i just want to decode them. To be very clear on this: I can't change the encoding, it is not my software, i do not develop it and i never had. I just got the source code for the de and encrypt part, so i may be able to import the XML files. I never wrote a single line VB code in my life. To be honest, i don't believe security is the issue, the developer just don't want anyone to be able to open it. That may not be an excuse for bad code but so far, i can't change it, i'm just happy now to be able to decode.

i still think there is simpler explanation for your issue.
The linker can't even find the lib file specified.
Are you really sure that the libs are in "C:\source\icu2\lib"? And not in a release/debug subfolder, etc.?

@mrjj no misunderstanding. It was the latter and both of your responses were equally helpful.

@Leonardo said:

Linkage is done from right to left. Maybe you're adding your static library after openssl. Put it before.
Yes, you're right. Moving static library after openssl solved my issue.

@Dooms said:

sslConfiguration

You don't seem to have actually associated the sslConfiguration object with the QSslSocket object.

You can set the cert/key files directly on the QSslSocket if that helps simplify your code for testing...

@SGaist thanks for reply) I understand that I need that for deployment on device but I am building just qt not an app. So i thought it might be unnecessary for building Qt itself. Cause when i am downloading qt for Ios i don't need to have that account. But i need it to build qt that's strange for me. I have ready code to port to ios so openssl is needed

@koahnig I am using 2.0.1

Thanks, -no-openssl -securetransport works. Now I can use Mac OS X native secure transport instead of OpenSSL.

For the people googleing this issue. There is documentation abut this in
qtbase/src/network/ssl/ssl.pri:

Add optional SSL libs # Static linking of OpenSSL with msvc: # - Binaries http://slproweb.com/products/Win32OpenSSL.html # - also needs -lUser32 -lAdvapi32 -lGdi32 -lCrypt32 # - libs in <OPENSSL_DIR>\lib\VC\static # - configure: -openssl -openssl-linked -I <OPENSSL_DIR>\include -L <OPENSSL_DIR>\lib\VC\static OPENSSL_LIBS="-lUser32 -lAdvapi32 -lGdi32" OPENSSL_LIBS_DEBUG="-lssleay32MDd -llibeay32MDd" OPENSSL_LIBS_RELEASE="-lssleay32MD -llibeay32MD"

Just to be sure: it fails to build on Windows even if you use one of the official package ?

@mcosta Thanks mcosta

Yes, indeed I can show website over https with WebEngine, even though it still show those warning messages. As documented here, Web Kit will be deprecated in Qt version 5.5+, so I'll switch to use WebEngine then.

For those who feel annoyed with the warning messages, you could suppress them by calling following method in your main()

QLoggingCategory::setFilterRules("qt.network.ssl.w arning=false");

or by setting environment variable

QT_LOGGING_RULES=qt.network.ssl.warning=false

Do you have the simulator installed ?

It's because Qt (or rather QSslSocket) closes the connection immediately after emitting the error() signal.

@Jeff-Andle
A list of vulnerabilities can be found here . From the list i can take that it's one MITM exploit and everything else just DOS. Also google just warns us about a possible problem, it doesn't remove nor unpublish the app. Afaik heartbleed occurs from OpenSSL version 1.0.1 to 1.0.1f until it's fix in version 1.0.1g. So version 1.0.0e shouldn't have a problem with heartbleed. Although i would like to update somehow anyway...

I was able to upgrade the version of OpenSSL by using the Qt MaintenanceTool.exe and updating everything to the latest. Have yet to submit to Google, but I think it may be the solution.

Oh, I guess when not using -openssl-linked, it will not matter as the .lib files will not be used.
I'm still interested in what to do if I'd actually want to use -openssl-linked.

Try to install the latest OpenSSL libraries for Windows. You can find it here : https://www.openssl.org/related/binaries.html