@healermagnus said in QSslSocket and QTcpSocket ... how to know if the connection is incorrect: Any ideas what I'm missing? You want a delayed handshake. Ideologically it goes like this: You create the QSslSocket object, but operate it as a QTcpSocket. The server and client exchange TCP messages (as per your liking) to try and negotiate whether they should stay in plain TCP or in SSL mode. When the connection is decided to be used over SSL the client calls startClientEncryption, while the server socket calls startServerEncryption to begin the actual SSL handshake. Connecting the TCP error and sslErrors() signals is a must.

@mrjj Cheers, that worked for me :)

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.

I dont think this example uses QSslSocket at all. After some investigation I found out that client is sending some data after connecting to start handshake, but server does not response. What is really strange socket->waitForEncypted(30000) alweys returns false and never waits the time(30 sec). I've set both certificate and key so it should work. Any ideas?

That's tricky… Good catch !

@Bart_Vandewoestyne said: Could my educated guess be correct? Your guess sounds reasonable to me. Does anybody have any idea why the original author of this code decided to make a difference between linux and non-linux? If I remove the ifdef and simply use close() in all situations, things seem to work, although it seems that in this case the ClientSslSocket destructor is no longer called (and I'm not sure if this is a good thing...). Nope, sorry. Are there any comments in the code, or in the commit history? Could you ask the author directly? What would be the clean solution here? How should FooBar's destructor look like? It's hard to say without knowing how the rest of the program is designed. Maybe you can manually disconnect the socket before deleting it?

@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...

Ok guy thank you for that much replies :P! I solved the issue by myself anyway. In case sombebody has a similar problem here comes the solution: What I did wrong was that I connected a time consuming function to the UpdateClient::tcpReady() slot. In this function I did some stuff which also lead to the emission of UpdateClient::tcpReady(). This broke the QEventQueue. So to what I had to chance was to skip the direct signal slot connection an do this in the UpdateClient::tcpReady(): QTimer::singleShot(0, this, SIGNAL(updateAvailable())); No everything is working fine ;).

Hi, since I am convinced that somebody else will also have similar problems I wrote a tutorial how to create a multithreaded server: https://five-s.de/en/how-to-create-a-multithreaded-server-in-qt Best regards

@t3685 Yes I'm sure.

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

@Huragan Witam. Widzę, że nie ma zbytniego zainteresowania tym postem, ale jakoś sobie radzę. :) Doszedłem do etapu w którym mailowy serwer google (gmail) odmawia mi połączenia się ze sobą z powodu niskiego poziomu bezpieczeństwa zapewnianego przez moją aplikację. Rozwiązanie tego problemu przyszło łatwo. Zezwoliłem na łączenie się z moją skrzynką mailową mniej bezpiecznym aplikacjom. [https://support.google.com/accounts/answer/6010255]

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