Category: wolfSSL/ wolfCrypt

How wolfSSL and Dark Sky Technology Secure Embedded Systems

When defense systems run open-source code touched by foreign adversaries, it’s not just risky—it’s a national security threat. That’s why wolfSSL and Dark Sky Technology teamed up: to combine certifiable cryptography with provable trust.

wolfSSL builds the most trusted cryptography on the market. Our lightweight, FIPS 140-3 validated wolfCrypt library secures everything from satellites to submarines—where performance, footprint, and reliability are non-negotiable. We support secure boot, secure firmware updates, and full (D)TLS 1.3, all engineered to meet the toughest standards like DO-178C DAL A and CNSA 2.0.

Dark Sky Technology defends America’s most critical systems from hidden threats in open-source software. Their platform, Bulletproof Trust, gives defense contractors and government agencies confidence in the integrity of their code by analyzing every risk vector:

• Contributors (who touched it)
• Vulnerabilities (what’s exposed)
• Licenses (what’s legal)
• Maintainability, code quality, and hygiene (what’s operationally dangerous)

Why We Partnered

Trust needs proof. Dark Sky independently evaluated wolfSSL using their TrustScore engine. Results:

• 0 sanctioned contributors
• No license conflicts or IP landmines
• Clean, maintainable code
• No embedded secrets or repo risk

You can view our TrustScore and full transparency report here: Dark Sky TrustScore for wolfSSL.

Why It Matters

For defense, software trust is mandatory. You must know what your code does—and who touched it.

wolfSSL delivers certifiable crypto.
Dark Sky proves its provenance.

No guesswork. No compromise. Just trusted software—by 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

In the context of the recent collaboration between wolfSSL and Frontgrade Gaisler, we are excited to share some benchmark results of the wolfCrypt library running on the Gaisler GR740-MINI board.

The GR740, designed as ESA’s Next Generation Microprocessor (NGMP), is a radiation-hardened System-on-Chip (SoC) featuring a quad-core fault-tolerant LEON4 SPARC V8 processor.

WolfSSL and Gaisler aim to enhance security solutions for space-grade applications, leveraging the robust capabilities of the GR740 processor and the cryptographic know-how of wolfSSL.

Benchmark for wolfCrypt running on Baremetal:

------------------------------------------------------------------------------
 wolfSSL version 5.8.0
------------------------------------------------------------------------------
Math:   Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c
        Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 sp_c32.c small
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
AES-128-CBC-enc              3 MiB took 1.003 seconds,    3.432 MiB/s
AES-128-CBC-dec              3 MiB took 1.002 seconds,    3.411 MiB/s
AES-192-CBC-enc              3 MiB took 1.007 seconds,    2.958 MiB/s
AES-192-CBC-dec              3 MiB took 1.005 seconds,    2.940 MiB/s
AES-256-CBC-enc              3 MiB took 1.005 seconds,    2.601 MiB/s
AES-256-CBC-dec              3 MiB took 1.001 seconds,    2.585 MiB/s
AES-128-GCM-enc            475 KiB took 1.014 seconds,  468.300 KiB/s
AES-128-GCM-dec            475 KiB took 1.015 seconds,  468.142 KiB/s
AES-192-GCM-enc            475 KiB took 1.036 seconds,  458.356 KiB/s
AES-192-GCM-dec            475 KiB took 1.037 seconds,  458.202 KiB/s
AES-256-GCM-enc            450 KiB took 1.003 seconds,  448.872 KiB/s
AES-256-GCM-dec            450 KiB took 1.003 seconds,  448.724 KiB/s
GMAC Table 4-bit           546 KiB took 1.001 seconds,  545.432 KiB/s
CHACHA                       7 MiB took 1.002 seconds,    6.945 MiB/s
CHA-POLY                     4 MiB took 1.000 seconds,    4.466 MiB/s
POLY1305                    17 MiB took 1.001 seconds,   17.076 MiB/s
SHA                         10 MiB took 1.002 seconds,    9.675 MiB/s
SHA-256                      3 MiB took 1.003 seconds,    2.581 MiB/s
SHA3-224                     2 MiB took 1.011 seconds,    1.907 MiB/s
SHA3-256                     2 MiB took 1.003 seconds,    1.801 MiB/s
SHA3-384                     1 MiB took 1.014 seconds,    1.397 MiB/s
SHA3-512                     1 MiB took 1.021 seconds,    0.980 MiB/s
HMAC-SHA                    10 MiB took 1.001 seconds,    9.585 MiB/s
HMAC-SHA256                  3 MiB took 1.001 seconds,    2.561 MiB/s
RSA     2048   public        78 ops took 1.017 sec, avg 13.035 ms, 76.715 ops/sec
RSA     2048  private         2 ops took 1.480 sec, avg 739.794 ms, 1.352 ops/sec
DH      2048  key gen         4 ops took 1.283 sec, avg 320.709 ms, 3.118 ops/sec
DH      2048    agree         4 ops took 1.282 sec, avg 320.625 ms, 3.119 ops/sec
ECC   [      SECP256R1]   256  key gen        18 ops took 1.028 sec, avg 57.084 ms, 17.518 ops/sec
ECDHE [      SECP256R1]   256    agree        18 ops took 1.025 sec, avg 56.947 ms, 17.560 ops/sec
ECDSA [      SECP256R1]   256     sign        16 ops took 1.010 sec, avg 63.136 ms, 15.839 ops/sec
ECDSA [      SECP256R1]   256   verify        10 ops took 1.145 sec, avg 114.465 ms, 8.736 ops/sec

Benchmark of wolfCrypt running in Linux Environment:

------------------------------------------------------------------------------
 wolfSSL version 5.8.0
------------------------------------------------------------------------------
Math:   Multi-Precision: Wolf(SP) word-size=32 bits=4096 sp_int.c
        Single Precision: ecc 256 384 rsa/dh 2048 3072 4096 sp_c32.c small
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
AES-128-CBC-enc              5 MiB took 1.502 seconds,    3.330 MiB/s
AES-128-CBC-dec              5 MiB took 1.542 seconds,    3.242 MiB/s
AES-192-CBC-enc              5 MiB took 1.737 seconds,    2.879 MiB/s
AES-192-CBC-dec              5 MiB took 1.780 seconds,    2.810 MiB/s
AES-256-CBC-enc              5 MiB took 1.971 seconds,    2.536 MiB/s
AES-256-CBC-dec              5 MiB took 2.015 seconds,    2.481 MiB/s
AES-128-GCM-enc              5 MiB took 10.777 seconds,    0.464 MiB/s
AES-128-GCM-dec              5 MiB took 10.744 seconds,    0.465 MiB/s
AES-192-GCM-enc              5 MiB took 10.983 seconds,    0.455 MiB/s
AES-192-GCM-dec              5 MiB took 10.980 seconds,    0.455 MiB/s
AES-256-GCM-enc              5 MiB took 11.218 seconds,    0.446 MiB/s
AES-256-GCM-dec              5 MiB took 11.215 seconds,    0.446 MiB/s
GMAC Table 4-bit          1024 KiB took 1.863 seconds,  549.684 KiB/s
CHACHA                      10 MiB took 1.483 seconds,    6.742 MiB/s
CHA-POLY                     5 MiB took 1.031 seconds,    4.852 MiB/s
POLY1305                    20 MiB took 1.158 seconds,   17.270 MiB/s
SHA                         10 MiB took 1.063 seconds,    9.410 MiB/s
SHA-256                      5 MiB took 1.494 seconds,    3.346 MiB/s
SHA3-224                     5 MiB took 2.609 seconds,    1.917 MiB/s
SHA3-256                     5 MiB took 2.757 seconds,    1.814 MiB/s
SHA3-384                     5 MiB took 3.578 seconds,    1.398 MiB/s
SHA3-512                     5 MiB took 5.126 seconds,    0.975 MiB/s
HMAC-SHA                    10 MiB took 1.062 seconds,    9.412 MiB/s
HMAC-SHA256                  5 MiB took 1.494 seconds,    3.346 MiB/s
RSA     2048   public       100 ops took 1.309 sec, avg 13.094 ms, 76.373 ops/sec
RSA     2048  private       100 ops took 74.411 sec, avg 744.114 ms, 1.344 ops/sec
DH      2048  key gen         4 ops took 1.291 sec, avg 322.812 ms, 3.098 ops/sec
DH      2048    agree       100 ops took 32.274 sec, avg 322.741 ms, 3.098 ops/sec
ECC   [      SECP256R1]   256  key gen       100 ops took 5.748 sec, avg 57.484 ms, 17.396 ops/sec
ECDHE [      SECP256R1]   256    agree       100 ops took 5.737 sec, avg 57.371 ms, 17.431 ops/sec
ECDSA [      SECP256R1]   256     sign       100 ops took 6.360 sec, avg 63.599 ms, 15.723 ops/sec
ECDSA [      SECP256R1]   256   verify       100 ops took 11.532 sec, avg 115.318 ms, 8.672 ops/sec

These results underscore the potential of integrating wolfSSL’s cryptographic solutions with Gaisler’s advanced hardware, paving the way for secure high-performance cryptography that comply with latest industry standards, including DO-178C Level A, FIPS 140-3 and MISRA-C.

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

wolfSSL’s wolfcrypt library includes several cryptographic algorithms that are now considered broken or deprecated. While these algorithms are typically disabled by default, developers should be aware of their security implications. Here is the list of these algorithms along with links to documents explaining why they are no longer considered secure:

• RC4/ARC4: Prohibited for TLS use due to keystream biases and practical attacks
• MD2: Moved to Historic Status due to collision attacks
• MD4: Moved to Historic Status, full collision attacks demonstrated
• MD5: Practical collision attacks, can generate collisions in seconds (See https://github.com/wolfSSL/wolfssl/pull/8895)
• SHA-1: Collision attacks demonstrated, officially retired by NIST in 2022
• DES: 56-bit key easily crackable by brute force attacks with modern hardware
• 3DES/TDEA: Deprecated by NIST, vulnerable to Sweet32 birthday attacks
• DSA: Being phased out by NIST, vulnerable to nonce reuse attacks
• RSA-1024 and weaker: There are experiments showing this is already too weak.

Note that these are still in the wolfSSL code base for some specific customer needs.

1. Legacy Compatibility: Existing systems and embedded devices require these algorithms for interoperability
2. Standards Compliance: Industry standards and regulatory requirements mandate support during transition periods
3. Backward Compatibility: Applications migrating from legacy systems need continued support
4. Gradual Migration Support: Organizations require time and pathways to transition to secure alternatives

NOTE: These algorithms are disabled by default and require explicit compilation flags (such as WOLFSSL_ALLOW_RC4) to enable them, demonstrating wolfSSL’s commitment to security best practices while maintaining necessary compatibility. There are other ways to enable some of these algorithms that you should be careful about:

• –enable-all will enable all these algorithms
• –enable-all-crypto will enable all these algorithms
• –enable-openssh will enable DSA
• –enable-wpas will enable DSA
• –enable-curl will enable DES3
• –enable-stunnel will enable DES3
• –enable-oldtls will enable MD5 and SHA-1

A great way to check if these algorithms are enabled is to inspect your wolfssl/options.h to see what macros are defined.

All that said, no matter how strong your algorithms are, if you have weak entropy or use weak parameters, your cryptography is eventually destined to fail. Another threat is quantum computers. As the state of the art improves in the field of quantum computing, so increases the risk to our currently considered secure algorithms. If you find these points confusing, please do reach out to us for guidance.

Please think very carefully before enabling any of these algorithms and please do reach out to us if you have any uncertainty with regards to whether you need them.

Here are some other algorithms that are considered broken:

• Dual_EC_DRBG: back-doored
• SIKE (Supersingular Isogeny Key Exchange): broken during NIST PQC competition
• Merkle–Hellman knapsack cryptosystem: broken by Shamir
• Caesar Cipher: vulnerable to brute force attacks and statistical analysis

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 wanted to highlight a useful migration guide posted by Amazon for their AWS IoT Core with FreeRTOS showing how to migrate from mbedTLS to wolfSSL. The migration guide shows useful API mappings and how to expose PKCS11 capabilities.

Check out the FreeRTOS with mbedTLS to FreeRTOS with wolfSSL Migration Guide v1.0.

FreeRTOS is a real-time operating system used in many embedded systems. It is lightweight and optimized for microcontrollers and small processors. For systems using cryptography or TLS, wolfSSL is a perfect match, so we wanted to highlight a guide for migrating from mbedTLS to wolfSSL.

The AWS IoT Core is a managed cloud service for secure, reliable communication between embedded devices and the AWS Cloud. The AWS Iot Core requires TLS communication to establish connections.

Why Migrate from mbedTLS to wolfSSL?

Moving to wolfSSL offers several advantages for embedded environments, including:

• Smaller footprint and performance optimizations: wolfSSL provides a reduced memory footprint and faster cryptographic processing.
• Latest Protocols: It also includes full support for TLS 1.3 and DTLS 1.3, enabling shorter handshakes and stronger encryption.
• Professional support: Direct support from engineers who authored and maintained the code. Free pre-sales support and paid support plans available.
• Commercial licensing: While open source, wolfSSL also offers commercial licenses for proprietary projects
• FIPS 140-3 certified cryptographic software module, making it suitable for regulated industries.
• Easy integration and extensive resources: The library includes detailed documentation and examples, simplifying testing and adoption.
• Expanded algorithm support: wolfSSL includes cryptographic algorithms beyond mbedTLS’s offerings such as Post Quantum (PQ) ML-DSA, ML-KEM, XMSS and LMSS.
• Assembly optimizations for ARM Cortex-M and A. We typically see a 10x speedup using our hand crafted assembly speedups, which are available for all our commonly used symmetric and asymmetric algorithms.

Note: This migration guide is fairly dated. Since then wolfSSL has developed and maintains full PKCS11 support to either consume a PKCS11 provider or to be one through our wolfPKCS11 provider. We also support using a TPM 2.0 module as the cryptographic and storage provider for wolfPKCS11.

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

Have you heard the newest and most pervasive buzzword in online security? Recently, the most popular and over-hyped expression doing the rounds these days is “Cryptoagility”. Why do we think it is so overhyped? Because if you are simply looking for a definition, you’ll be hard pressed to find one. People who talk about it can barely define it.

Most will have you believe in a vague notion of being able to swap out algorithms in real time via the click of a mouse button. No need for reboots, updates or interference from system administrators. Some will even go as far as having the ability to swap different implementations of the same algorithms. Uber flexibility in the runtime environment.

Here at wolfSSL we have a more nuanced approach to cryptoagility. What we just described above is what we call RuntimebCryptoagility and if your system can accommodate it and you are willing to spend the resources to have it, then perhaps you might want to look into our wolfEngine and wolfProvider products.

The other kind of Cryptoagility where the wolfSSL team specializes in is Buildtime Cryptoagility. We recognize that when it comes to embedded systems, resources are at a premium and can not be wasted. With that in mind, currently unused algorithms and data are taking up valuable memory and footprint. For example, if you’re planning a post-quantum transition, having those algorithms in your firmware now might not be practical. With wolfBoot, our super efficient boot loader implementation, that migration is a simple and seamless firmware update away. When the time comes, rebuild your firmware with the algorithms required and have a seamless Cryptoagility experience.

Note that it has been this way for years. Here at wolfSSL, we didn’t need to create a new buzzword to serve our customers.

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

Selecting the right hardware for an embedded project can be a complex decision—but choosing a security library doesn’t have to be. wolfSSL offers broad platform support, running seamlessly on everything from bare-metal systems to full-featured operating systems. In this post, we’ll compare how wolfSSL integrates with two widely used embedded platforms: Xilinx and STM. While both are popular choices, they offer distinct differences in architecture, development tools, and integration workflows.

---

Platform High Level Overview

Xilinx

• Primarily FPGA-based (Zynq, Zynq Ultrascale+, Versal)
• Offers ARM Cortex-A cores alongside programmable logic
• Development environment: Xilinx Vitis / Petalinux
• OS: Often uses Linux (Yocto or Petalinux), FreeRTOS or bare-metal

STM (STMicroelectronics)

• Microcontroller-focused (e.g., STM32 family)
• Most are based on ARM Cortex-M cores, with some series using Cortex-A cores
• Development environment: STM32CubeIDE, Makefiles, or bare-metal toolchains
• OS: Often bare-metal or FreeRTOS

---

wolfSSL Build Process

Xilinx

• Autotools or CMake to build wolfSSL in userspace
• Cross-compilation with Petalinux SDK or Vitis toolchain
• Hardware acceleration via Xilinx’s crypto engine, ARM assembly optimizations or custom logic in the PL with crypto callbacks

STM (STMicroelectronics)

• Predefined example configuration files in wolfSSL/IDE/STM32Cube
• Integration with STM32CubeMX-generated projects
• Support for HAL/LL drivers, and FreeRTOS (if applicable)

---

Cryptographic Acceleration

Xilinx

• Advanced FPGAs allow for hardware acceleration of cryptographic primitives
• Can use custom IP cores or external crypto accelerators
• wolfSSL’s ARM assembly optimizations
• Potential for extreme performance gains, but at the cost of complexity

STM (STMicroelectronics)

• Some STM32 parts support hardware ECC, AES, SHA, and RNG
• wolfSSL can use these via direct calls to HAL drivers
• Easier to configure and use but offers less flexibility compared to FPGAs and on average has a less powerful CPU
• wolfSSL’s ARM assembly optimizations

---

Some Use Cases We See

• Xilinx if:
  • You need programmable logic and customizable crypto acceleration
  • Your application runs Linux and demands high throughput
  • You have a complex security architecture
• STM if:
  • You want quick integration for a bare-metal or FreeRTOS-based project
  • Your focus is low power and minimal footprint
  • You need an edge microcontroller

---

Both Xilinx and STM platforms are well-supported by wolfSSL, but the experience differs significantly. Xilinx generally offers power and flexibility—ideal for high-performance secure systems—while STM excels in simplicity and efficiency, making it perfect for lightweight, resource-constrained designs.

Whether you’re targeting a Linux-based Zynq application or a real-time STM32 sensor node, wolfSSL provides the building blocks you need to implement robust embedded security.

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

As of wolfSSL version 5.8.0, support for Curve25519 blinding has been introduced. Although originally listed as a feature addition in the changelog, it is more accurately characterized as a mitigation for a potential side-channel vulnerability affecting specific builds. This feature offers optional hardening against power or electromagnetic (EM) analysis during Curve25519 private key operations. While such attacks are generally difficult to execute in practice, enabling blinding provides an additional layer of protection for devices that may be more susceptible to physical access or side-channel observation.

When Blinding Is Applicable

Blinding is only relevant for builds that use the C implementation of Curve25519 in wolfSSL. It is not available or necessary in the following cases:

• Assembly-optimized implementations (–enable-armasm / WOLFSSL_ARMASM, –enable-intelasm / USE_INTEL_SPEEDUP)
• The small footprint Curve25519 build (–enable-curve25519=small / CURVE25519_SMALL)

To enable blinding in the C implementation, define the macro WOLFSSL_CURVE25519_BLINDING. For example:

bash
CopyEdit
./configure --enable-curve25519 CPPFLAGS=-DWOLFSSL_CURVE25519_BLINDING

Affected APIs

Blinding hardens operations where the private key is used with scalar multiplication, such as:

• wc_curve25519_export_public_ex – when deriving the public key from a private key
• wc_curve25519_make_key – during key pair generation
• wc_curve25519_generic
• wc_curve25519_shared_secret_ex

If you are using the C implementation on hardware where physical side-channel exposure is a concern, it’s recommended to enable blinding and regenerate private keys used in these operations. Curve25519 blinding will be enabled by default for the C implementation in future wolfSSL releases.

Acknowledgments

Thanks to Arnaud Varillon, Laurent Sauvage, and Allan Delautre from Telecom Paris for reporting this.

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

Introduction

The wolfSSL embedded SSL/TLS library has recently expanded its compatibility by adding support for the Open Watcom C/C++ compiler. This enhancement enables developers to build wolfSSL using Open Watcom across multiple platforms including Windows, Linux, and OS/2. This blog post explores the new Open Watcom support, its features, and how to leverage it in your projects.

What is Open Watcom?

Open Watcom is an open-source compiler suite derived from the commercial Watcom C/C++ compiler. It’s particularly valued for its:

• Cross-platform capabilities (Windows, OS/2, DOS, Linux)
• Efficient code generation
• Strong support for legacy systems
• Continued development by the open-source community

The compiler is especially important for maintaining and developing software for OS/2 and other legacy systems that still have active user communities.

New Features in wolfSSL for Open Watcom

The recent pull requests #8505 and #8484 have implemented several features to ensure wolfSSL works seamlessly with Open Watcom:

1. Multi-Platform Support:
   • Windows builds
   • Linux builds
   • OS/2 builds (particularly significant as OS/2 support is rare in modern libraries)
2. Build Configuration Options:
   • Single-threaded and multi-threaded builds
   • Static library and DLL (Dynamic Link Library) options
   • Compatibility with Open Watcom 1.9 and newer versions (2.0+)
3. OS/2-Specific Enhancements:
   • Socket handling for OS/2 networking
   • Thread management for OS/2’s unique threading model
   • Proper mutex implementation for OS/2
4. Technical Improvements:
   • Renamed OFFSETOF macro to WC_OFFSETOF to avoid conflicts with OS/2 headers
   • Added proper time handling functions for Open Watcom
   • Implemented conditional compilation for platform-specific code
   • Fixed socket and I/O handling for cross-platform compatibility

Use Cases and Benefits

The addition of Open Watcom support opens up several possibilities:

1. Legacy System Integration: Integrate modern TLS security into legacy systems running OS/2 or older Windows versions.
2. Cross-Platform Development: Develop secure applications that can be compiled for multiple platforms using a single compiler.
3. Educational Environments: Universities and educational institutions that use Open Watcom for teaching can now incorporate wolfSSL in their security curriculum.
4. Embedded Systems: Some embedded systems with specific requirements may benefit from Open Watcom’s efficient code generation.

Summary

The addition of Open Watcom support to wolfSSL shows our versatility by supporting this compiler across Windows, Linux, and especially OS/2 platforms. This feature enables developers working with legacy systems, educational environments, and specific embedded platforms to leverage wolfSSL’s robust security features.

The implementation includes comprehensive support for different threading models and library types, ensuring that developers have flexibility in how they integrate wolfSSL into their projects. Whether you’re maintaining legacy applications, teaching security concepts, or developing cross-platform solutions, the Open Watcom support in wolfSSL provides a valuable tool in your development arsenal.

As the security landscape continues to evolve, this enhancement ensures that even systems using older or specialized compilers can maintain modern security standards through wolfSSL’s TLS implementation.

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’re thrilled to announce a new feature in wolfSSL 5.8.0: the ability to offload Extended Master Secret (EMS) generation to hardware, introduced in Pull Request #8303. Integrated into `–enable-pkcallbacks –enable-extended-master` builds, this enhancement empowers developers to leverage Trusted Execution Environments (TEEs) or custom hardware for EMS generation, boosting security and performance in TLS sessions. This makes wolfSSL an even more robust solution for embedded systems, IoT, and high-security applications.

What is Extended Master Secret Offloading?

The Extended Master Secret (EMS), defined in RFC 7627, strengthens TLS session security by tying the master secret to the full handshake transcript, mitigating man-in-the-middle attacks. The new feature in wolfSSL allows developers to offload EMS generation to hardware, such as a Trusted Execution Environment (e.g., ARM TrustZone, Intel SGX) or specialized cryptographic hardware. By using a custom callback function, you can delegate EMS computation to secure hardware, ensuring sensitive operations occur in a protected environment.

If you want to know more about using callbacks in wolfSSL or 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

On May 12th, 2025, the test certificate baltimore-cybertrust-root.pem expired. This may cause issues with the test cases run during make check with wolfSSL builds that do not use the OpenSSL compatibility layer and have a filesystem enabled.

One of the unit tests attempts to load all Certificate Authorities (CAs) from the certs/external directory, which previously included this now-expired certificate. When this test is run with a wolfSSL configuration that will fail if any bad CAs are found among all CAs loaded, it will fail due to the certificate’s expiration.

This issue has been resolved in the wolfSSL master branch by the following pull request: https://github.com/wolfSSL/wolfssl/pull/8769

If you’re currently encountering failures during make check, we recommend removing the expired certificate from your local test environment by applying the changes from GitHub pull request 8769.

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