wolfSSL 5.9.4 is now available with new cryptographic algorithms, expanded post-quantum support, new hardware ports, significant assembly performance work, and a number of vulnerability fixes. Users are always recommended to stay up to date with wolfSSL releases. In this release the use cases affected by high severity reports are: trusted peer certificates (WOLFSSL_TRUST_PEER_CERT, including builds using OPENSSL_COMPATIBLE_DEFAULTS such as –enable-nginx, –enable-haproxy, –enable-all and –enable-distro), client-side multiple OCSP response stapling (HAVE_CERTIFICATE_STATUS_REQUEST_V2 with WOLFSSL_CSR2_OCSP_MULTI), and client-side Raw Public Keys (–enable-rpk, –enable-all, –enable-distro).

Vulnerabilities
This release addresses 11 CVEs (3 high, 4 medium, 4 low), down from 32 in 5.9.2. Most of them apply only to specific, non-default build configurations or API usage. Highlights include certificate validation fixes for name constraints, trusted peer matching and OCSP/CRL fallback, a (D)TLS 1.2 client ChangeCipherSpec ordering fix, and a session cache reference fix for TLS 1.2 resumption. Thanks to all the researchers who responsibly disclosed issues, including the Anthropic OSS program, Cantina Security, Jorge Milla (Pig-Tail), PathDiff, the Fuzz0x team, Jack Lloyd, Ben Smyth, and several independent contributors.

For the full list of vulnerabilities addressed, visit the wolfSSL Vulnerability Page.

Important Notes

• liboqs is no longer used for any algorithm. Falcon now has a native wolfCrypt implementation, and the liboqs dependency and its configure and CMake options have been removed.

• Certificates carrying trailing bytes after the DER structure are now rejected unless WOLFSSL_NO_ASN_STRICT is defined.

• –disable-tlsv12 now truly compiles TLS 1.2 out, and WC_RNG gains a per-instance lock and fork handlers by default so one RNG can be shared between threads and across fork().

• Under FIPS, HMAC-MD5 is rejected, short AES-GCM IVs return FIPS_BAD_VALUE_E, the CMAC minimum tag is 64 bits, and RSA-PSS salts longer than the hash are refused (FIPS 186-5).

New Features

• New algorithms: Argon2 (RFC 9106) password hashing, AES-GCM-SIV (RFC 8452), KMAC and cSHAKE (SP 800-185), AES Key Wrap with Padding (RFC 5649), and a Time-Stamp Protocol (RFC 3161) implementation.

• –enable-tinytls13 — a TLS 1.3-only footprint profile (PSK + ECDHE floor with optional minimal X.509).

• TLS receive read-ahead (–enable-readahead) to cut the number of recv() calls per record, plus zero-copy AEAD encryption on the send path.

• Runtime policy APIs to require an external PSK in (D)TLS 1.3 and to enforce Extended Master Secret.

• SBOM generation with make sbom (SPDX 2.3 + CycloneDX 1.6) and make bomsh (OmniBOR build provenance) to support EU Cyber Resilience Act compliance.

• WOLFSSL_X509_TINY and WOLFSSL_X509_VERIFY_ONLY certificate parser profiles, and true zero-allocation X.509 verification for WOLFSSL_NO_MALLOC builds.

Post-Quantum Cryptography Updates

• Native Falcon (levels 1 and 5) with crypto callbacks and ARM DSP / AArch64 NEON acceleration, replacing the liboqs wrapper

• FrodoKEM added with C and assembly for x86_64, AArch64, AArch32 and Thumb2, plus ASN.1 keys and X.509 certificates.

• SLH-DSA (FIPS 205) authentication in the TLS 1.3 and DTLS 1.3 handshake for all twelve parameter sets.

• Post-quantum-only TLS 1.3 builds — ML-KEM key exchange with ML-DSA or SLH-DSA authentication and no RSA/ECC/DH.

• ML-DSA for PKCS#7/CMS SignedData (RFC 9882) and in the OpenSSL compatibility layer.

• AVX512 assembly for ML-KEM and ML-DSA, a constant-time ML-DSA low-bits check, and a new –enable-all-quantum-crypto bundle.

TLS and DTLS Improvements

• RFC 9846 (TLS 1.3 update) conformance work, including the general_error alert, key update limits, and NewSessionTicket hardening.

• Extended Key Usage is now enforced on chain-supplied intermediate CAs.

• RFC 5746 renegotiation_info is checked by default on TLS 1.2 clients, and SHA-1 signature schemes are no longer offered by default for TLS 1.2.

• DTLS: rotatable cookie secrets, DTLS 1.2 Connection ID support, stricter peer address handling, and many DTLS 1.3 correctness fixes.

• New dtls_bench DTLS throughput benchmark with an optimized DTLS send path.

Hardware and Embedded Ports

• STM32 bare-metal crypto port (no HAL required) with DHUK (Device Hardware Unique Key) hardware-protected keys, validated on a 27-board reference matrix spanning about 20 STM32 families, plus STM32V8 (Cortex-M85) and STM32CubeMX2 support.

• New ports for the RealTek AmebaPro2, WISeKey/SealSQ VaultIC, Vorago VA416x0 TRNG, and the TI C2000 C28x DSP family.

• SE050/SE05x enhancements including on-chip key generation, SCP03 key rotation and attestation, plus Zephyr, NetX, Renesas, NXP and other port fixes.

Assembly and Performance

• New Intel x64 AES assembly using AVX512/VAES, AVX512 ChaCha20-Poly1305, and AVX512 IFMA X25519/Ed25519.

• AArch64 and ARM32 runtime CPU feature dispatch, new PPC64/PPC32 AES and SHA assembly, and a full RISC-V 64-bit SP implementation.

Build System

• CMake gains ~100 options and 37 application bundles to match autotools.

• Linux and FreeBSD kernel module improvements, and FIPS v7 readiness work.

Rust Wrapper

• Released versions 2.1.0 and 2.2.0 of the wolfssl-wolfcrypt Rust crate, with the dilithium module renamed to mldsa and numerous build-option gating fixes.

Get the Update
Dive into the full ChangeLog for a complete list of changes.

If you have any questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfTPM 4.2.0 centers on TCG TPM 2.0 v1.85 specification compliance in the firmware TPM (fwTPM), expanded post-quantum support up to TLS 1.3 authentication, and new platform backends. The result is a portable, hardware-backed root of trust that is standards-compliant and quantum-ready on hardware ranging from microcontrollers to Linux edge devices.

TPM 2.0 v1.85 Specification Compliance in the fwTPM
The firmware TPM received a broad round of TCG v1.85 conformance work so that it behaves like a certified discrete TPM on the paths used by measured boot and attestation:

• Command-code masking and corrected vendor-bit return codes (PR #556)

• PolicyAuthorize compliance and corrected response codes for the keySign name ticket and approvedPolicy (PRs #567, #572)

• Authenticated object context blobs on ContextSave / ContextLoad (PR #568)

• Rejecting unsupported LoadExternal private types, corrected creation-ticket HMAC ordering, and ML-DSA / ML-KEM template validation in LoadExternal and CreateLoaded (PRs #573, #578)

• NV space authorization validation and v1.85 revision reporting (PR #575)

• Corrected command-attribute reporting, the verified-ticket HMAC algorithm, and SPDM responder version negotiation (PRs #577, #579, #584)

Post-Quantum Authentication for TLS 1.3
v4.2.0 extends post-quantum support from primitives to a complete authentication flow:

• TPM-backed ML-DSA authentication for post-quantum TLS 1.3, with a complete example and tests (PR #559)

• SealSQ QVault post-quantum TPM support (PR #570)

• ML-KEM credential activation and ML-DSA quotes in the fwTPM (PR #592)

The --enable-pqc, --enable-mldsa, and --enable-mlkem build options limit the post-quantum footprint to the operations your product performs.

New Platform and HAL Backends
This release adds two new ways to reach the TPM:

• wolfHAL I2C and SPI backends, enabled with --enable-wolfhal and an application-supplied board.h (PR #562)

• NVIDIA Jetson Orin (Tegra234) OP-TEE firmware TPM, reached through the Linux TPM kernel driver as /dev/tpmrm0 (PR #576)

• Finer per-command-group gating macros in the fwTPM for tighter code-size control (PR #574)

• Caller-supplied policy authorization for firmware upgrade (PR #560)

Also in This Release
ST33 firmware update: corrected Generation 1 manifest sizing with oversized-command rejection (PR #583) and field-upgrade command selection from the TPM command set (PR #586).

Performance: reused transport connections and reduced NV-write and hash-cache overhead (PR #563).

Build and licensing: fixes for AES_BLOCK_SIZE under OpenSSL coexistence (PR #552), TIS-lock builds without wolfCrypt (PR #564), and --enable-pqc with --disable-wolfcrypt (PR #606); refreshed example CA certificates with a refresh script (PR #601); new contribution guidance (PR #569); and a GPLv2 exception allowing wolfTPM combined with U-Boot from Cisco Systems, Inc. to be licensed under GPLv2 (PR #557).

Security Hardening
v4.2.0 includes a security-hardening pass driven by Fenrir, Coverity, static analysis, negative testing, and input-validation review. The changes include hardening of the crypto callback, ASN.1 parsing, parameter encryption, and marshalling (PR #551); bounded response decrypt-parameter sizing with primary-key auth zeroization (PR #555); fixes for a fwTPM response buffer overflow and an SPDM clear-frame command bypass (PR #561); a wolfCrypt refcount race fix in P521 primary derivation and a policy-session authorization-bypass fix (PR #571); transactional fwTPM state changes with hardened PolicyPCR and private-blob wrapping (PR #593); and a further set of fwTPM protocol, key-derivation, zeroization, and bounds fixes (PRs #554, #558, #565, #581, #582, #588, #591, #595, #596, #597, #598, #599, #600, #603, #604, #605, #608).

Getting Started

git clone https://github.com/wolfSSL/wolfTPM.git
cd wolfTPM
git checkout v4.2.0
./autogen.sh
./configure --enable-fwtpm –enable-swtpm
make && make check

The full change log is available in ChangeLog.md.

For commercial licensing, FIPS 140-3 integration, DO-178C DAL A qualification kits, custom HAL ports, or help deploying TPM 2.0 v1.85 post-quantum, contact facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfProvider version 1.2.2 is now available. As an OpenSSL 3.x provider, wolfProvider routes cryptographic operations through the wolfCrypt FIPS 140-3 module, allowing existing OpenSSL applications to gain a FIPS-validated cryptographic core without modifying any application code. This release introduces native Windows support, PKCS#8 private-key encryption, FIPS build hardening, and a high severity security fix for AES-GCM in TLS 1.2.

Windows and Visual Studio 2022 Support
wolfProvider now compiles natively on Windows using Visual Studio 2022, building libwolfprov.dll against OpenSSL 3.x and wolfSSL configured via user_settings.h. Both non-FIPS and FIPS configurations are fully supported, bringing the same integration Linux users rely on directly to Windows environments.

PKCS#8 Private-Key Encryption
The PKCS#8 encoder now encrypts private keys whenever a cipher is assigned on the PrivateKeyInfo encoder. This ensures encrypted PKCS#8 output works smoothly through the provider as callers expect. This update also tightens PKCS#8 feature guards and expands cipher-rejection test coverage.

FIPS and Interoperability Enhancements

• Restored the default FIPS policy mask in WOLFSSL_USER_SETTINGS builds, added portable FIPS CAST-mutex initialization, and balanced wolfCrypt init and cleanup calls.

• Stopped advertising SHA-512/224 and SHA-512/256 in FIPS and self-test builds.

• Matched OpenSSL’s ML-KEM NULL output handling.

• Expanded hostap smoke tests and EAP test coverage in CI.

Additional fixes, including X25519 public-key length validation and buffer sizing for ECX/ECC get_params, can be found in the included ChangeLog.

Security Fixes
CVE-2026-81019, AES-GCM Explicit Nonce Reuse on TLS 1.2 and DTLS 1.2

Severity, High. Affects wolfProvider 1.0.0 through 1.2.1.
The 8-byte explicit nonce was generated when setting up the fixed IV, but it did not increment for subsequent records. Because successive AES-GCM records within the same encryption context reused the exact same key and nonce pair, confidentiality was weakened by repeated keystreams and integrity was vulnerable to authentication tag forgery. TLS 1.3, and non-TLS uses of AES-GCM are unaffected. This impacts wolfProvider versions 1.0.0 through 1.2.1 across both FIPS and non-FIPS builds.

Download and Upgrade
Anyone running TLS 1.2 or DTLS 1.2 with AES-GCM through wolfProvider should update to 1.2.2 immediately.

You can find the release on GitHub at https://github.com/wolfSSL/wolfProvider alongside the full ChangeLog.

For questions on wolfProvider, FIPS 140-3, or commercial licensing, reach out to facts@wolfssl.com. For direct technical assistance, contact support@wolfssl.com.

Download wolfSSL Now

wolfTPM v4.1.0 delivers the post-quantum upgrade path we promised in v4.0.0, alongside a major round of firmware TPM (fwTPM) hardening. It delivers three headline capabilities:

• TPM 2.0 v1.85 Post-Quantum Cryptography: ML-DSA and ML-KEM native and in the fwTPM.

• fwTPM Hardening: Dictionary Attack protection to the TCG spec, SPDM secured transport, and session, policy, and NV fixes.

• Runtime TPM Locality Control: select locality 0-4 at runtime with a single API call.

All of it runs on the same wolfCrypt engine trusted in FIPS 140-3 and DO-178C DAL A deployments.

Feature 1: TPM 2.0 v1.85 Post-Quantum Cryptography
v4.0.0 shipped with post-quantum support listed as coming soon. It is here. The fwTPM now implements the TPM 2.0 v1.85 post-quantum algorithms: ML-DSA sign/verify and ML-KEM encapsulate/decapsulate, with seed handling to TCG Phase B, ML-DSA primary keys via TPM2_CreateLoaded, PQC parameter encryption in the examples, and dedicated PQC CI and fuzz coverage.

Build Only What You Use
Post-quantum keys and code are large, so v4.1.0 adds layered build macros to trim the PQC footprint to the operations you actually perform:

--enable-pqc                          # lean ML-DSA + ML-KEM subset
--enable-mldsa[=all|sign-only|verify-only|no]
--enable-mlkem[=all|enc|dec|no]
--disable-hash-mldsa

–enable-pqc now selects the lean PQC subset, while –enable-v185 remains the full specification build. Per-algorithm (WOLFTPM_MLDSA, WOLFTPM_MLKEM) and per-operation macros each have a matching WOLFTPM_NO_* opt-out. New _ex session, OAEP, and PQC-hash wrappers round out the API, and the build enforces a wolfSSL v5.8.0+ PQC floor with upstream-drift CI.

Feature 2: fwTPM Hardening
The firmware TPM introduced in v4.0.0 received a major round of work to close the gap with discrete hardware.

Dictionary Attack Protection to the TCG Spec

• noDA honored on objects (TPMA_OBJECT_noDA), not just NV indices.

• failedTries persisted in NV, including the non-orderly-shutdown +1 penalty.

• recoveryTime self-heal and separate lockoutRecovery, with DA properties reported via TPM2_GetCapability.

• New wrappers wolfTPM2_DictionaryAttackLockReset and wolfTPM2_DictionaryAttackParameters, a da_check example, and a CI retry harness.

Sessions, Policy, and NV

• Transient state kept across command-port reconnects.

• continueSession set in the password-auth response, and PolicyAuthorize zero-ticket handling.

• Append-only NV journal for write-once flash ports.

• Optional transparent TPM_RC_RETRY handling for TPMs that momentarily report busy. Opt in via TPM2_SetCommandRetries or -DWOLFTPM_MAX_RETRIES=N.

• SPDM secured transport extended to the fwTPM, and FIPS 140-3 capability reporting.

Feature 3: Runtime TPM Locality Control
TPM locality lets a platform distinguish measurements made by trusted early boot code (DRTM) from ordinary software. The new wolfTPM2_SetLocality(dev, locality) API selects locality 0-4 at runtime, and the PCR reset example takes a -loc=n flag. It works on the TIS/SPI driver and the fwTPM over socket and TIS/SHM; platforms without a locality interface cleanly return NOT_COMPILED_IN.

The fwTPM per-PCR locality enforcement was replaced with a single source-of-truth table matching the TCG PC Client profile. Behavior change: DRTM PCRs 17-22 can no longer be extended from locality 0, exactly as the specification requires.

Other v4.1.0 Release Improvements

• New crypto-primitive examples (getrandom, hash, AES, ECDH) and a WOLFTPM2_ECC_DEFAULT_CURVE option.

• Optional hardware-reset HAL: –enable-hal-reset pulses the nRST line via the Linux GPIO char device.

• Freestanding builds via WOLFTPM_NO_STD_HEADERS for bare-metal targets without a standard C library.

• SBOM generation (make sbom): CycloneDX and SPDX documents for EU Cyber Resilience Act (CRA) compliance.

• Fixed TPM_CAP_ALGS / TPM_CAP_COMMANDS capability paging, and Nations NS350 example fixes.

• Extensive security hardening: automated Fenrir review, Coverity fixes across the fwTPM paths, and CodeQL/Semgrep review gates.

• CI and build improvements: expanded CMake tests, a GHCR container image, and nightly fuzzing.

Getting Started

git clone https://github.com/wolfSSL/wolfTPM.git
cd wolfTPM
git checkout v4.1.0
./configure --enable-fwtpm --enable-pqc
make && make check

• Release notes: github.com/wolfSSL/wolfTPM/releases/tag/v4.1.0

• Changelog: ChangeLog.md

• Examples: examples/ directory, including the new da_check, PCR-locality, and crypto-primitive demos.

For commercial licensing, FIPS 140-3 integration, DO-178C DAL A qualification kits, custom HAL ports, or help deploying TPM 2.0 v1.85 post-quantum, contact facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

We are excited to announce the first stable release of wolfCOSE 1.0.0, a complete, zero-allocation C implementation of CBOR (RFC 8949) and COSE (RFC 9052/9053) built on top of wolfCrypt. wolfCOSE brings standards-based signing, encryption, and authentication of CBOR data to even the smallest embedded targets, with a tiny footprint, no dynamic memory, and a clear path to FIPS 140-3.

What is COSE?
COSE (CBOR Object Signing and Encryption) is the compact, binary counterpart to JOSE/JWT. Where JOSE secures JSON, COSE secures CBOR, the concise binary data format used across IoT, firmware update (SUIT), attestation (EAT), W3C WebAuthn, and digital credentials. COSE is the cryptographic message format of choice when every byte and every allocation counts, which makes it a natural fit for the constrained devices wolfSSL has always targeted.

A complete COSE implementation
wolfCOSE 1.0.0 implements all six COSE message types from RFC 9052, in both single-actor and multi-actor forms:

• COSE_Sign1 / COSE_Sign: single-signer and multi-signer signatures

• COSE_Encrypt0 / COSE_Encrypt: single-recipient and multi-recipient encryption

• COSE_Mac0 / COSE_Mac: single-key and multi-recipient authentication

It ships with its own dependency-free CBOR engine (RFC 8949) that enforces deterministic/preferred encoding and rejects non-preferred or trailing input on decode, plus full COSE_Key / COSE_KeySet serialization, including complete RFC 8230 RSA private keys.

40 algorithms, including post-quantum
wolfCOSE 1.0.0 supports 40 algorithms across signing, encryption, MAC, and key distribution (RFC 9053):

• Signing: ES256/384/512, EdDSA (Ed25519/Ed448), PS256/384/512

• Encryption: AES-GCM (128/192/256), AES-CCM variants, ChaCha20-Poly1305

• MAC: HMAC-SHA256/384/512, AES-MAC

• Key distribution: Direct, AES Key Wrap, ECDH-ES + HKDF

• Post-quantum: ML-DSA-44/65/87

Of particular note is standardized post-quantum signing: wolfCOSE implements ML-DSA (FIPS 204) at all three security levels, conformant to RFC 9964 (“ML-DSA for JOSE and COSE”), using the RFC 9964 AKP key type. This lets you sign and verify CBOR objects with quantum-resistant signatures today, using the canonical, standards-track encoding.

Built for embedded: zero allocation, tiny footprint
wolfCOSE was designed from the start for deeply embedded use:

• Zero dynamic allocation. Every operation uses caller-provided buffers, with no heap and no hidden .data or .bss. Memory use is deterministic, which matters for safety-critical and FIPS deployments.

• Tiny footprint. An ES256 COSE_Sign1 build is roughly 5.1 KB verify-only and 6.8 KB sign + verify for the wolfCOSE COSE + CBOR engine.

• Lean configuration layer. WOLFCOSE_LEAN, WOLFCOSE_HAVE_* feature gates, verify-only profiles, and a bounded-stack WOLFCOSE_MIN_BUFFERS mode let you compile in only what you need. Verify-only ECC images link cleanly against sign-disabled wolfCrypt.

Quality and standards

• Path to FIPS 140-3 through wolfCrypt FIPS Certificate #4718. wolfCrypt is wolfCOSE’s sole cryptographic dependency.

• MISRA C:2012 and C:2023 checked.

• Extensively tested: ~240 algorithm-combination round-trips, static analysis (cppcheck, Clang analyzer, GCC -fanalyzer, Coverity), CodeQL and Semgrep security scanning, ASan/UBSan sanitizers, and a wolfCOSE ? t_cose wire-interop conformance suite.

• Standards implemented: RFC 8949 (CBOR), RFC 9052/9053 (COSE), RFC 8230 (RSA keys for COSE), and RFC 9964 (ML-DSA for JOSE and COSE).

Getting wolfCOSE
wolfCOSE requires wolfSSL 5.8.0 or later as its crypto backend (post-quantum ML-DSA requires wolfSSL 5.9.2 or later). It is a Makefile-only project whose only dependency is wolfCrypt. Run make, make test, and you are running.

Source: https://github.com/wolfSSL/wolfCOSE
Release: https://github.com/wolfSSL/wolfCOSE/releases/tag/v1.0.0
Documentation: see the project README and wiki

wolfCOSE is dual-licensed under GPLv3 and a commercial license. If you are building a product and need commercial licensing, FIPS, or support, please reach out.

Have questions, or want to tell us about your COSE use case? Contact us any time at facts@wolfssl.com or support@wolfssl.com, or call +1 425 245 8247. We would love to hear what you are building.

Download wolfSSL Now

wolfCLU release 0.2.0 is now available. Major feature additions were added; dual-algorithm certificates, a full OCSP client/responder, a cross-platform test suite, and a large round of security hardening.

Highlights:

• Chimera (dual-algorithm) certificates. wolfCLU can now generate Chimera certificates carrying both a conventional and a post-quantum signature on a single X.509 cert, so one certificate satisfies both classical and PQC-aware verifiers. (PR 182, @Yu-Ma28051503)

• OCSP client and responder. New OCSP client and responder, both with HTTP and SCGI transports. SCGI lets the responder be fronted by nginx in production. (PR 200, @julek-wolfssl)

• Cross-platform Python tests. The shell-based test suite was ported to Python (unittest), so it now runs on Windows in addition to Linux and macOS. (PR 215, @julek-wolfssl)

• Explicit key files for enc. The enc command now accepts an explicit key file instead of deriving the key from a password. (PR 224, @embhorn)

Security Hardening:
A large set of fixes from static analysis using wolfSSL internal Fenrir project: out-of-bounds writes in argv processing, a stack buffer overflow in encryption setup, a shell command injection, a use-after-free, a potential double-free, a heap buffer over-read, plus numerous null-pointer and sanity-check fixes across command and init paths. (PRs 202–223; @miyazakh, @aidangarske, @JacobBarthelmeh, @yosuke-wolfssl, and others)

Other Changes:
ML-DSA sign/verify now passes a context for OpenSSL interop (PR 195), the post-quantum groups list was updated to match the latest wolfSSL (PR 209), and there were assorted fixes to the enc, pkey, req, and ECC sign/verify paths along with expanded test coverage and README updates. See the full commit log for details.

Download wolfCLU now and contact facts@wolfssl.com for any questions.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfCrypt JNI/JCE 1.10.0 is now available for download! This release brings new JCE Cipher support for RSA OAEP padding schemes and RSA key wrapping (WRAP/UNWRAP modes), a PKIX CertPathBuilder implementation using native wolfSSL X.509 functionality, default FIPS error callback registration, new JNI utilities for hex string conversion and PEM-to-DER, enhanced WolfSSLX509StoreCtx methods, and two new system properties for flexible native library loading and OCSP/CRL timeouts. Along with these additions, 1.10.0 delivers extensive bug fixes, memory-safety improvements, FIPS compliance enhancements, and an expanded testing matrix.

New JCE Functionality:

• Add Cipher RSA/ECB/OAEPWithSHA-256AndMGF1Padding support

• Add Cipher RSA/ECB/OAEPWithSHA-1AndMGF1Padding support

• Add Cipher WRAP_MODE and UNWRAP_MODE support for RSA-based key wrapping

• Add PKIX CertPathBuilder implementation using native wolfSSL X509_STORE

• Add jdk.certpath.disabledAlgorithms enforcement to CertPathBuilder and CertPathValidator

• Register default FIPS error callback in WolfCryptProvider for FIPS error debugging

• Enrich WolfCryptException with FIPS module status for FIPS_NOT_ALLOWED_E errors

• Add Java 9+ module support (JPMS) for jlink compatibility

New JNI Functionality:

• Add hex string conversion via WolfCrypt.toHexString() and WolfCrypt.hexStringToByteArray()

• Add PEM to DER conversion support for keys and certificates

• Add setFlags() and setVerificationTime() methods to WolfSSLX509StoreCtx

New Property Support:

• wolfssl.skipLibraryLoad System property – Skip automatic System.loadLibrary() calls for advanced embedding scenarios

• wolfjce.ioTimeout System property – Configure OCSP/CRL IO timeouts

Bug Fixes & Reliability Improvements
Beyond the new features, version 1.10.0 includes a substantial set of bug fixes and reliability improvements focused on FIPS error visibility, cryptographic correctness, input validation, and memory safety:

• Fixed FIPS error callback lifecycle (including proper deregistration in JNI_OnUnload)

• Corrected Ed25519 signature length handling, RSA public-key flattening/export, unsigned return values, and pointer casts

• Added HMAC/ByteBuffer/offset-length bounds validation, improved NULL checks, and missing releaseByteArray() calls across ECC, RSA, ChaCha, and AES-GCM

• Implemented defensive copies of IV arrays, constant-time GMAC tag verification, secure zeroization of keys and buffers, and proper cleanup for AES-CTR/AES-OFB/GMAC

• Fixed signed integer overflow risks in bounds checks, DH key export paths, ECC private-key import curve handling, and reduced unnecessary WC_RNG allocations

• Expanded FIPS-compliant SecureRandom sanitization and fixed threaded MessageDigest hangs on FIPS errors

Expanded Testing & CI Infrastructure
CI coverage has been expanded with new workflows and modern platform support:

• Java 24 and 25 tests added to GitHub Actions workflows

• Linux 32-bit testing with Java 17 via GitHub workflow

• UndefinedBehaviorSanitizer (UBSan) GitHub workflow

• SpotBugs static analysis target and dedicated GitHub Actions workflow

• Android FIPS Ready automated emulator testing via GitHub workflow

• Java 9+ module (JPMS) testing workflow

• Improved JUnit test reliability for FIPS mode and CI environments

New Examples

• Added CertPathBuilder and CertPathValidator example demonstrating PKIX path building and validation with disabledAlgorithms enforcement

• Updated Android example project: migrated from jcenter() to mavenCentral() and AndroidX, added Gradle wrapper with distributionSha256Sum, JKS-to-BKS KeyStore conversion script for testing, and CMakeLists.txt exclusion list updates

wolfCrypt JNI/JCE 1.10.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. Full details on this release can be seen in the ChangeLog.md on GitHub. For any questions, or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfTPM v4.0.0 is our largest release to date. It delivers three headline capabilities:

• Firmware TPM (fwTPM) – a portable TPM 2.0 built on wolfCrypt.

• SPDM Secured Transport – encrypted host-to-TPM communication.

• ST33 TPM 2.0 Firmware Update – new update tool for STMicro ST33KTPM2X.

All three are powered by the same wolfCrypt engine trusted in FIPS 140-3 and DO-178C DAL A deployments.

Feature 1: Firmware TPM (fwTPM)
The fwTPM is a portable TPM 2.0 command processor. It is implemented entirely on top of wolfCrypt. It covers 105 of 113 commands in the TPM 2.0 v1.38 specification (93%). The full object, session, policy, attestation, PCR, and NV families are included.

Use it as a drop-in replacement for a discrete TPM chip. Or use it in CI as a replacement for external simulators like the Microsoft TPM simulator and IBM swTPM.

Why It Matters

• Reduce BOM and physical attack surface. Parts that never shipped with a TPM can now gain TPM services. No extra chip. No exposed bus.

• Portability. The same fwTPM runs on a Cortex-M in TrustZone, a dedicated RPU on an MPSoC, a hardened RISC-V core, or an FPGA soft core.

• Supply-chain integrity. Your TPM becomes part of your signed firmware image. No separate silicon vendor in the trust path.

• Same crypto you already trust. RSA, ECC, SHA-2/3, AES, and HMAC all come from the FIPS 140-3 wolfCrypt module, qualifiable to DO-178C DAL A for avionics.

Where fwTPM Runs

fwTPM is designed to live in an isolated execution environment. Proven homes include:

• Microchip PolarFire SoC (MPFS250T) – Run in FPGA with Mi-V RISC-V soft-core or run in a dedicated core (E51 Monitor or U54)

• Arm TrustZone-M. Reference port on STMicro STM32H5 (NUCLEO-H563ZI). TrustZone-M gives isolated code, data, flash, and crypto peripherals.

• AMD/Xilinx Zynq UltraScale+ MPSoC and Versal Gen 1 / Gen 2. Multiple deployment options on the same part: Arm TrustZone on the APU, a dedicated Cortex-R5F (UltraScale+) or R52 (Versal Gen 2) on the RPU, or a MicroBlaze V (RISC-V) soft core.

• AMD Spartan UltraScale+ (MicroBlaze V or Cortex-M1 soft core)

• Altera Agilex 5 (Nios V soft core). TPM functionality entirely inside programmable logic.

Integration

• Transports: Socket mssim or swtpm (auto detected), shared memory IO and register-level TIS for bare-metal SPI, I2C or UART.

• NV storage: File-backed on hosted systems. HAL callback for embedded flash. TLV journal format suits wear-levelled flash.

• Footprint knobs: Features can be disabled if not required to reduce code size. Attestation, Policy, NV, Credential, Dictionary Attack.

Feature 2: SPDM Secured Transport
When a TPM speaks to its host over a PCB trace, that trace is attackable. SPDM closes the gap. Commands and responses ride over a vendor-defined TCG channel. The channel is encrypted with AES-256-GCM and integrity-checked on every packet.

What’s New

• Vendors: Nuvoton NPCT75x and Nations Technologies NS350. (More coming soon)

• Session modes:
  

  • Identity-key mode over ECDH P-384, on both NPCT75x and NS350.

  • PSK mode on NS350.

• Auto-connect with SPDM-only lock-down. Once locked, wolfTPM establishes the encrypted session on every open. Plaintext commands are rejected.

• New spdm_ctrl utility. Full lifecycle: enable, disable, provision PSK, clear PSK, lock, unlock.

Why It Matters
Anywhere the TPM is physically accessible – servers in colocation, defense platforms, medical devices, industrial controllers, in-vehicle ECUs – SPDM closes the last-inch attack surface.

Feature 3: ST33 TPM 2.0 Firmware Update
STMicro’s ST33KTPM2X introduced a new Generation 2 firmware format using LMS signing. wolfTPM v4.0.0 adds the st33_fw_update example tool for supporting firmware updates on older Gen 1 and newer Gen 2 firmware versions. See examples/firmware/README.md for usage.

Other v4.0.0 Release Improvements

New HALs

• Raspberry Pi 4 hardware SPI

• U-Boot (tpm_io_uboot.c)

• Espressif ESP-IDF SPI

• Linux auto-detection between /dev/tpmX and direct SPI

Hardening

• Fenrir and Coverity findings addressed across tpm2_wrap, tpm2_packet, tpm2_asn, NV, session auth, SPDM, and fwTPM paths.

• ForceZero on every sensitive stack buffer.

• Constant-time export for ECDH shared secrets and ECC signature r/s.

• Short-circuit OR removed from all auth paths.

• Bounds checks and NULL-deref guards across ASN.1, PCR, and key-load code.

CI

• ASan and UBSan sanitizer jobs.

• Pedantic gcc and clang matrices.

• macOS and Windows fwTPM builds.

• Weekly libFuzzer plus per-PR smoke.

Coming Soon: TPM 2.0 v1.85 Post-Quantum

Right behind this release. Post-quantum algorithms from TPM 2.0 v1.85 are landing in both the fwTPM server and the wolfTPM client library:

• ML-KEM (Kyber) for key encapsulation

• ML-DSA (Dilithium) for signatures

Why now? Harvest-Now-Decrypt-Later (HNDL) mitigation for long-lived device identity keys. Deploy fwTPM today. Get a drop-in PQC upgrade path without respinning silicon.

Getting Started

git clone https://github.com/wolfSSL/wolfTPM.git
cd wolfTPM
git checkout v4.0.0
./configure --enable-fwtpm
make && make check

• Source and tag: https://github.com/wolfSSL/wolfTPM (tag v4.0.0)

• Changelog: ChangeLog.md

• fwTPM deep-dive: src/fwtpm/README.md

• SPDM deep-dive: src/spdm/README.md

• ST33 firmware update: examples/firmware/README.md

For commercial licensing, FIPS 140-3 integration, DO-178C DAL A qualification kits, custom HAL ports, or early access to the v1.85 PQC branch, contact facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSH v1.5.0 is now available! This release brings additional post-quantum hybrid key exchange algorithms, a broad hardening pass across the code base, and a large number of bug fixes. There is also one low-severity vulnerability fix in this release affecting wolfSSHd on Windows when handling an edge case in terminal resize messages received from an authenticated connection.

Please see the ChangeLog.md for full details.

New Features
The headline addition in v1.5.0 is post-quantum key exchange via ML-KEM hybrid algorithms — mlkem1024nistp384-sha384 and mlkem768x25519-sha256 — based on draft-ietf-sshm-mlkem-hybrid-kex, with interoperability testing against OpenSSH running in CI. This brings wolfSSH in line with the industry direction toward quantum-resistant SSH.

On the algorithm side, client-side rsa-sha2-512 signature support has been added. The key type is now separated from the signature type, so ssh-rsa keys can be used with ssh-rsa, rsa-sha2-256, or rsa-sha2-512 signatures, improving compatibility with modern SSH servers that have deprecated the older scheme.

Two handy SFTP client usability improvements also landed: lcd and lls commands for managing the local working directory without leaving an SFTP session.

Improvements
Several handlers that previously lacked proper callback validation have been tightened: host key acceptance, channel open requests, TCP/IP forwarding, and DH group exchange parameters are all now gated and validated. Additional defensive constant-time comparisons were also applied.

Beyond hardening, SFTP reliability saw meaningful attention – better non-blocking behavior, improved error path handling, and more robust multi-byte password support. CI coverage was expanded significantly with new sanitizer builds, multi-compiler testing, and automated Coverity scanning.

Fixes
This release contains a large number of bug fixes driven by static analysis and code review. Highlights include a non-blocking SFTP server hang on WS_WANT_WRITE, Windows authentication issues, missing hash cleanup in RSA/ECC paths, and a variety of null-dereference, bounds-check, and memory-leak fixes throughout the codebase.

Download wolfSSH v1.5.0 from our download page, or clone it from GitHub.

If you have questions about wolfSSH or any of our other products, feel free to reach out at facts@wolfssl.com or support@wolfssl.com, or give us a call at +1 425 245 8247.

Download wolfSSL Now

We are excited to announce the release of wolfIP 1.0.0, the first public release of wolfSSL’s lightweight TCP/IP stack for embedded, real-time, and safety-critical systems. wolfIP is built around a simple idea: networking behavior should be defined before runtime, not discovered during it. With no dynamic memory allocation, fixed socket tables, pre-allocated packet buffers, and a deterministic execution model, wolfIP gives developers a compact and analyzable network stack for systems where predictability matters. Version 1.0.0 is listed on the official wolfIP product page and changelog dated March 31, 2026.

Why wolfIP
Traditional TCP/IP stacks often bring in dynamic allocation, background processing, and broader feature sets than many embedded endpoints actually need. That flexibility can be useful in general-purpose systems, but it also makes worst-case timing, memory usage, and verification harder to bound. wolfIP takes a different approach. It is designed as a tiny, deterministic stack with compile-time configured resources, a fixed socket count, static RX/TX packet buffers, and no hidden runtime allocation. That makes it a strong fit for constrained devices, controlled deployments, and projects with demanding review, testing, or certification workflows.

What is included in 1.0.0
The 1.0.0 release delivers a solid IPv4 networking foundation for embedded endpoints. Core support includes Ethernet II, ARP, IPv4, ICMP, UDP, TCP, DHCP client, and DNS client, along with modern TCP capabilities such as MSS, timestamps, PAWS, window scaling, retransmission timeout handling, SACK, slow start, congestion avoidance, and fast retransmit. wolfIP 1.0.0 also includes HTTP/HTTPS server support, IPsec ESP transport mode, IP filtering with wolfSentry integration, native wolfGuard support, and optional IPv4 forwarding for multi-interface builds.

That combination is important because it gives developers more than just a packet pipe. wolfIP 1.0 starts with the network services many connected devices actually need, then adds security-focused integration points across the wolfSSL ecosystem. Developers can combine wolfIP with wolfSSL for TLS 1.3-protected applications, wolfSentry for filtering and policy enforcement, and wolfGuard where a tightly integrated secure tunnel model is needed. For teams building secure connected products, that means a more cohesive networking and security story from a single vendor and codebase family.

Small footprint, practical deployment model
wolfIP is positioned as a small embedded-first stack, and the official product material describes the core as roughly 4× smaller than lwIP’s core. Just as important, wolfIP’s architecture is intentionally narrow and easier to analyze: deterministic memory usage by default, fixed compile-time resources, and an endpoint-focused design rather than a broad general-purpose routing stack. For organizations thinking about code review effort, qualification scope, or long-term maintenance, reducing moving parts matters.

From POSIX testing to embedded targets
One of the most useful aspects of wolfIP 1.0 is its portability across development and deployment environments. The release includes integration layers for wolfSSL, wolfSSH, wolfMQTT, a POSIX LD_PRELOAD socket interception path via libwolfip.so, and a FreeRTOS BSD socket wrapper. The repo also documents host-side testing through TAP-style interfaces and lists host link driver support for Linux TAP/TUN, Darwin utun, FreeBSD TAP, and VDE2, alongside embedded ports for targets including STM32H753ZI, STM32H563, STM32N6, VA416xx, and Raspberry Pi Pico USB networking demos. That is a practical release story: developers can exercise the stack on desktop-class environments, then carry the same architecture into embedded deployment.

Built to Work Naturally with wolfSSL
wolfIP is especially compelling when paired with the rest of the wolfSSL portfolio. The product page highlights seamless TLS 1.3 integration with wolfSSL, and the repository documents HTTPS server support with wolfSSL TLS backing. For engineering teams that already trust wolfSSL in embedded and RTOS environments, wolfIP extends that same design philosophy down into the transport layer: compact code, explicit resource control, and predictable behavior. Instead of stitching together unrelated networking and crypto components, developers can build on a tightly aligned stack designed for constrained and security-conscious systems.

Available Now
wolfIP 1.0.0 is available now under the GPLv3 open source license. If you are building connected embedded devices and need a TCP/IP stack with bounded memory usage, deterministic behavior, and straightforward integration with wolfSSL security products, wolfIP is well worth a look. Download the latest release, review the changelog, and contact us to discuss commercial licensing, support, or how wolfIP fits into your next embedded networking design.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

We are excited to announce that wolfSSL version 5.9.0 is now available! wolfSSL 5.9.0 brings a strong focus on advancing post-quantum cryptography support, an expanded Rust wrapper, new hardware platform integrations, and a number of security vulnerability fixes.

Security Fixes
wolfSSL 5.9.0 includes fixes for 15 security vulnerabilities spanning a range of severity levels, covering areas including CRL parsing, TLS 1.3 ECH extension handling, ALPN parsing, PKCS7 encoding, the packet sniffer, and side channel hardening of post-quantum implementations on ARM Cortex-M. We would like to thank all external researchers who responsibly disclosed issues to us. For full details on each vulnerability please visit the wolfSSL Security Vulnerabilities page.

Post-Quantum Cryptography: SLH-DSA and More
Post-quantum cryptography continues to be a major area of focus in the security industry. In this release there is an addition of SLH-DSA (FIPS 205) — the Stateless Hash-Based Digital Signature Standard — rounding out wolfSSL’s coverage of all three NIST post-quantum digital signature standards alongside ML-DSA and FALCON.

SLH-DSA is a stateless, hash-based signature scheme that provides strong security guarantees without relying on the hardness of lattice problems. It offers an alternative signature foundation for deployments that want to diversify their post-quantum strategy beyond lattice-based approaches. With this addition wolfSSL now supports the full NIST PQC signature portfolio: ML-DSA (FIPS 204), FALCON, and SLH-DSA (FIPS 205), as well as the stateful hash-based schemes LMS/HSS and XMSS/XMSS^MT for specialized use cases.

Beyond SLH-DSA, this release also brings a range of improvements across the existing PQC stack:

• ML-DSA improvements — Several bug fixes including a fix for ML-DSA verification when using WOLFSSL_DILITHIUM_SMALL, improved no-malloc build support, and PKCS#11 integration for ML-DSA key operations.

• ML-KEM improvements — Bug fixes and hardening across no-malloc builds, static memory handling, DTLS 1.3 cookie and ClientHello fragment handling, and expanded hybrid/individual ML-KEM level test coverage.

• Fault injection hardening for PQC on Cortex-M — New protection for ML-KEM and ML-DSA implementations on ARM Cortex-M, specifically guarding against fault injection attacks targeting Keccak-based seed expansion.

• General WOLFSSL_NO_MALLOC PQC support — Broader no-malloc improvements make PQC algorithms more accessible in deeply embedded environments.

• SLH-DSA and FALCON key-type detection fixes — Corrected the key variant identification logic in both the SLH-DSA (SPHINCS+) and FALCON signature algorithm implementations.

New Features

• OCSP Responder API — wolfSSL can now act as an OCSP responder. A new API and supporting infrastructure have been added to serve certificate status responses, enabling wolfSSL to be used in PKI infrastructure roles beyond the TLS client and server. (PR 9761)

• AES CryptoCB Key Import — Added AES key import support via the crypto callback interface, making it easier to use externally managed AES keys through wolfSSL’s callback framework. (PR 9658)

• RNG Bank Facility — New wc_rng_new_bankref() API allows multiple wolfCrypt contexts to share a seeded RNG pool, reducing the overhead of repeated seeding at runtime — particularly useful in resource-constrained embedded systems. (PR 9616)

Rust Wrapper Expansion
The wolfSSL Rust wrapper received significant expansion in this release, gaining FIPS support and coverage for a large number of new cryptographic primitives. New modules were added for Dilithium/ML-DSA, ChaCha20-Poly1305, Curve25519, BLAKE2, LMS, and ML-KEM. Improvements were also made for RSA, ECC, HASH-DRBG, HMAC-BLAKE2, and XChaCha20-Poly1305, along with support for optional heap and device ID parameters and conditional compilation based on underlying C build options.

TLS/DTLS Improvements
TLS 1.3 now supports Brainpool curves for key exchange (PR 9701). DTLS retransmission handling has been improved and TLS message order checking has been hardened on both client and server sides. The MAC and hash comparisons in the TLS 1.3 and TLS 1.2 Finished messages were also strengthened. Additional improvements include an extended AIA (Authority Information Access) interface, better ECH (Encrypted Client Hello) handling, and a range of smaller robustness fixes across fragmentation, session ticket lifetime validation, and QUIC transport parameter handling.

Kernel Module Updates
The Linux kernel module received various fixes and enhancements for Tegra kernels, including support for offline FIPS hash calculation. The FreeBSD kernel module gained both FIPS support and x86 hardware crypto acceleration in this release, broadening wolfCrypt’s kernel-mode footprint across operating environments.

Ports and Hardware Integration
New platform support in 5.9.0 includes the Renesas SK-S7G2 board, STM32 HMAC hardware acceleration, and STM32G0 hardware crypto. Various Thumb2 AES and SP assembly optimizations were added or fixed, and Zephyr 4.1+ compatibility was added for the wolfssl_tls_sock sample application.

PKCS Improvements
This release adds PKCS7 ECC raw sign callback support, RSA-PSS support for SignedData, and RSA-PSS certificate support for PKCS7 EnvelopedData KTRI. Several PKCS7 parsing fixes were also included, along with expanded ML-DSA support via PKCS#11.

Testing and CI Improvements
Test coverage was expanded with a particular focus on PQC and CMake builds. The CI test matrix grew to include rng-tools 6.17, openldap 2.6.9, and bind 9.20.11. A new TLS Anvil interoperability test workflow was added, and a stateful port-tracking mechanism was implemented to eliminate test port collisions during high-concurrency CI runs.

For a full list of fixes and optimizations, check out the ChangeLog.md bundled with wolfSSL. Download the latest release from the download page. If you have any questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL JNI/JSSE 1.16.0 is now available for download!  This release contains a number of bug fixes and changes to the JNI and JSSE layers.

wolfSSL JNI/JSSE allows for use of the native wolfSSL SSL/TLS library from Java. The thin JNI wrapper can be used for direct JNI calls into native wolfSSL, or the JSSE provider (wolfJSSE) can be registered as a Java Security provider for integration underneath the Java Security API. wolfSSL JNI/JSSE provides TLS 1.3 support and can also support running on top of the wolfCrypt FIPS 140-3 validated cryptographic module.

Highlights from this release are below. See ChangeLog.md for a full list.

Java System and Security Property Support:
This release improves alignment with Java JSSE behavior and improves drop-in compatibility for applications migrating from other JSSE providers.

• New wolfjsse.autoSNI security property for controlling automatic SNI behavior with automatic SNI configuration for HttpsURLConnection

• Partial support for jdk.tls.client.SignatureSchemes and jdk.tls.server.SignatureSchemes

• Java Module System (JPMS) compatibility via ServiceLoader support

• Added X509Certificate getSubjectX500Principal() and getIssuerX500Principal() implementations

• Added Android non-standard checkServerTrusted() in X509TrustManager

DTLS 1.3 and Session Enhancements
This release adds DTLS 1.3 support in SSLContext and SSLEngine classes, along with:

• DTLS Connection ID (CID) support

• New DTLS 1.3 example client and server applications

• Session serialization and persistence support via wrapped native APIs

These enhancements enable secure datagram-based applications with session resumption.

Performance Improvements
Several changes focus on reducing overhead in high-throughput and highly concurrent environments:

• 20–30% SSLEngine send/receive performance improvement

• Reduced synchronization and contention in JSSE components

• Cached system and security properties to avoid repeated lookups

• ByteBuffer pooling and improved ByteBuffer handling in JNI paths

• Cached KeyStore entries for improved scalability under load

Correctness, Stability, and Security Fixes

• Fixes for potential use-after-free conditions and memory leaks

• Improved protection of native WOLFSSL sessions during concurrent I/O

• Correct certificate chain ordering and improved handling of cross-signed certificates

• Enhanced SNI handling for session resumption and server-side matching

• Improved ALPN handling, including non-ASCII protocol names

• Expanded X.509 API coverage, including Extended Key Usage and X500 principals

• Added support for honoring client cipher suite preference ordering

• Rename wolfCrypt JNI helper classes to avoid namespace conflicts with wolfcrypt-jni

Improved Debugging, Testing, and CI Coverage
Debug logging now uses Java’s standard logging framework (java.util.logging) with improved timestamps. CI coverage has also been expanded to include GitHub Actions for:

• AddressSanitizer (-fsanitize=address)

• Clang scan-build static analysis

• Windows (Visual Studio) builds

• Android emulator unit tests

• ARM (--enable-armasm) builds

• Compatibility testing against the last five stable wolfSSL releases

wolfSSL JNI/JSSE 1.16.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. For any questions or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now