QSslSocket Behaviour Linux vs macOS (possibly LibreSSL incompatibilities?)
-
In the absolute, having also a test server would be nice (doesn't need to be C++ for that part) as it would allow to be sure that a failing connection can properly be made.
-
In the absolute, having also a test server would be nice (doesn't need to be C++ for that part) as it would allow to be sure that a failing connection can properly be made.
@SGaist I understand; still its kind of difficult to just give out the sources since some of the tech used there (unrelated to connecting) is under heavy confidentiality requirements.
That said, a server you could connect to is available via DynDNS (edit: tested - working)
-
No worries, that's not what I was asking you to do at all !
Just some dummy test server using the custom certificate so that the communication can be tested/established with the test client.
-
No worries, that's not what I was asking you to do at all !
Just some dummy test server using the custom certificate so that the communication can be tested/established with the test client.
@SGaist Here we go: https://github.com/markusmeyerhofer/SimpleServer
Just a heads-up: this is a quickly distilled ssl server; it should work but its certainly not tested exhaustively.
The client: https://github.com/markusmeyerhofer/QtSSLClient
I created a small project creating certs and keys (again, using the sample provided in the mentioned thread above) and writing those to disk.
I imported a key generated this way (recall: this key is accepted as valid by QSslKey) into a resource file and load that file in my SSL client - where the exact same key is rejected ("isNull").Visual inspection (qDebugging out the loaded file) suggests an actually valid key file. As it stands it looks like something happens during loading the key file. Not sure what I'm doing wrong...
(Hint: the respective code segment is in "citcpconnection.cpp" lines 27ff, see Github Repo QtSSLClient as given above) -
After some testing, the certificate itself is good. What poses problem currently is the key. Poking at the sources and searching a bit, the key you are generating is a PKCS8 type of key which doesn't seem to be handled currently. PKCS1 keys on the other should be good.
I didn't had time to go through OpenSSL to find how to generate such a key from the API however on the command line it seems to be as simple as:
openssl rsa -in server.key -out server_new.key.Hope it helps.
-
After some testing, the certificate itself is good. What poses problem currently is the key. Poking at the sources and searching a bit, the key you are generating is a PKCS8 type of key which doesn't seem to be handled currently. PKCS1 keys on the other should be good.
I didn't had time to go through OpenSSL to find how to generate such a key from the API however on the command line it seems to be as simple as:
openssl rsa -in server.key -out server_new.key.Hope it helps.
@SGaist Thx for the heads - up. What still puzzles me is: how is it that the key generated in code (its in the client code posted) is accepted when fed into QSslKey directly; when storing the key as is and subsequently loading from file it isn't.
Anyway, its kinda tedious - there are so many formats and how tos out there I kinda lost oversight. What I need is basically:
1 - A certificate (self-signed) acting as CA certificate.
2 - A server and a client key + certs, signed by the CA cert as created in 1. I did that, but, as you know, the key isn't accepted.There are other issues I don't quite understand: e.g. the key, even though set in the client, does not seem to appear on the server; meaning it isn't used. Similarly, setting the peer host name on the client, getting peerHostName on the server happens to be empty. Not sure why...
The connection still is encrypted, but host identification is defunct as of now, opening a hole
-
Looking for something else, I stumble on this bug of Curl which I wonder if it relates to the problem at end.
-
Looking for something else, I stumble on this bug of Curl which I wonder if it relates to the problem at end.
@SGaist said in QSslSocket Behaviour Linux vs macOS (possibly LibreSSL incompatibilities?):
bug of Curl
I doubt it: the bug seems to address Yosemite; my issues are for one: on High Sierra and for two: consistent over various platforms (OpenSuSE, Ubuntu; Mac).
Besides - why curl? I am not knowingly using curl for that project. Is it somehow used by Qt under the hood?
-
@SGaist said in QSslSocket Behaviour Linux vs macOS (possibly LibreSSL incompatibilities?):
bug of Curl
I doubt it: the bug seems to address Yosemite; my issues are for one: on High Sierra and for two: consistent over various platforms (OpenSuSE, Ubuntu; Mac).
Besides - why curl? I am not knowingly using curl for that project. Is it somehow used by Qt under the hood?
Hello.. as a follow up: I am not aware of the changes that took place under the hood in Qt 5.12.
However, the issues as described apparently are fixed now; i.e. I am now using Qt 5.12.0 as provided/updated using the Qt Maintenance Tool.
In more detail: I had to use the custom compiled Qt 5.10.0 in order to be able to connect to my QSsl - based development server under macOS.
With the latest update to Qt 5.12.0 everything works as intended out of the box, no custom Qt/SSL compilation required any more.Thx for fixing this!
-
Glad it's working now and thanks for the feedback !
Additonal note, I never wrote that this was a curl problem or bug that was affecting your application. Only that the bug report I found could give some additonal clues to look into to fix your problem.
-
Glad it's working now and thanks for the feedback !
Additonal note, I never wrote that this was a curl problem or bug that was affecting your application. Only that the bug report I found could give some additonal clues to look into to fix your problem.
@SGaist Actually the post above may have been a bit premature. Not sure what is going on: I updated 2 machines to Qt 5.12.0.
On my workstation, it is working as intended and described in the previous post.
Since I assumed the issues have been fixed I also updated my Macbook only to find out the failed handshake still occurs.
Currently I am in the process of investigating what is going on - mentioned computers installations are very similar. All I know for now is that the handshake failures occur only on one computer with standard Qt installation.
I suspect the cause is somehow tied to libssl.a/libcrypto.a, perhaps different ssl version or something like that.I'll keep you advised if I find out what's going on
-
The one problem I can see is that OpenSSL is not used on macOS since a few Qt versions. Qt use the SecureTransport framework from macOS. You can still use OpenSSL though but you have to build Qt yourself for that as well as get a recent version of OpenSSL.
-
The one problem I can see is that OpenSSL is not used on macOS since a few Qt versions. Qt use the SecureTransport framework from macOS. You can still use OpenSSL though but you have to build Qt yourself for that as well as get a recent version of OpenSSL.
@SGaist I know - I did compile Qt with OpenSSL 1.0.2o a couple of months ago (Qt 5.10.0).
Unfortunately later versions Qt failed to compile using this config - never figured out why; for the lack of time I just went ahead using mentioned custom compiled version.Yesterday I randomly checked if my server compiles/works using 5.12.0 - and to my surprise it did (on my workstation).
It still doesn't on the Macbook what puzzles me...otool -L indicates everything is similar. The binary compiled on the workstation also does not work on the notebook - so clearly some dynamically linked library causing this. If only I knew which one
-
Any difference of macOS versions ?
Any hint from the logs on the system ?
Just in case, IIRC, since 5.10 Qt supports also OpenSSL 1.1
-
Any difference of macOS versions ?
Any hint from the logs on the system ?
Just in case, IIRC, since 5.10 Qt supports also OpenSSL 1.1
-
OpenSSL 1.1 requires a different backend. The 1.1 release broke API and ABI compatibility with the 1.0 release, hence you have to do a specific build of Qt or any library/application using OpenSSL.
-
OpenSSL 1.1 requires a different backend. The 1.1 release broke API and ABI compatibility with the 1.0 release, hence you have to do a specific build of Qt or any library/application using OpenSSL.
@SGaist I did a fresh macOS install using a VM and can confirm the issue is resolved in stock macOS High Sierra using XCode 9.4.1, Command Line Tools 10.1 for High Sierra and standard Qt 5.12.0 installation.
Guess I have to find some path/ssl lib or similar getting in the way on my Macbook, but this should not be any of your concern.
Again, thanks for support.
Issue solved.
-
You're welcome !
Then please mark the thread as solved using the "Topic Tools" button so other forum users may know a solution has been found :)
-
You're welcome !
Then please mark the thread as solved using the "Topic Tools" button so other forum users may know a solution has been found :)
-
Software mysteries... You may have gremlins playing with your machine ;-)
