> >> I notice that Tomcat distributes openssl.exe and not openssl.dll (or > >> similar). Are you building openssl.exe or openssl.dll when you build > >> OpenSSL? > > > > Building OpenSSL on Windows results in three distributable files: > > libeay32.dll, ssleay32.dll, and openssl.exe. I copy the first two into > > Tomcat\bin, along with tcnative-1.dll, in order to make OpenSSL > > available to tcnative. It also results in libeay32.lib and > > ssleay32.lib, which are used in the tcnative compile process. > > What happens is you put openssl.exe in there alongside the .dll files?
Nothing different. Openssl.exe is simply the openssl utility program, and it is the libeay32.dll and ssleay32.dll libraries that provide the underlying functionality. > With your test program, was anything in the PATH (or current > directory) other than the two .dll files? (I'm just trying to figure out why > Tomcat ships with openssl.exe at all... I thought it was all > statically-linked). Only libeay32.dll and ssleay32.dll were in the same directory as my test program. My guess is that openssl.exe ships with Tomcat to allow users to create and manage SSL server certificates, as a helpful utility. I believe you are correct that the tcnative build that ships with Tomcat statically links the OpenSSL libraries, as my copy of Tomcat did not have libeay32.dll or ssleay32.dll, but still was able to provide SSL services through the original tcnative library. > I presume you are not building a statically-linked tcnative.dll (which would > include the OpenSSL code), right? I believe so, but am not positive. It seems the Visual Studio tcnative build statically links the APR library, but it doesn't seem to work unless libeay32.dll and ssleay32.dll are present, so I think that means OpenSSL is not statically linked. --Steve Nickels Ipswitch, Inc.
