sgcCustomIndy TLS 1.3. HTTP/2 via ALPN. Nothing to uninstall.

The standard Indy library does not support ALPN, and it does not support TLS 1.3 through OpenSSL 1.1.1 or 3.x. sgcWebSockets Enterprise ships a custom build of Indy that does. sgcCustomIndy brings that same build to sgcWebSockets Core, installed beside the Indy already in your IDE.

How to get it Explore sgcCustomIndy
  • ALPN and HTTP/2
  • TLS 1.3
  • OpenSSL 1.1.1 and 3.x
  • Static OpenSSL
  • Delphi 7 to 13
  • C++ Builder
STANDARD INDY IdGlobal.pas IdTCPClient.pas IdSSLOpenSSL.pas already in your IDE, stays installed CUSTOM INDY sgcIdGlobal.pas sgcIdTCPClient.pas sgcIdSSLOpenSSL.pas added by the pack, no name collides TLS 1.3 HANDSHAKE WITH ALPN Client Server ClientHello, ALPN [h2, http/1.1] ServerHello, ALPN h2 HTTP/2 streams on one connection
  • 0Indy libraries to uninstall
  • 0Indy 10 installs on Delphi 7
  • 3Capabilities standard Indy lacks
  • 1Unit for static OpenSSL
  • 2Static linking targets, Windows 32 and 64 bit
What it unlocks

Three things the standard Indy library cannot do.

Every item below is a capability of the Indy layer itself, not of a component sitting above it. That is why swapping the Indy library is what turns them on.

CLIENTHELLO ALPN offers h2 http/1.1 Server picks h2 stream 1 stream 3 stream 5 HTTP/2 streams Negotiated inside the TLS handshake, below any HTTP component.
ALPN

The extension HTTP/2 is built on.

  • The client advertises the protocols it can speak, and the server picks one, during the TLS handshake.
  • That negotiation happens inside the TLS layer, below anything an HTTP component can reach.
  • The standard Indy library does not support it. The custom Indy library makes ALPN, and with it HTTP/2, available.
STANDARD INDY TLS 1.3 capped at the older OpenSSL API CUSTOM INDY TLS 1.3 OpenSSL 1.1.1 OpenSSL 3.x Clients and servers reach endpoints that require TLS 1.3.
TLS 1.3, OpenSSL 1.1.1 and 3.x

The modern OpenSSL branches, reachable at last.

  • TLS 1.3 needs OpenSSL 1.1.1 or OpenSSL 3.0.0, and the standard Indy library does not support those branches.
  • The custom Indy library does, so a client or server built on it negotiates TLS 1.3 against endpoints that require it.
  • No longer capped at what the older OpenSSL API offers.
THREE FILES TO DEPLOY app.exe libssl libcrypto ONE FILE TO DEPLOY app.exe OpenSSL linked in uses sgcIdSSLOpenSSL_Static; Windows 32 and 64 bit, Delphi XE2 or newer.
Static OpenSSL

OpenSSL inside the executable.

  • OpenSSL is linked directly into your application instead of loaded at runtime from the libcrypto and libssl DLLs.
  • A TLS application deploys as a single file, for client and server components alike.
  • It takes effect only when the custom Indy library is in use, on Windows 32 and 64 bit with Delphi XE2 or newer.
Coexistence

It sits beside the Indy you already have.

Replacing the Indy library in an IDE is the part nobody wants to do, so this pack does not ask for it. The custom Indy files carry an sgc prefix, IdGlobal becomes sgcIdGlobal, and both versions coexist without problems.

Nothing to uninstall

Whatever Indy your IDE already has stays installed and stays registered. There is no step where you remove a package, restore it later, or keep two IDE profiles around.

Existing projects untouched

Anything you already build against the standard Indy library keeps compiling against it, byte for byte the same units. The custom build is additional, not a replacement.

One compiler define

Use of the custom Indy library is controlled by SGC_CUSTOM_INDY in sgcVer.inc. Turning the custom build off again is a one line change.

Full source, as always

The renamed Indy units ship as source with the licence, so they compile with your project settings and step through in your debugger like the rest of the library.

No Indy 10 install on Delphi 7

Delphi 7 ships with an older Indy. With the custom Indy library bundled in, there is no Indy 10 to find, install into the IDE, or keep matched against the components.

The build Enterprise uses

The custom Indy library is not new. It is what sgcWebSockets Enterprise has been built on, and this pack is the route to it for sgcWebSockets Core.

The code

One unit, one file to deploy.

There is nothing to configure. Add sgcIdSSLOpenSSL_Static to the uses clause, for example in the main .dpr, and the application uses the OpenSSL linked into the executable the next time it runs.

Project1.dpr

uses
  sgcIdSSLOpenSSL_Static;

// That is the whole configuration. No compiler
// directive to enable, no OpenSSL API version to
// choose. Remove the unit again and the application
// goes back to loading the OpenSSL DLLs.

sgcVer.inc, in the source folder

{$DEFINE SGC_CUSTOM_INDY}

// One define controls the custom Indy library.
// Static OpenSSL linking has no effect without it,
// and turning the custom build off again is a
// one line change.

On a version or platform where static linking is not available, nothing breaks. The application keeps loading the OpenSSL DLLs as it did before, so the same source builds everywhere. Where static linking applies

Platforms

Where an object file in this format can be linked.

  • Windows 32 bit
  • Windows 64 bit

Compiler

Older versions report a bad object file format, so static linking starts at Delphi XE2.

  • Delphi XE2 and newer

Prerequisite

Static linking has no effect without the custom Indy library in use.

  • SGC_CUSTOM_INDY defined
Part of sgcWebSockets

An add-on, not a separate order.

sgcCustomIndy attaches to a sgcWebSockets Core licence. It is offered as the first recommended add-on inside a Core order, so you add it with one click while ordering sgcAI, sgcMQ or sgcSocial, and it arrives on the same licence.

Core with sgcCustomIndy

The same custom build Enterprise uses, added during a Core order. Full source code and 1 year of updates.

€149 / developer

Included with sgcAuth and sgcHTTP

The WebAuthn support in sgcAuth and the HTTP/2 and gRPC clients in sgcHTTP require it, so ordering either pack always includes sgcCustomIndy. The pack's listed price already covers it.

Already in Enterprise and All-Access

The custom Indy library is part of sgcWebSockets Enterprise and of eSeGeCe All-Access, enabled by default. If you hold either, there is nothing to add. Standard and Professional use the standard Indy library.

Not the same thing as sgcIndy, the full Indy package you install in place of the Indy in your IDE. Which edition you need

See pricing

Bring the Indy layer up to date.

ALPN and HTTP/2, TLS 1.3 over OpenSSL 1.1.1 and 3.x, and OpenSSL inside the executable on Windows. All of it beside the Indy you already have. The sgcWebSockets trial has the full Enterprise feature set, custom Indy included.

Download the trial Start with sgcWebSockets Core

More for sgcWebSockets Core.

sgcCustomIndy is one of the packs that build on the sgcWebSockets Core runtime. They share conventions, ship with full source code and deploy royalty-free.

sgcWebSockets Core

The runtime bundled into sgcAI, sgcMQ, sgcSocial and sgcCustomIndy: HTTP, TLS, JSON, TCP and UDP. The licence this pack attaches to.

sgcHTTP

HTTP server, HTTP/2 client, gRPC client and Google Cloud Pub/Sub, Calendar and FCM clients. Every sgcHTTP order includes sgcCustomIndy.

sgcAuth

OAuth2 client, JWT client and WebAuthn support. Every sgcAuth order includes sgcCustomIndy.

sgcAI

AI, LLM and MCP components for Delphi and C++ Builder, with the sgcWebSockets Core runtime bundled in.

sgcMQ

MQTT, AMQP 0.9.1 and 1.0, Apache Kafka and STOMP clients, with the sgcWebSockets Core runtime bundled in.

Packs, add-ons and more

Latest from the blog

· Components

Passkeys in Delphi: Passwordless Login With WebAuthn
· Releases

sgcWebSockets 2026.10
· Components

SAML Single Sign-On in Delphi With Entra ID, Okta and AD FS

View all posts →

You are seeing the sgcCustomIndy view of eSeGeCe.

Show me another angle →
30-Day Money-Back GuaranteeNot satisfied? Request a full refund within 30 days of purchase. See refund policy