fphttpclient: Connect to URL failed.

[chris_laz]

Just a bump for this thread, I encountered the same problem on a Windows 10 PC, and fixed it.
An application which worked on other PCs failed to establish an HTTPS connection on this one PC.

My diagnostic text from TRon's diagnostic looked very similar to the OP's:

Load OK, missing functions:
OPENSSL_init_ssl (handled in unit)
TLSv1_1_method
TLSv1_2_method
TLS_method
OPENSSL_init_crypto (handled in unit)
OPENSSL_INIT_new (handled in unit)
OPENSSL_INIT_free (handled in unit)
OPENSSL_INIT_set_config_appname (handled in unit)
OpenSSL_version (handled in unit)
EVP_MD_CTX_new
EVP_MD_CTX_free
OpenSSL_add_all_algorithms (handled in unit)
EVP_CIPHER_CTX_reset (handled in unit)
BN_secure_new
BN_bn2binpad
BN_lebin2bn
BN_bn2lebinpad
BN_is_negative
BN_mod (handled in unit)

Version :


Note that there is no version number displayed by this output.

I eventually established that the reason was that the PC had old versions of the openssl libeay32.dll and ssleay32.dll DLLs in a folder in the PATH - some Intel control panel app which had added itself to  the main PATH for some reason - note these are 64bit DLLs even though they have a 32 suffix.

The FPC openssl unit searches for the DLLs to load - the way it is written, these files - libeay32.dll and ssleay32.dll - will always be loaded if found on the PATH, in preference to libcrypto-1_1-x64.dll and libssl-1_1-x64.dll even if the latter dlls are in the same dir as the exe.

I fixed the issue by removing the Intel dir from the PATH, it doesn't seem to have affected the running of the PC.

[paweld]

Therefore, you should always provide the OpenSSL libraries in the directory together with the executable file. Then such problems do not occur.

[chris_laz]

@paweld, no, that won't help here.
The FPC openssl unit always searches for the DLLs named libeay32.dll and ssleay32.dll (and confusingly, these can be 64bit DLLs) before it searches for the libcrypto-1_1-x64.dll and libssl-1_1-x64.dll files that I had placed in the same dir as my exe.
It uses LoadLibrary to search for the DLLs, so if they are anywhere on the PATH, they will be loaded.

Arguably it's a bug in the logic - is it better to search for the newer 64bit filenames first, and then fallback to the legacy 32bit filenames? It's also difficult to workaround without replacing the whole openssl unit, as the LoadLibraries proc is in the implementation section - it can't easily be hooked or replaced.

[paweld]

I just checked FPC 3.2.2, and that's indeed the case.
However, in version 3.2-fixes (which I have been using for a long time) and the upcoming 3.2.4, this has been corrected and libraries are searched from the newest, i.e., first in version 3, then 1.1, and only at the very end the older ones.

As for file names and bitness, in older versions of OpenSSL (below 1.1), files always had the same name (libeay32 and ssleay32) regardless of whether it was a 32-bit or 64-bit version of the library. Only since version 1.1 do 64-bit versions include a suffix indicating the bitness of the library. The program and library must be in the same bit version.

[chris_laz]

Ah, that's good that this has been recognised and fixed in the latest FPC. I'll wait for the FPC fixes to be released and incorporated into a Lazarus release, as I try to keep my dev environment as simple as possible, without customisations.

I'm well aware of standard library naming conventions, it's not just openssl who created 64bit libs named the same as 32bit libs - Microsoft did the same sort of confusing anti-intuitive naming with System32 and SysWOW64 - still seems like a bad choice to me, but hey, no doubt there were  arguments on both sides.

[Warfley]

Ah, that's good that this has been recognised and fixed in the latest FPC. I'll wait for the FPC fixes to be released and incorporated into a Lazarus release, as I try to keep my dev environment as simple as possible, without customisations.

If it doesn't make it to FPC 3.2.4 which is being prepared right now, it will probably be years. Just be aware of that

I'm well aware of standard library naming conventions, it's not just openssl who created 64bit libs named the same as 32bit libs - Microsoft did the same sort of confusing anti-intuitive naming with System32 and SysWOW64 - still seems like a bad choice to me, but hey, no doubt there were  arguments on both sides.

Simple, compiling für 64 bit is for most programs just setting a flag in the compiler, if the naming for the libraries changed you'd need code changes. This way you can have exactly the same code for 32 and 64 bit applications