In my application I am using IdHTTP.Get. A part of the code:
var
IdHTTP: TIdHTTP;
begin
IdHTTP := TIdHTTP.Create(nil);
Output := IdHTTP.Get(url);
...
IdHTTP.Free;
Using IdHTTP.Version gives me the version: 10.6.2.5263
I have downloaded the OpenSSL from here, both libeay32.dll and ssleay32.dll are in the same folder of my application.
This problem occured since I am using a new laptop with Windows 10.
I hope someone can tell me how to solve this problem!
asked Feb 9, 2016 at 11:37
TeunTeun
5751 gold badge6 silver badges14 bronze badges
10
If you need to access an https url, you must add some code, to complete the creation of the TidHTTP component.
Try use something like this:
// create components
HTTPs := Tidhttp.Create(nil);
IdSSL := TIdSSLIOHandlerSocket.Create(nil);
// try..finally for free
try
// ini
HTTPs.ReadTimeout := 30000;
HTTPs.IOHandler := IdSSL;
IdSSL.SSLOptions.Method := sslvTLSv1;
IdSSL.SSLOptions.Method := sslvTLSv1;
IdSSL.SSLOptions.Mode := sslmUnassigned;
...
You need to add IdSSLOpenSSL to uses clause.
Toon Krijthe
52.8k38 gold badges145 silver badges202 bronze badges
answered Feb 9, 2016 at 12:15
5
Having 32 bit target platform for your application in a 64 bit system will also cause this problem. I don’t know how to properly fix this but an easy way is to compile exe for same system your OS is.
answered Jun 22, 2021 at 18:09
DoegeDoege
3414 silver badges12 bronze badges
0
After trying the various solutions offered here, none of them work with the latest version of Windows 10 or Windows 11.
I would like to share my solution that works:
Just install the latest version of open SSL openssl-1.0.2u-x64_86-win64 which is available here.
It includes the two necessary libraries for TidHTTP libeay32.dll and ssleay32.dll in version 1.0.2.21
tomerpacific
4,52413 gold badges33 silver badges51 bronze badges
answered Dec 16, 2021 at 12:48
2
If you are NOT using Android 6 Marshmallow, OpenSSL should be working fine on Android. When you get the «could not load» error, you can call Indy’s WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why OpenSSL could not be loaded. If your device does not have OpenSSL pre-installed, you can deploy the OpenSSL binaries with your app, and use Indy’s IdOpenSSLSetLibPath() function to tell Indy where to load them from.
That being said, starting with Android 6 Marshmallow, Google no longer supports OpenSSL on Android. It has been replaced with a custom fork named BoringSSL, which Indy does not fully support yet (although some BoringSSL-related changes have been made to Indy after Seattle’s release). So, if you are having trouble with using Indy SSL/TLS on Android 6, you can try upgrading to the latest Github snapshot to see if it helps.
BoringSSL makes some major changes to the OpenSSL API interface (dropping functions, changing data types, etc), so it is not backwards-compatible with existing OpenSSL code. But to make matters worse, BoringSSL uses the same library filenames as OpenSSL, and is pre-loaded at device startup, so it is not possible to deploy custom-built OpenSSL library binaries with your Android app. Android will simply use the pre-loaded BoringSSL binaries when the app tries to load the OpenSSL library filenames at runtime (regardless of whether you call Indy’s IdOpenSSLSetLibPath() function).
Indy operates at the NDK level of Android, not the Java level, so to make Indy avoid BoringSSL would require users to either:
-
recompile the OpenSSL libraries with new filenames that don’t conflict with BoringSSL (AFAIK no known version of this is available), and then update Indy to use those filenames.
-
compile the OpenSSL source code directly into their Android app. Indy is not currently setup to support static-linking of OpenSSL on any platform other than iOS, but this should be a minor change to update Indy’s
IdSSLOpenSSLHeaders_staticunit with the relevant definitions if someone can produce viable.afiles for OpenSSL on Android. I do know of at least one user attempting this route, but that user has not had success yet (errors getting the source code to fully link correctly). -
switch to Android’s higher-level Java-based crypto APIs. This is Google’s preferred solution. But Indy does not support it at this time. Doing so would require writing a whole new set of
TIdStackandTIdIOHandlerclasses for Android socket I/O and SSL/TLS, using JNI calls to access the Java APIs. But this has performance and threading issues that need to be dealt with.
So, there is no known viable workaround available at this time to make Indy SSL/TLS work on Android 6+.
Update: a user in the Embarcadero forums was able to find OpenSSL .so files that are compatible with Indy and work on Android 6:
https://forums.embarcadero.com/thread.jspa?threadID=211089
After many reports of my apps crashing if installed in Android 6 devices I’ve searched the net for some tips and the couple of needed .so compiled files, 1.02 version, added the two files to the play store deployment of my apps (assetsinternal) and changed the Indy’s path calling
IdOpenSSLSetLibPath(TPath.GetDocumentsPath)
in the OnCreate of my datamodule.
After those modifications of my code my Apps run perfectly on my brand new S7 with Android 6.0.1, and on all the other recent Android devices (tested using the Play Store deployment).
And now the Google warning pops up telling me that the OpsnSSL files deployed with my apps are not of the minimum required 1.02f version (or 1.01r)…. and so my post in this forum.
…
Anyway you can download here the latest .so files, the ones that I deploy at this moment:
https://drive.google.com/file/d/0B7AxqW32K0oXWW9nUk9qaFpHT0k/view?usp=sharing
Another user in the same discussion also seems to have some success as well:
Ive been running on android 6 loading the .so libraries just fine for months. The new problem is we need to compile new versions of the openssl libraries. Cygwin is not working correctly to compile for me so im switching to a linux install to create them (if possible) https://wiki.openssl.org/index.php/Android#Build_the_OpenSSL_Library_2
heres a repository you can grab some current prebuilt ones https://github.com/emileb/OpenSSL-for-Android-Prebuilt.git
Update: The following (German) forum discussion provides OpenSSL 1.0.2g binaries for Android (and iOS Simulator) to registered users. They do not display the security warning in the Google Play store:
http://www.delphipraxis.net/188736-kompilierte-openssl-bibliotheken-fuer-android.html
OpenSSL 1.0.2g Android.zip
OpenSSL 1.0.2g iOS Simulator.zip
Update: the Android binaries for OpenSSL 1.0.2g are now available in the Embarcadero Attachments forum:
https://forums.embarcadero.com/thread.jspa?threadID=211147
Then, to load OpenSSL instead of BoringSSL, follow these steps:
-
Add the 2
.sofiles to your project deployment and set them to deploy to the.assetsinternalfolder -
add the
System.StartupCopyunit as the first unit in your DPR’susesclause. -
call
IdOpenSSLSetLibPath(TPath.GetDocumentsPath)at app startup.
Update: OpenSSL 1.0.1t and 1.0.2h binaries are now in the Embarcadero Attachments forum:
https://forums.embarcadero.com/thread.jspa?threadID=211147
Update: the binaries have now been posted on Indy’s Fulgan mirror:
http://indy.fulgan.com/SSL/
Update: Indy is no longer using the Fulgan mirror for hosting OpenSSL binaries. They are now in their own GitHub repo:
OpenSSL binaries moved to GitHub
https://github.com/IndySockets/OpenSSL-Binaries
Thread Rating:
- 0 Vote(s) — 0 Average
- 1
- 2
- 3
- 4
- 5
|
Error: Could not load SSL library |
|
Posts: 7 Reputation: 0 Hi, A small number of users report this error when trying to download webpages with my application. The app includes recent versions of OpenSSL in the same folder as the exe. Is it possible for me to rename the dlls and then set a custom name for the dlls in Indy? (Delphi XE4; Indy 5438) Thanks
Posts: 41 Reputation: 0 Location: New Zealand
Use a special directory for your SSL files, then force Indy to use this directory. Code:
SSLDir := MyFullPath; Bart
—
Posts: 7 Reputation: 0 Can it not be in the same directory as the main exe with other files?
Posts: 41 Reputation: 0 Location: New Zealand
As long as you make sure that this is a guarantied permanent directory, e.g. you must enter is as an absolute path. Code:
Nice and clean.
—
Posts: 7 Reputation: 0 I call this in Main Form initialization: initialization Report from user: «Failed to load…» is from call to WhichFailedToLoad() http://www.bauerapps.com/dev/HttpsTest.zip Any ideas?
Posts: 41 Reputation: 0 Location: New Zealand Honestly, read what it says. Are you telling me that your executable is on the Desktop? There are clearly NOT at «ExtractFilePath(Application.ExeName)» wherever that is. Print it out and see if your libraries are actually there. But: Stop using the ‘executable’ directory to put things in. This may be anywhere. Use a Known, Fixed directory as I described, and you always know for sure where to find it, regardless if you run from the IDE of from wherever the executable may be at that time. (If you run your program from the IDE, it runs from its compiled location, but if you use an installation package to install the program its somewhere totally different. So where are your libraries then?). Bart
—
Posts: 561 Reputation: 33 Location: USA 05-09-2018, 06:19 PM
The filenames are hard-coded in Indy’s source code. Even if you renamed the DLLs and recompiled Indy, it still wouldn’t work, because ssleay32.dll has dependencies on functions exported from libeay32.dll, so renaming that DLL would break those dependencies. You would have to recompile OpenSSL itself.
Usually, when the DLLs themselves fail to load into memory, it is because they likely have dependencies on additional DLLs that are missing on the user’s system, such as Microsoft’s VC++ runtime DLLs. Try using the OpenSSL DLLs at http://indy.fulgan.com/SSL/, they don’t have any extra dependencies (only to each other).
Windows doesn’t look just anywhere, it has very specific places it looks for DLLs. If you don’t use IdOpenSSLSetLibPath() to set a specific folder, you still have some control over where Windows looks, via SetDllDirectory(), AddDllDirectory(), and SetDefaultDllDirectories(). This is also important when dealing with OpenSSL DLLs that have external dependencies on other DLLs, because IdOpenSSLSetLibPath() does not influence where Windows looks for those other DLLs.
Posts: 7 Reputation: 0 05-09-2018, 06:36 PM >>Are you telling me that your executable is on the Desktop? It looks like it, in a folder «HttpsTestv1.2» >>And you have set the SSL directory to where your executable is running from? Correct. >>And where is that then? C:UsershjhuDesktopHttpsTestv1.2 >>And where did you copy your SSL files? The zip file pointed to in previous post only contains 3 files. >>There are clearly NOT at «ExtractFilePath(Application.ExeName)» wherever that is. They clearly are… >>But: Stop using the ‘executable’ directory to put things in. This may be anywhere. And what is wrong with that? Are you familiar with «ExtractFilePath(Application.ExeName)»?
Thanks Remy.
Posts: 7 Reputation: 0 Thank you. Using the fulgan DLLs has solved the problem. |
Users browsing this thread: 1 Guest(s)
Some libraries, like Indy, use openssl to connect to secure servers using TLS. As some components from sgcWebSockets package are based on Indy library, make use of openssl libraries and sometimes you get an error message when you can load a library.
There are several reasons why you can’t load the openssl library.
In the following lines I will try to explain the most common ones.
Library can not be found
Yes, this is the number one reason why library can not be loaded. Usually if openssl libraries are in the same folder that your main application, openssl can be loaded in your app. You can try to update your global path where your openssl libraries are if this is not the same folder than your application.
So, every time you get this error, first check if your openssl libraries exists and are in the correct folder.
Library is old
OpenSSL libraries are updated quite often and sometimes you don’t have the latest openssl libraries or are not compatible with your application.
Check if you have latest openssl libraries because if some function needed by your app are not included in your openssl library, this can be a reason why can not be loaded.
VC++ runtime package is not installed
Yes, another reason, why openssl library can not be loaded, in windows environments, is because vc++ runtime packages are not installed in your machine. If you are not sure if have been installed, first install runtime package and try again.
Установил плагин буквально 11-12 апреля 2017 и на удивление все заработало на раз-два.
Быстро, шустро, показывало размеры папок.
Думаю прелесть какая, можно зайти в любой момент скопировать/удалить и все без браузера.
На выходные оставил работать Cloud.Mail.Ru агента для синхронизации папок.
И вот сегодня 17.04.2017, вижу переименованные дубликаты файлов в каталоге синхронизации, думаю посмотрю через плагин, что старое, что свежее, подчищу, а плагин не работает.
При попытке установить соединение пишет: «EIdOSSLCouldNotLoadSSLLibrary ошибка с сообщением: Could not load SSL library. при отправке данных на адрес https://auth.mail.ru/cgi-bin/auth»
На прошлой неделе все работало. Я просто создал вручную папку, закинул плагины , вручную вписал их в Конфигурация-Настройки-Плагины.