4
votes

I've been trying to SSL working on my IW program for the last little while and I keep running up against the 'Could not load SSL Library'. I've followed every piece of advice I could find on the subject, but still no joy. I've tried the suggested DLLs in both the local directory and in system32.

Does anyone have a definitive answer about what OpenSSL DLLs I should be using? And what build of them? Or any other ideas at all?

Indy: updated to the most recent snapshot yesterday IntraWeb: stock D2007 installed

This is running on a Vista machine, if that makes any difference.

TIA,

Trevor

4
Mind if i asking how to install ssl in intraweb for now ? i search throu internet but nothing good on intraweb. So may i have your attention on this ?Munkhdelger Tumenbayar

4 Answers

3
votes

SOLVED:

It looks like the problem was a bpl floating about on my machine.

Here are the steps I took in case anyone else is having difficulty with getting the standalone server to run with D2007 and the pre-installed libraries:

  1. Remove all traces of Indy from your machine - there's a howto on the Indy site somewhere;
  2. Download the Indy 10 trunk from the subversion repository
  3. Install Indy according to the instructions;
  4. Download the latest IW9 from atozed - you'll need a key;
  5. Install it - let it clobber your current installation;

now, for the OpenSSL DLLs:

  1. Get them from here: http://www.slproweb.com/download/Win32OpenSSL_Light-0_9_8i.exe
    • these are working well for me;
  2. Make sure your firewall is letting port 443 through (or whatever you choose);

At this point, I was able to compile and run the demo and my app.

Thanks for all the help.

Trevor

2
votes

You need the OpenSSL dlls (0.9.8i worked for me, but I'm not using Vista), which you can download here (as I think you're suggesting, the Indy dlls don't work with IW9, which is the version bundled with D2007).

After installation, copy ssleay32.dll and libeay32.dll from system32 to your application directory.

If it still doesn't work:

  • is your servercontroller's ssl port set to 443?
  • does your cert pw match your servercontroller's ssl cert pw?
  • is servercontroller.sslversion set to sslv23?
  • have you tried compiling/running the AtoZed demo application for SSL (standalonessl)?

Hope this helps.

EDIT: once you get this working, you'll want to change sslversion to sslv3, and get users to turn off v2.

1
votes

In a response today to the same question in the intraweb forum on the Embarcadero newsgroups, Chad Z. "Kudzu" Hower posted this link (without any explanation - just the link).

That page provides this link to a special build of the SSL libraries.

Hope this helps.

0
votes

I am the one who has built the aforementioned special build of IntraWeb SSL dlls. To complete the answers above let me explain why there has been the need for a special build:

Previous Indy and IntraWeb editions used a slightly modified version of OpenSSL. The modifications include several functions related to e.g. timezone calculations which were not available in Delphi or Indy at that time.

So when somebody used a unmodified set of OpenSSL dlls (not the Indy OpenSSL dlls) together with an older Indy or IntraWeb version he will get the "Could not load SSL Library" error because of the missing exports.

Since the Indy version we use with Delphi 2009 there is no need for these changes anymore. That is why a current Indy version - from SVN even with Delphi 2007 - together with IntraWeb works with the dlls from slproweb too (which don't include these modifications).

But please note that the slproweb dlls do require the MS VC++ runtime dlls.

To circumvent this I regularly create an own set of dlls for Indy: ftp://ftp.fulgan.com/SSL/

As of today you should be fine using this edition: ftp://ftp.fulgan.com/SSL/openssl-1.0.0d-i386-win32-rev2.zip

My set of dlls don't require the installation of the MC VC runtimes.

So it's safe to say that any Indy version newer than Delphi 2009 and/or the corresponding SVN revision are safe to use with the slproweb (with VC dependencies) or our own (from fulgan mirror) dlls.