OpenSSL (iohOpenSSL) is the cross-platform TLS transport for sgcWebSockets. It runs on every platform the library targets and is the default on most of them, with the broadest protocol and cipher coverage of any backend. Enable it by setting TLSOptions.IOHandler to iohOpenSSL, then deploy the OpenSSL runtime libraries alongside your application.
Cross-platform TLS implemented over Indy's socket, available on every platform sgcWebSockets targets.
OpenSSL is the cross-platform TLS implementation that sgcWebSockets layers over Indy's socket. It is available on Windows, Linux, macOS, iOS and Android, and it is the default backend on most of them. Choose OpenSSL when you need identical TLS behavior across every platform, or when you depend on a capability that only OpenSSL exposes.
The backend covers TLS 1.0 through TLS 1.3 with the widest cipher suite selection of any sgcWebSockets transport. You can trust a private or self-signed authority with a custom CA root (RootCertFile), present a client certificate for mutual TLS, and advertise application protocols such as http/1.1 through ALPN. Because all four backends share the same TLSOptions API, code written against OpenSSL moves to a native backend by changing only the IOHandler line.
The trade-off is deployment. OpenSSL is an external dependency, so you ship its runtime libraries with your application and keep them patched. On Windows that means libssl-3.dll and libcrypto-3.dll, on Linux and Android the matching .so files, and on Apple platforms the .dylib files. If you want native TLS with zero libraries to deploy, look at SChannel on Windows or the native Android and Apple backends, or keep using OpenSSL and link it statically into your Windows executable instead, see below.
Set TLSOptions.IOHandler to iohOpenSSL, then deploy the OpenSSL libraries with your build.
uses
sgcWebSocket, sgcWebSocket_Types;
// ...
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohOpenSSL;
WSClient.TLSOptions.VerifyCertificate := True;
WSClient.TLSOptions.RootCertFile := ''; // optional custom CA (PEM/DER)
WSClient.TLSOptions.CertFile := ''; // optional client cert for mTLS
WSClient.TLSOptions.Password := '';
WSClient.TLSOptions.ALPNProtocols.Add('http/1.1');
WSClient.Host := 'your.server.com';
WSClient.Port := 443;
WSClient.Active := True;WSClient->TLS = true;
WSClient->TLSOptions->IOHandler = iohOpenSSL;
WSClient->TLSOptions->VerifyCertificate = true;
WSClient->TLSOptions->RootCertFile = ""; // optional custom CA (PEM/DER)
WSClient->TLSOptions->CertFile = ""; // optional client cert for mTLS
WSClient->TLSOptions->Password = "";
WSClient->TLSOptions->ALPNProtocols->Add("http/1.1");
WSClient->Host = "your.server.com";
WSClient->Port = 443;
WSClient->Active = true;OpenSSL is an external dependency, so the runtime libraries travel with your application on every platform.
Deploy libssl-3.dll and libcrypto-3.dll next to your executable (the 32-bit or 64-bit build to match your target), or skip the DLLs entirely by linking OpenSSL statically, see below.
Bundle the matching libssl and libcrypto .so files, then load them from a path your application can reach at runtime.
Ship the libssl and libcrypto .dylib files with the app bundle so the OpenSSL runtime is available on the device.
Because the libraries are yours to deploy, you are responsible for updating them when a security fix is released.
On Windows, OpenSSL can be linked directly inside your .exe instead of being loaded from libssl-3.dll and libcrypto-3.dll at runtime.
Add the unit sgcIdSSLOpenSSL_Static to the uses clause of your project and there is nothing else to set up: no compiler directive to enable, no OpenSSL API version to choose. Your application starts using the OpenSSL library linked into the executable the next time it runs, for both client and server components, in 32-bit and 64-bit builds. Remove the unit from the uses clause and your application goes back to loading the OpenSSL DLLs exactly as before.
uses
sgcWebSocket, sgcWebSocket_Classes,
sgcIdSSLOpenSSL_Static;The OpenSSL version currently linked in is 3.5.7, refreshed in future updates so you don't need to track or redeploy OpenSSL binaries yourself. Static linking requires Delphi XE2 or newer and the custom Indy library (the default in these editions); on older Delphi versions the unit compiles to nothing and your application keeps loading the OpenSSL DLLs as usual.
OpenSSL (iohOpenSSL) is included in every edition of sgcWebSockets. See the feature matrix for the full breakdown.
Static linking on Windows requires Delphi XE2 or newer and is available in the Enterprise and All-Access editions.