I'm using cURL 7.42.1 and MinGW. I'm having problems compiling libcurl with ssl support (for HTTPS). Ive tried defining USE_OPENSSL on lib\curl_setup.h but it still didn't work.
Ive been trying to find a solution to this for hours but i couldn't find one.
You must build libcurl with SSL support enabled, adding a define to curl_setup.h won't have the desired effect.
i.e.:
./configure --with-winssl
Then init curl the following way in your application:
if (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)
/* handle error */
Related
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'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.
Trying to make a whois tcp lookup that directly queries verisign via port 43. Got it to work in command line + visual studio community 2017.
When I try to use em++ to compile it, I get an error.
C:\Users\Samuel Walker\source\repos\Barebones_Client\Barebones_Client>em++ -O3 --emrun -s WASM=1 -o main.html main.cpp
main.cpp:3:10: fatal error: 'WS2tcpip.h' file not found
#include <WS2tcpip.h>
^~~~~~~~~~~~
1 error generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
I'm using WS2tcpip.h for the script. It's essential, but yeah still entirely new to C++ and following guides and snippets online. Is this a matter of somehow telling enscripten to know where windows header files are or am I completely off?
You cannot. WS2tcpip.h is part of the Windows API, which is not available in the browser.
You can make HTTP requests from JavaScript, but there are no generic sockets to be able to make requests using the WHOIS protocol. You will need to contact a web server that offers an API for making WHOIS requests. Also see this question and its answers:
Whois with JavaScript
I intend to do https requests with libcurl and openssl with a C++ program.
I initialized libcurl with curl_global_init(CURL_GLOBAL_ALL) as described in the documentation. Then I use an curl_easy handle that I initialize, populate with headers and a body, and send everything out to ´https://example.com:443/foo´. It works for non-https connections.
Looking around I find that there may be other libraries that are already getting an SSL context which is what causes libcurl to fail in doing precisely that. I get the following error message:
curl_easy_perform failed: Out of memory
In my case I am using libmicrohttpd which I initialize with
mhdDaemon = MHD_start_daemon(MHD_USE_THREAD_PER_CONNECTION | MHD_USE_SSL,
htons(port),
NULL,
NULL,
connectionTreat, NULL,
MHD_OPTION_HTTPS_MEM_KEY, httpsKey,
MHD_OPTION_HTTPS_MEM_CERT, httpsCertificate,
MHD_OPTION_CONNECTION_MEMORY_LIMIT, memoryLimit,
MHD_OPTION_SOCK_ADDR, (struct sockaddr*) &sad,
MHD_OPTION_NOTIFY_COMPLETED, requestCompleted, NULL,
MHD_OPTION_END);
So I am indeed using openSSL somewhere else. The thing is, if I take out the MHD_USE_SSL part it does not fix the problem.
This is the list of libraries that are linked to the application (I'm using cmake):
-lmicrohttpd
-lmongoclient
-lboost_thread
-lboost_filesystem
-lboost_system
-lpthread
Is there any of the others that could be loading SSL? Is microhttpd loading it anyways even if I comment out the MHD_USE_SSL flag (plus all other related flags)? Could there be any other reason for this error?
I'm not aware of any problem in libcurl that would cause this error code to get returned if indeed a memory allocation function doesn't fail. Using OpenSSL in multiple modules does not cause such a failure. (I am the lead developer of libcurl.)
So, run your app with VERBOSE set to libcurl, or even strace to see which syscall that fails and it should give you more clues.
As the descibed in this answer, you might need to disable SSLv3 if you are on Ubuntu 16.04 like so
curl_easy_setopt(curl_, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2));
It was disabled on Ubuntu 16.04 for security reasons, see more here.
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.