@Axel-Spoerl small updates:

I tried different Gemini browser, namely Sputnik (written in Swift) - works barely better than my prototype but it does work and I could verify the links - they do work, so the problem is within my code somewhere. there is a Qt5 multi browser named Kristall, written with Qt5 and long not updated at all. Porting it to Qt6 should not be much of a problem (some outdated classes, like QRegExp but not much of it), porting it to macOS is a bit more complex so I'll not attempt unless bored. BUT. They also use QSslSocket so now I'll have a read through their code and see where did I go wrong.

More updates once I do the read.

I have used QSslServer and passed the

QSslCongifuration::defaultSslConfiguration()

value to use it as the configuration data. Seems pretty easy in that respect.

The default SSL configuration consists of: no local certificate and no private key protocol SecureProtocols the system's default CA certificate list the cipher list equal to the list of the SSL libraries' supported SSL ciphers that are 128 bits or more

Another option is

QSslConfiguration::defaultDtlsConfiguration()

You have full control over certs, keys, etc. in the QSslConfiguration object. Just depends on how detailed you need to get with it. Usually in my case it's a "same host" sort of deal so I just use the default config.

@Tomaz if your issue is solved now, please don't forget to mark your post as such!

@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