TLS stack for FreePascal

OpenSSL becomes unnecessary: TlsLib4Pascal is a new library for TLS (the successor to SSL) that provides a fully managed TLS 1.2 and 1.3 stack.

↗https://github.com/Xor-el/TlsLib4Pascal

Licence: MIT, © 2026 Ugochukwu Mmaduekwe

The library implements TLS 1.2 and TLS 1.3 from scratch, without relying on OpenSSL or any OS-level TLS engine such as SChannel (Windows Secure Channel). Because the code is pure Object Pascal, it runs identically on Windows, Linux, macOS, and the BSDs.

Cryptography: ↗CryptoLib4Pascal is the library's only dependency, supplying the actual cryptographic primitives underneath. The crypto backend itself is pluggable through an ICryptoProvider interface, so developers can swap in a different backend if needed.

Architecture: At the core sits a sans-IO engine that owns no sockets, threads, or timers, with three integration tiers built on top of it. Tier 1 is a simple facade called TTlsLib, tier 2 is TTlsStream, a standard TStream that speaks TLS over a two-method transport interface. And tier 3 consists of drop-in adapters for mORMot, Indy, Synapse, and fcl-net. Each adapter plugs into that stack's own SSL seam, so existing code often needs only one new uses clause.

Protocol features: TLS 1.3 uses AEAD-only cipher suites, while TLS 1.2 is restricted to a hardened ECDHE + AEAD profile. Weak options such as CBC-HMAC, RC4, and static RSA key exchange are excluded by design, and post-quantum hybrid key exchange (↗X25519MLKEM768) is enabled by default in every preset.

Trust and verification: The library performs full PKIX path validation, checks hostnames against certificate SANs, and supports certificate pinning alongside both stapled and live OCSP/CRL revocation checks. OS system trust is available as an opt-in package. Throughout, the library fails closed, meaning it will never complete a handshake it cannot verify.

Testing: The library is tested against BoringSSL's BoGo conformance suite, which runs as a required CI gate, as well as against RFC 8448 byte-exact vectors, an OpenSSL interop matrix, and structure-aware fuzzing.

Use cases: TlsLib4Pascal fits any Object Pascal project that needs TLS without an OpenSSL dependency. Typical scenarios:

• HTTPS clients: Standard TFpHttpClient (fcl-web) can do HTTP GET/POST over TLS once the TlsLibFclNetTls adapter unit is linked in. No code changes to the HTTP calls themselves are needed.
• HTTPS servers: TFpHttpServer supports TLS the same way, through its UseSSL and CertificateData properties. This covers small embedded web servers, REST APIs, or admin interfaces.
• FTP/FTPS and other TCP protocols: One forum tester already switched an FTP client from OpenSSL to TlsLib4Pascal and reported success. Any protocol built on Synapse, Indy, or fcl-net sockets can gain TLS the same way.
• mORMot-based services: A one-line global registration (RegisterTlsLib4PascalTls) switches every TCrtSocket connection in a mORMot application to TlsLib4Pascal.
• Custom protocols over raw sockets: Developers who own their own socket layer can drive TTlsStream directly over a small transport interface, or drive the raw sans-IO engine for async/event-loop frameworks.

Running your own server on HTTPS

Certificate and private key: The library does not generate certificates for you. It expects two PEM-encoded inputs: A certificate chain, leaf-first: your server's own certificate, followed by any intermediate certificates. And a private key, matching that leaf certificate. It can be unencrypted, or encrypted with a password supplied separately.

Where these files come from depends on the deployment: Public production servers should use a certificate from a public CA, most commonly free via Let's Encrypt (tools like Certbot or win-acme produce fullchain.pem and privkey.pem directly). Internal or development servers typically use a self-signed certificate, created once with any standard tool (OpenSSL's openssl req command, PowerShell's New-SelfSignedCertificate, or similar). This tool is only used offline to produce the PEM files — it is not a runtime dependency of TlsLib4Pascal itself. PKCS#12/.pfx bundles are also supported, but only through the library's native TTlsPresets ... WithCredentialPkcs12 API, not through TFPHTTPServer.CertificateData, which expects separate PEM files.

One consequence of self-signed certificates: TlsLib4Pascal's client-side PKIX validation will reject them by default, since no public CA backs them. Clients connecting to a self-signed test server must add that certificate as an explicit trust anchor, or — for local testing only, never in production — bypass verification entirely through the library's clearly marked "dangerous" API surface.