POST returns EIdOSSLCouldNotLoadSSLLibrary

[pete@pdmagic.com]

Hi there!  Hope whoever reads this is having a great day!

I've got an Intraweb app that serves up a REST interface.  I've also got a Delphi desktop app that consumes the Intraweb apps' REST interface using Indy.  I've had it all working both locally and installed as an ISAPI for a while now.  ...Until I directed IIS to force all requests to https.  The Intraweb app works fine under https. But the desktop app started complaining EIdOSSLCouldNotLoadSSLLibrary.  Interestingly, another desktop app (in c#) needed no modifications and has continued to run fine, now accessing the https REST URL.

In fact, here is a live URL: https://dev.governmenttools.com/alpha/cm.../VersionNH
My client code for making the REST call (POST) is below.

So far I haven't done *anything* to the desktop app.  I haven't added any DLLs to its path, I haven't changed any code to have it use https, nothing.  So here are my questions:
1. Assuming a working non-ssl desktop app, what changes need to be made to support SSL?
2. My desktop app, used for data entry, is currently just a single .exe.  I'd love to keep it that way.  Is there any way to bundle the functionality needed into the .exe?  I'm not beyond adding the dlls as a resource and extracting them before dynamically loading them. Otherwise, I'll need to create an installer.
3. In searching on the web, I see other programmers writing SSL specific Indy code when connecting to https.  Is this necessary?  From my limited experience, Indy seems to be identifying that it wants to do SSL, but looking for those dll's most likely.
4. Any suggestions?  (that's carte blanche to criticize my strategy if you feel so inclined) 

Thanks,
Pete

Code:

function TpdHTTPClient.Post( aName        : string;
                             aServiceURL  : string;
                             aParams      : TStringList ) : string;
var lHttp :TIDHttp;
    lRequestStream, lResponseStream : TStringStream;
begin
  lHttp := TIDHttp.Create(nil);
  try
    ConfigureHttp( lHttp );
    result := lHttp.Post( aServiceURL, aParams );
  finally
    lHttp.Destroy;
  end;
end;

procedure TpdHTTPXMLClient.ConfigureHttp(aHttp: TIDHttp);
begin
  inherited;
  aHTTP.Request.ContentType := 'application/x-www-form-urlencoded';
//  aHttp.Request.ContentType := 'application/xml';
end;

---

Okay, as my daughter would say - "my bad". Sorry about that.

I could have at least tested the .dll's.  I added the dll's to the .exe directory and everything works fine.  
So the question is more simple - how to pack into .exe, and any other suggestions?

Thanks for your time.

[rlebeau]

But the desktop app started complaining EIdOSSLCouldNotLoadSSLLibrary.

When the error happens, what does Indy return from the WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit?

Interestingly, another desktop app (in c#) needed no modifications and has continued to run fine, now accessing the https REST URL.

.NET does not use OpenSSL. Your app does, because Indy's default IOHandler class for SSL/TLS is TIdSSLIOHandlerSocketOpenSSL.

So far I haven't done *anything* to the desktop app.  I haven't added any DLLs to its path, I haven't changed any code to have it use https, nothing.

That is why you are getting the error.

1. Assuming a working non-ssl desktop app, what changes need to be made to support SSL?

You need the 2 OpenSSL DLLs (libeay32.dll and ssleay32.dll) in order to use OpenSSL. You can get them from Indy's Fulgan mirror. Note that the latest version of OpenSSL is currently 1.1.1, but Indy currently supports only up to 1.0.2.

2. My desktop app, used for data entry, is currently just a single .exe.  I'd love to keep it that way.  Is there any way to bundle the functionality needed into the .exe?

The only way to truly avoid any external dependencies would be to assign an SSLIOHandler class to the TIdHTTP.IOHandler property, whose SSL/TLS implementation is completely embedded within your app. Indy does not natively provide such an implementation, but there are some 3rd party SSLIOHandler classes floating around (such as provided with Eldos' SecureBlackbox) that may be embedable. Or, you could write your own TIdSSLIOHandlerSocketBase-derived class that uses platform-specific SSL/TLS APIs (such as SChannel on Windows, which FYI is planned to be added to Indy in a future version).

I'm not beyond adding the dlls as a resource and extracting them before dynamically loading them. Otherwise, I'll need to create an installer.

Extracting the OpenSSL DLLs from your app's resources to disk will work fine, as Indy loads the DLLs dynamically at runtime only when they are actually being used to secure TCP connections, so you can extract them before performing your HTTPS requests. If you need to extract the DLLs to a folder other than your app's installation folder (for instance, because it is installed under %ProgramFiles%), Indy has an IdOpenSSLSetLibPath() function in the IdSSLOpenSSLHeaders unit that you can call to tell Indy which folder to look in when it is loading the DLLs.

3. In searching on the web, I see other programmers writing SSL specific Indy code when connecting to https.  Is this necessary?

TIdHTTP requires an SSLIOHandler class be assigned to it in order to handle HTTPS. By default, TIdHTTP creates one internally if not already assigned. However, most examples you are looking at either pre-date that feature, or they require additional setup beyond the default configuration.

From my limited experience, Indy seems to be identifying that it wants to do SSL, but looking for those dll's most likely.

That is exactly what is happening.

[pete@pdmagic.com]

I meant to reply sooner:
Thanks Remy! I appreciate your detailed clarifications and answers.
-Pete