Indy and SSL

If anyone has ever tried to get the OpenSSL libraries to work with Indy, you may have experienced a lot of pain with the process. I'm in the process of trying to develop an application for DHL's ShipIT XML Api that utilizes an HTTPS POST. The actual post code from Indy is easy

response := HTTP.Post(url, file);

but getting the SSL side to work, especial on Vista, is painful. I should disclose here that I have yet to get the HTTPS to send the data correctly via Indy, but I did finally get OpenSSL playing with Indy under Vista.

Basically, the problem stems from the fact that Indy lets you make SSL assignments that will fail at run-time and then provides very little in the way of information about the failure. This is caused by IdSSLOpenSSLHeaders.pas not having any meaningful error reporting on the OpenSSL libraries failing to load. To be clear, it does basically say "Can't load library" but that's it.

To fix it, search on SafeLoadLibrary in IdSSLOpenSSLHeaders.pas. You'll find a section that basically looks like:

  {$IFNDEF FPC}
    {$IFDEF WIN32_OR_WIN64_OR_WINCE}
  if hIdCrypto = 0 then begin
    hIdCrypto := SafeLoadLibrary(SSLCLIB_DLL_name);
  end;
  if hIdSSL = 0 then begin
    hIdSSL := SafeLoadLibrary(SSL_DLL_name);
  end else begin
    Exit;
  end;
    {$ENDIF}
 {$ENDIF}

What is happening here is that hIdCrypto and hIdSSL are attempting to load the OpenSSL DLLs. If this fails, there is no trap to capture the error. I recommend changing the loading to:

  {$IFNDEF FPC}
    {$IFDEF WIN32_OR_WIN64_OR_WINCE}
  if hIdCrypto = 0 then begin
    hIdCrypto := SafeLoadLibrary(SSLCLIB_DLL_name);
    if hIDCrypto<1 then
       Windows.MessageBox(0, pansichar('An error occured loading '+SSLCLIB_DLL_name+#13#10+ErrorDefinition(getLastError)), 'Error',
                          MB_TASKMODAL+MB_SETFOREGROUND+MB_TOPMOST);
  end;
  if hIdSSL = 0 then begin
    hIdSSL := SafeLoadLibrary(SSL_DLL_name);
    if hIDSSL<1 then
       Windows.MessageBox(0, pansichar('An error occured loading '+SSL_DLL_name+#13#10+ErrorDefinition(getLastError)), 'Error',
                          MB_TASKMODAL+MB_SETFOREGROUND+MB_TOPMOST);
  end else begin
    Exit;
  end;
    {$ENDIF}
 {$ENDIF}

Oh, you'll also need my little cheat routine called ErrorDefinition. It just takes the last Windows error (which you pass, otherwise you couldn't save it if you had some type of log that kept track of the error number and the error message) and converts it to a string. For some reason, I find error #14401 not terribly useful.

function ErrorDefinition(x:longint):string;
var Buffer : array[0..255] of Char;

    function TrimWhite(const S : String) : String;
    var
      i : Integer;
    begin
      Result := S;
      for i := length(Result) downto 1 do
        if Result[i] < ' ' then
          Result[i] := ' ';
      i := pos('  ',Result);
      while i <> 0 do begin
        delete(Result,i,1);
        i := pos('  ',Result);
      end;
    end;

begin
   result:='';
   //ask for error message from OS
   if FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM,nil,abs(x),0,
                    Buffer,255,nil) > 0 then
      Result := TrimWhite(StrPas(Buffer));
end;

Some of you may want to change the MessageBox function over to a raise Exception.Create... but I'll leave that to your discretion. For my purposes, I was just trying to get something that gave more details than "Unable to load". Of course, the next problem is that the error message I got was really unhelpful. In my case, the message says that there is a problem with the SideBySide configuration and to check the event viewer for the application log. Since I have no idea what a SideBySide configuration is, I check the application log to discover this message

 "Activation context generation failed for "j:\winprog\main\ssleay32.dll". Dependent Assembly Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis." 

Now I'm really confused. I've just installed the OpenSSL libraries via the installer. Just to make sure, I check that the SSL DLLs actually are present in the system32 directory. Just to make sure, I copy them local and still have the problem. I then download the special OpenSSL libraries that are supposed to work better with Indy and have the same results. BTW, I did use the sxstrace tool which is (remarkably) easy to use. The problem is that it points me into the SideBySide directory (c:\windows\winsxs) which doesn't look like it's designed to be edit by people. For those interested, the sxstrace tool output looks like:

"Begin Activation Context Generation.
Input Parameter:
 Flags = 0
 ProcessorArchitecture = x86
 CultureFallBacks = en-US;en
 ManifestPath = j:\winprog\main\libeay32.dll
 AssemblyDirectory = j:\winprog\main\
 Application Config File =
-----------------
INFO: Parsing Manifest File j:\winprog\main\libeay32.dll.
 INFO: Manifest Definition Identity is (null).
 INFO: Reference: Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"
INFO: Resolving reference Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
 INFO: Resolving reference for ProcessorArchitecture x86.
  INFO: Resolving reference for culture Neutral.
   INFO: Applying Binding Policy.
    INFO: No publisher policy found.
    INFO: No binding policy redirect found.
   INFO: Begin assembly probing.
    INFO: Did not find the assembly in WinSxS.
    INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC90.CRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.CRT.DLL.
    INFO: Attempt to probe manifest at j:\winprog\main\Microsoft.VC90.CRT.DLL.
    INFO: Attempt to probe manifest at j:\winprog\main\Microsoft.VC90.CRT.MANIFEST.
    INFO: Attempt to probe manifest at j:\winprog\main\Microsoft.VC90.CRT\Microsoft.VC90.CRT.DLL.
    INFO: Attempt to probe manifest at j:\winprog\main\Microsoft.VC90.CRT\Microsoft.VC90.CRT.MANIFEST.
    INFO: Did not find manifest for culture Neutral.
   INFO: End assembly probing.
 ERROR: Cannot resolve reference Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
ERROR: Activation Context generation failed.
End Activation Context Generation."

At any rate, Google of course tells me that I'm missing the MS VC 9.0 RTL. This is surprising since I have MS VS 2008 installed on this machine but some digging in those folders doesn't turn up the VC90 DLLs (which, just to be fun, are actually named msvc?90.dll). At any rate, I found a link to them on Google Code, download them and put them AND the manifest file in the system32. For those of you who read the sxstrace dump better than I did, I'm sure you won't be surprised to find that this didn't do anything to fix the problem. I then copy the DLL files locally. Still nada. I finally get a clue and copy the DLLs AND the manifest file locally and voila, I can now load the OpenSSL libraries. Of course, I could have put the files and manifest in C:\Windows\assembly\GAC_32\Microsoft.VC90.CRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.CRT.DLL (I think), but that folder doesn't really look like it should be adjusted via the command prompt AND I'm probably going to switch away from Indy for this project since the chances of getting this successfully deployed to hundreds of machines just went down a couple of notches.

At any rate, I still haven't figured out the HTTPS Post issue yet. I can post the XML to DHL fine via FF, but the Indy code is corrupting the XML somehow. I'll post again once I get that part figured out and provide the sample code that is so lacking from the Indy project. Don't get me wrong, Indy rocks for what it does, but they could REALLY use a huge set of "for instance" samples. This blog gets 70 hits or so every week just from people looking for hints on the Indy SMTP components that I posted a while back.

Oh, and WHEN did we decided "Unable to load DLL xyz" should be renamed "SideBySide Configuration"? I don't know about you, but the former is much more descriptive than the later.