Static OpenSSL Linking in sgcWebSockets: No More libcrypto and libssl DLLs | eSeGeCe Blog

Static OpenSSL Linking in sgcWebSockets: No More libcrypto and libssl DLLs

· Components
Static OpenSSL Linking in sgcWebSockets: No More libcrypto and libssl DLLs

Deploying TLS with sgcWebSockets on Windows has always meant shipping libcrypto and libssl next to your executable, matched to the right OpenSSL version and bitness. sgcWebSockets can now link OpenSSL directly inside the executable instead, so there is no DLL to deploy, no version to match, and no folder to keep them in. It is available in the Enterprise and All-Access editions.

One unit, nothing else to configure

There are no compiler directives to enable and no OpenSSL API version to choose. Add the unit sgcIdSSLOpenSSL_Static to the uses clause of your project, and from the next run onward your application uses the OpenSSL library linked into the .exe, for both client and server components.

uses
  sgcWebSocket, sgcWebSocket_Classes,
  sgcIdSSLOpenSSL_Static;

Remove the unit from the uses clause and your application goes back to loading the OpenSSL DLLs exactly as before. There is nothing else to change in your code, your TLS settings, certificates and connection logic stay the same either way.

Works in clients and servers, Win32 and Win64

Static linking applies equally to TsgcWebSocketClient and to TsgcWebSocketServer, and to any other sgcWebSockets or sgcIndy component that goes through TLS, in both 32-bit and 64-bit builds. A server that terminates TLS for hundreds of connections and a client that dials out to a single endpoint both pick up the linked-in OpenSSL the same way, just by having the unit in the project.

OpenSSL 3.5.7, kept up to date

The OpenSSL version currently linked in is 3.5.7. As new OpenSSL releases come out, this gets refreshed in future sgcWebSockets updates, so you do not need to track, download or redeploy OpenSSL binaries yourself, a normal component update is enough.

Requirements

If you compile with a Delphi version older than XE2 and still reference the unit expecting it to link, you will see E2045 Bad object file format. The fix is simply to remove sgcIdSSLOpenSSL_Static from the uses clause, your application will keep working with the OpenSSL DLLs.

When this helps

Static linking is useful when you want to ship a single file, when you cannot guarantee the target machine already has the right OpenSSL DLL installed, or when your deployment process does not allow extra files next to the executable, for example a locked-down install directory or a tool distributed as one binary.

Availability

Static OpenSSL linking ships in the Enterprise and All-Access editions of sgcWebSockets. For the full picture of the TLS backends sgcWebSockets supports on every platform, see the SSL / TLS section and the OpenSSL TLS backend page.

Download from the sgcWebSockets download page, or grab it through GetIt or your registered account.

Questions, feedback or help planning a DLL-free deployment? Get in touch, you will get a reply from the people who wrote the code.