I'm trying to run a simple client/server to implement a communication using QSslSocket. I work on Windows (unfortunately) and I use QtCreator for more convenience.
When I try, from the client side, to connect to the server using MyQSslSocket->connectToHostEncrypted(ip, port), I get the following message:
qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed
When I print the raised error, I get the following one:
QAbstractSocket::SocketError(20)
In the documentation we can find that this error code corresponds to QAbstractSocket::SslInternalError whose the description is:
"The SSL library being used reported an internal error. This is probably the result of a bad installation or misconfiguration of the library."
After some investigations I found that Qt does not provide OpenSSL by itself so I installed it (the binaries, for both 32 and 64 bits versions to be sure) from here https://slproweb.com/products/Win32OpenSSL.html.
During the installation, the dll was copied to C:\Windows\System32 (for the 64 bits). Then I checked that the PATH environment variable does well contain this folder.
At this point I tried again, but I still had the same problem, as if the OpenSSL installation was still not found.
When I print the output of the following calls (in the main function of my client):
qDebug() << QSslSocket::supportsSsl();
qDebug() << QSslSocket::sslLibraryVersionString();
I get the following outputs:
false""
My question is, how to make QSslSocket::supportsSsl() return true ?
If anyone could teach me what I missed, what I am doing wrong and tell me what I should do to be able to make this SSL connection run properly, I would be very grateful.
Fareanor.
PS: Sorry for the long question but I think it is important to clearly expose the problem and the context to help you to easily understand the problem and give me more relevant answers.
Ok,
Thanks to #AlienPenguin and #Macias advices, it was that my version of OpenSSL was too recent.
Finally I have installed the closest available version of the one used for the Qt build (which does make sense, I should have thought of it) which can be found by running the following call:
qDebug() << QSslSocket::sslLibraryBuildVersionString();
Problem solved.
Thanks again.
Related
I am writing a c++ grpc based service. As recommended here, I installed grpc in my local directpry. I am using linux ubuntu 22.04.
Now, at he begginig of a service call implementation, i have these lines of code:
google::protobuf::Arena arena;
ResponseStatus * response_status =
google::protobuf::Arena::CreateMessage<ResponseStatus>(&arena);
response->set_allocated_status(response_status);
When I invoke the service, from a ruby client, the last line causes an exception with the following error message
[libprotobuf FATAL /home/lrleon/grpc/third_party/protobuf/src/google/protobuf/generated_message_util.cc:764] CHECK failed: (submessage_arena) == (nullptr):
I'll be honest: I do not have an good idea about why this problem could be happening. My best hypothesis is that somewhere a different version of the required grpc/protobuf libraries is intervening. I do not believe it because I am almost sure I am not using any system library related to grpc, but eventually another app could have installed some library.
I spent a full day searching in forums without getting a some related post that could help me solve mine.
That said, I kindly ask if some expert in grpc could help me.
Thanls in advance
I am developing a C++ HTTP/HTTPS client application inside environment of CentOS/Redhat 7.7, which the OS comes with OpenSSL 1.0.2k-fips. But I need at least OpenSSL 1.1.1 for my application. So I compiled OpenSSL 1.1.1f from source.
My compilation configuration.
./Configure linux-x86_64 enable-ec_nistp_64_gcc_128 -Wl,-rpath=/usr/local/lib64 --prefix=/usr/local --openssldir=/usr/local
The problem starts here.
Any requests I make with the new OpenSSL results with Verify return code: 20 (unable to get local issuer certificate). I spent some time switching HTTP clients for C++, which was a very tiring process, only to find out that the issue is with OpenSSL itself.
After a long research, the HTTP client I currently use, shared a ca-bundle inside it's repo. Including it into my project resolved the issue.
https://github.com/yhirose/cpp-httplib/blob/master/example/ca-bundle.crt
cli.set_ca_cert_path(./ca-bundle.crt);
Or with command line,
openssl s_client -connect example.com:443 -CAfile ./ca-bundle.crt
This all seems absurd, I never had to do anything like this before in my experience with developing HTTP clients. Therefore my questions:
Is this a problem with CentOS 7 ?
Did I make a mistake while compiling OpenSSL ? (Followed)
Note: Using cli.set_ca_cert_path("/etc/ssl/certs/ca-bundle.crt"); also works (took me a long time to realize), but I never had to do this manually before, hence forgive my ignorance.
Thanks for your time.
Edit: With the help of some code,
const char* dir = getenv(X509_get_default_cert_dir_env());
if (!dir)
dir = X509_get_default_cert_dir();
cout << dir << endl;
It would seem dir is /usr/local/certs which does not exist. But I also tried this with the default installed OpenSSL inside the OS. Which I would guess should point to the real certificates ?
Edit2: Using /etc/pki/tls/cert.pem also works.
I have a very simple MongoDB application that connects to a MongoDB database and works fine.
I've then added the connectivity calls to a large, complex, legacy application and when I call:
mongocxx::instance (i.e. the first MongoDB library call)
I get the following response:
2018/08/16 10:20:59.0499: [16856]: ERROR: mongoc: Failed to initialize OpenSSL.
It appears that the low-level call to SSL_CTX_new within the MongoDB C library is returning a null pointer.
I'm not too sure why this is happening. I've even gone so far as recompiling and linking my simple MongoDB app against all of the libraries that the large legacy app uses (calls to ldd are now identical) but the simple app is still working fine.
This is using the following MongoDB drivers:
mongo-c-driver-1.11.0
mongo-cxx-driver-r3.3.0
Compiled and run on RHEL7 box (7.4) using OpenSSL 1.1.0.
Any suggestions?
I was just in trouble with the same error.
It solved it by changing the option of cmake.
In this way, setting an option, it will work.
cmake -DENABLE_SSL=OFF ..
In the following method, OpenSSL initialization error occurs.
cmake -DENABLE_AUTOMATIC_INIT_AND_CLEANUP = NO
I'd like to know how to prevent initialization errors with "ENABLE_AUTOMATIC_INIT_AND_CLEANUP".
https://github.com/mongodb/mongo-c-driver/blob/r1.10/NEWS#L935
https://github.com/mongodb/mongo-c-driver/blob/2edd3b2a91171a5da88e9282ffb6a3efbbc2bd91/src/libmongoc/CMakeLists.txt#L225
This problem was solved by make of OpenSSL.
Why 'apt-get install openssl' did not install last version of OpenSSL?
I used the following.
openssl-1.1.0f
mongo-c-driver-1.10.1
mongo-cxx-driver-r3.3.0
I have a problem. I've made a Qt application which is connecting to a https site.
On my working machine, everything works fine. When I try to test my application on a clean Windows 7 machine, I observed the following issue:
After I have installed a fresh Win7 machine (installed all updates), after starting my application, I get a SSL Handshake failed error, SIGNAL(sslErrors(QNetworkReply*,QList)) is emitted with two empty error strings and error = QSslError::NoError.
I was really searching the whole day why this happens, also could reproduce it with examples\network\securesocketclient\release\securesocketclient and domain "google.com".
Now, I found out, that once I have started the internet explorer accessing https://www.google.com, my application is also working as expected and no further handshake errors are coming.
BTW, it does not matter which site you are accessing - this is not related to google.com.
Can someone explain to me why this happens? Is it a bug in OpenSSL, or Qt, or both?
UPDATE
I found a way to live with that issue for myself, implementing the following ignore logic:
QSslError ignoreNOErrors(QSslError::NoError);
foreach(QSslError error, errors)
if(error.error() != QSslError::NoError)
qDebug() << error.errorString();
QList<QSslError> expectedSslErrors;
expectedSslErrors.append(ignoreNOErrors);
reply->ignoreSslErrors(expectedSslErrors);
Thanks
You could ignore certificate verify using QSslConfiguration::setPeerVerifyMode():
QSslConfiguration conf = request.sslConfiguration();
conf.setPeerVerifyMode(QSslSocket::VerifyNone);
request.setSslConfiguration(conf);
I was facing the same issue on Mac with Qt 5.5 and 5.6. When I upgraded to 5.7 it is solved. Hope it may help if you are still facing this issue.
Have a look at this Qt bug
[This is padding for SO :D]
I have a C++ client that connects to servers using libcurl on FreeBSD. The system administrators recently update the FreeBSD image and install ports. The system went from cURL version 7.24.0_2 to cURL version 7.31.0. (File name went from libcurl.so.6 to lib curl.so.7 for what that's worth.)
I recompiled my program to link against the new library.
Now I am getting return value 3 (CURLE_URL_MALFORMAT) from my call to curl_easy_perform(3), and the error message string returned is " malformed".
However, nothing else has changed. The URL is unchanged, and has been verified as correct.
Stranger still, the command line "curl" program works fine; isn't it using the same library?!
I've spent a couple hours reading the release notes for libcurl but couldn't spot anything that suggested a reason as to why this should now fail.
Any suggestions?
Turns out the sysadmins built cURL wrong. A new install and it works.