RECENT BLOG NEWS
New Feature Spotlight: Offloading Extended Master Secret Generation to Hardware in wolfSSL
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
Live Webinar: Latest FIPS 140-3 developments at wolfSSL
Join us for an exclusive look into the Latest FIPS 140-3 Developments at wolfSSL, presented by Kaleb Himes, Senior Software Engineer at wolfSSL. This live webinar is scheduled for June 4th at 9 AM PT. Discover cutting-edge advancements in FIPS 140-3 compliance, Post-Quantum cryptography, and optimized solutions for Level 2 and Level 3 validation.
Register now: Latest FIPS 140-3 developments at wolfSSL
Date: June 4th | 9 AM PT
wolfSSL is FIPS 140-3 validated with 5-year Certification #4718. As the first to support Post-Quantum standards, wolfSSL delivers unmatched portability across dozens of hardware targets, establishing itself as a trusted leader in open-source cybersecurity.
This webinar will cover:
- Post-Quantum Full Submission: How wolfSSL is preparing for quantum-resistant encryption.
- FIPS 140-3 Level 2 & Level 3 Validation: Achieving rigorous standards with wolfSSL software and your hardware.
- Planned OE Additions: Get insight into our roadmap for expanding FIPS 140-3 certified OEs.
- Full Submission on Demand: Tailored modules, algorithm subsets, and boot loaders for embedded use-cases.
Register now to learn why industry leaders trust wolfSSL for their FIPS 140-3 projects and discover how you can stay ahead in cybersecurity!
As always, our webinar will include Q&A throughout. 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
Expired Test Certificate: baltimore-cybertrust-root.pem and make check Failures
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
Firefox Gets FIPS 140-3 Power: wolfPKCS11 Unleashes wolfCrypt in NSS!
wolfSSL is thrilled to announce a significant milestone in browser security: the successful integration of wolfPKCS11 to provide FIPS 140-3 validated cryptography for the Mozilla Firefox browser. This is achieved by enabling wolfPKCS11 to serve as the backend cryptographic provider for Firefox’s Network Security Services (NSS) layer. This development represents a major step forward, bringing robust, federally-certified security to one of the world’s most popular web browsers.
This achievement builds directly upon a previously shared vision. Many may recall an earlier post, Why replace NSS with wolfSSL in Firefox?, which demonstrated the possibility of such an integration. It is with great excitement that this possibility is announced as a working reality. The core concept, replacing the underlying authentication implementations within NSS with the FIPS-validated capabilities of wolfCrypt via wolfPKCS11, has been brought to fruition.
For users and organizations operating in environments that require or prefer the assurances of FIPS 140-3 validated cryptography, this development is transformative. It means that Firefox can soon be leveraged with the formidable security backing of wolfSSL’s FIPS-certified cryptographic engine, wolfCrypt. While this advanced capability is fully functional and has been rigorously tested internally, it is important to note that it is not yet part of an official public release. Further announcements regarding public availability will be forthcoming. This progression from a proof-of-concept to a tangible, working solution underscores a commitment to not only innovate but also to deliver on complex technical challenges, reinforcing the reliability that is paramount in the security domain.
Why FIPS 140-3 in Your Browser is a Big Deal
Understanding the significance of this development begins with understanding FIPS 140-3. The Federal Information Processing Standard (FIPS) Publication 140-3 is a U.S. government standard developed by the National Institute of Standards and Technology (NIST). It specifies the security requirements for cryptographic modules, covering both hardware and software components that execute cryptographic functions. The primary role of FIPS 140-3 is to ensure that these cryptographic implementations meet stringent security benchmarks, thereby effectively protecting sensitive information. The gravity of this validation is starkly highlighted by NIST and the Canadian Centre for Cyber Security, which state that “non-validated cryptography is viewed as providing no protection to information—equivalent to plaintext”. This underscores the profound level of assurance that FIPS validation provides.
The mandate to use FIPS-validated cryptography is explicit for U.S. federal agencies when protecting sensitive information within their computer and telecommunication systems. This requirement frequently extends beyond direct government use, impacting contractors, organizations in regulated industries such as healthcare and finance, and entities pursuing critical certifications like the Cybersecurity Maturity Model Certification (CMMC). For other organizations, employing FIPS-validated cryptography serves as a clear indicator of a commitment to a high standard of security assurance.
Mozilla Firefox, along with other Mozilla products, relies on a set of libraries known as Network Security Services (NSS) for all its SSL/TLS, S/MIME, and other cryptographic operations. NSS is engineered to support cross-platform development and implements a comprehensive suite of internet security standards. A critical architectural feature of NSS is its utilization of the PKCS#11 standard. PKCS#11 is an API that governs communication with cryptographic tokens, which can be hardware accelerators, smart cards, or, as in this case, software-based modules often referred to as a “Software Security Device”. This adherence by NSS to the PKCS#11 standard is fundamental to the integration of wolfPKCS11. The combination of FIPS 140-3 defining what constitutes trusted cryptography and PKCS#11 providing how that trusted cryptography can be interfaced is powerful. Without NSS’s support for this standardized interface, replacing its cryptographic engine would be an extraordinarily complex, if not impossible, endeavor. This successful integration demonstrates how adherence to open standards can foster innovation and interoperability, ultimately benefiting end-users by making high-assurance cryptography accessible in mainstream applications like Firefox, potentially elevating the baseline for general web security expectations.
The wolfSSL Solution: wolfPKCS11 Powering NSS with FIPS-Certified wolfCrypt
The key to this enhanced security for Firefox is wolfPKCS11. This is wolfSSL’s robust implementation of the PKCS#11 API. The wolfPKCS11 module functions as an essential interface, or bridge, enabling applications that are designed to use the PKCS#11 standard (such as NSS) to access and utilize the comprehensive suite of cryptographic algorithms available within wolfSSL’s core cryptographic engine, wolfCrypt.
The integration leverages the “magic” of the PKCS#11 standard, which facilitates a “drop-in” replacement mechanism. NSS, by design, uses the PKCS#11 API to communicate with its default cryptographic library, which is softokn-freebl. The wolfPKCS11 module has been engineered to serve as a binary drop-in replacement for this default software security device. This means that, through modifications to configuration files rather than extensive code changes to Firefox itself, NSS can be directed to utilize wolfPKCS11. Consequently, all cryptographic calls from NSS are re-routed through wolfPKCS11 to the wolfCrypt engine. This elegant modularity, made possible by the PKCS#11 standard, significantly reduces the complexity and effort typically associated with integrating a new cryptographic provider into an established application like Firefox. The existence of this well-defined standard is a direct enabler of this relatively seamless integration path.
The true cryptographic power behind this solution resides in wolfCrypt, wolfSSL’s FIPS 140-3 validated cryptographic engine. wolfSSL has a distinguished history of achieving FIPS certifications, and wolfCrypt stands as a testament to this commitment, having attained FIPS 140-3 validation (the wolfCrypt module was one of the first in the world to receive a FIPS 140–3 Validation Certificate). It is this validation that imbues the Firefox integration with its robust security backbone and its capability to meet stringent compliance requirements. Beyond its FIPS validation, wolfCrypt is renowned for its exceptional performance, minimal footprint optimized for embedded systems, and extensive support for a wide array of cryptographic algorithms.
Seeing is Believing: FIPS-Powered Browsing (And Yes, It’s Real!)
It is understandable that FIPS-grade cryptography seamlessly operating within Firefox might sound almost too good to be true. To demonstrate that this is far more than just theoretical, it was even tested with some, shall we say, critical internet operations.
Caption: “Never Gonna Give Your Data Up: Firefox running with wolfSSL FIPS 140-3 security!”
Yes, that’s Firefox streaming a timeless classic. While the choice of content might be a playful rickroll, rest assured, the underlying FIPS 140-3 validated cryptography being provided by wolfPKCS11 and wolfCrypt is absolutely real and fully functional. If the system can handle real-world HTTPS traffic for streaming video (even this particular video), it is capable of many of today’s demanding browser use cases.
For those curious about how this appears “under the hood,” if one were to inspect Firefox’s security device manager, wolfPKCS11 would be visible as a loaded module.
As mentioned, this powerful capability is confirmed and working seamlessly within our internal development environments. While it is not yet available in a public wolfPKCS11 release or as a standard component of Firefox distributions, work is progressing towards that goal. Keep an eye on the wolfSSL blog and official announcements for future updates.
Beyond the Browser: wolfSSL’s Commitment to Pervasive FIPS Security
The work to bring FIPS 140-3 validated cryptography to Firefox via NSS and wolfPKCS11 is not an isolated endeavor. It is a significant component of a much broader strategic initiative within wolfSSL: to make FIPS-certified cryptography readily and easily accessible across a diverse range of platforms and ecosystems.
This vision extends to enabling FIPS compliance across entire Linux distributions. There are ongoing efforts to integrate the wolfCrypt FIPS module with other critical system libraries, such as libgcrypt and GnuTLS. The ultimate objective is ambitious yet vital: “achieving FIPS 140-3 compliance across an entire Linux distribution”. Such an achievement would establish a unified, trusted cryptographic layer, thereby simplifying compliance efforts and significantly enhancing the security posture for countless applications and systems built upon these foundational open-source components. This strategy of embedding FIPS-validated technology deep within core operating system and application components positions wolfCrypt as a fundamental building block for secure systems, potentially establishing it as a de facto standard for FIPS cryptography in open-source environments.
Furthermore, the wolfPKCS11 module itself is designed with the future in mind. It is an evolving component, with enhancements such as upcoming support for the Leighton-Micali Signature (LMS) scheme planned. LMS is a stateful hash-based signature scheme, standardized in RFC 8554 and approved by NIST SP 800-208, notable for its quantum-resistant properties. This demonstrates a proactive stance towards emerging security threats. The engineering investment in wolfPKCS11 is therefore not limited to current FIPS standards; it is also paving a pathway towards post-quantum cryptography. This means that the very same integration mechanism being used to deliver FIPS 140-3 validated cryptography to Firefox today could potentially deliver post-quantum security in the future, thanks to the flexible and standards-compliant design of wolfPKCS11.
Conclusion: Secure Your Firefox Experience, Trust wolfSSL
To summarize this exciting development: wolfSSL has successfully made FIPS 140-3 validated cryptography a practical reality for the Firefox browser. This has been achieved by integrating the wolfPKCS11 module with Firefox’s Network Security Services (NSS), thereby allowing Firefox to leverage the proven strength of the wolfCrypt FIPS-certified engine.
The benefits of this integration are manifold. It provides access to high-assurance, FIPS-validated security within one of the world’s leading web browsers. For organizations with FIPS compliance mandates, it offers a significantly simplified path to meeting those requirements for browser-based activities. All of this is delivered with the robust, performant, and resource-efficient cryptography that wolfSSL is known for.
This advancement is another clear testament to wolfSSL’s leadership in embedded security, cryptography, and FIPS validation. The commitment at wolfSSL is to provide cutting-edge, reliable security solutions that meet the evolving challenges of the digital world. This successful integration reinforces that commitment and highlights the dedication to enhancing security for users everywhere.
Get in Touch / Download wolfSSL
Stay tuned to our blog for updates on the public availability of this feature!
If you have questions about any of the above, or how wolfSSL can help secure your applications, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
IronVelo Chooses wolfSSL for Secure Identity Solutions
In the realm of identity management, security is paramount. IronVelo, a company dedicated to building robust and reliable identity provider solutions, understands this critical need. To meet their stringent security requirements, IronVelo has partnered with wolfSSL, leveraging the power and reliability of the wolfCrypt cryptographic library. This collaboration highlights IronVelo’s commitment to security best practices and wolfSSL’s proven expertise in providing cutting-edge cryptographic solutions.
IronVelo’s Innovative Approach: The wolf-crypto Wrapper
IronVelo has developed a unique approach to integrating cryptography into their systems with their creation of “wolf-crypto.” This thin, low- to zero-cost wrapper around wolfSSL’s wolfCrypt library is designed to enforce correctness, security, and standards compliance at the Rust type system level.
Instead of relying on traditional runtime checks within the C layer, wolf-crypto elevates most constraints to compile time. This innovative strategy prevents cryptographic misuse from even compiling, enabling the early detection of bugs and the complete avoidance of undefined behavior. IronVelo has applied this rigorous methodology to FIPS-compliant usage, incorporating enforcement through both a feature flag and a marker trait to simplify compliance.
Rigorous Testing for Unwavering Reliability
IronVelo’s commitment to security extends to their thorough testing practices. To ensure compatibility with the underlying wolfCrypt implementation, they employ rigorous validation against the NIST CAVP test suite. This is further supplemented by extensive property-based testing, fuzzing, and unit tests designed to uncover edge cases. Additionally, wolf-crypto provides useful constant-time utilities that are formally verified with CBMC and Haybale Pitchfork (UCSD’s Boolector-based SMT framework) to guarantee the absence of timing side channels.
wolfSSL: A Foundation of Performance and Security
IronVelo’s decision to partner with wolfSSL was driven by several key factors. wolfSSL’s wolfCrypt library offers the performance, certifications, and proven reliability essential for securing IronVelo’s identity provider. Resource-constrained efficiency also played a critical role—wolfSSL’s minimal footprint and high efficiency are paramount for operating in deeply constrained environments. By utilizing wolfSSL, IronVelo can confidently provide its users with a secure and dependable identity management solution.
Looking Ahead: A Powerful Partnership
While still in QA, IronVelo plans to integrate wolfCrypt for both one-time key operations and TLS integration within their identity provider. This partnership between wolfSSL and IronVelo demonstrates a shared vision for building secure systems from the ground up. By combining wolfSSL’s robust cryptographic capabilities with IronVelo’s innovative Rust-based approach, the future of identity management is poised to be more secure, ergonomic, and efficient.
Find out more about IronVelo via their website: https://ironvelo.com/ and their github https://github.com/IronVelo/wolf-crypto
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 Enhances PKCS7 Streaming Support with Indefinite Length Handling
wolfSSL has extended its PKCS7 capabilities to better handle indefinite length encodings, particularly in streaming scenarios. While basic support for indefinite length verification existed, recent updates have refined the wc_PKCS7_VerifySignedData() API to process multipart and indefinite length content more efficiently in a streaming manner.(wolfSSL)
Key Enhancements
- Streaming Verification: The wc_PKCS7_VerifySignedData() function now supports verifying PKCS7 data with indefinite lengths without requiring the entire content to be buffered in memory.
- Improved Decoding: Enhancements in decoding functions allow for better handling of BER-encoded PKCS7 structures with indefinite lengths.
Example Usage
The wolfssl-examples repository provides practical demonstrations of these enhancements. For instance, the pkcs7-stream-verify example illustrates how to verify PKCS7 signed data in a streaming context:
PKCS7 pkcs7; byte buffer[BUFFER_SIZE]; int ret; // Initialize PKCS7 structure wc_PKCS7_Init(&pkcs7, NULL, INVALID_DEVID); // Set up certificate and key pkcs7.cert = cert; pkcs7.certSz = certSz; pkcs7.privateKey = key; pkcs7.privateKeySz = keySz; // Begin streaming verification ret = wc_PKCS7_VerifySignedData(&pkcs7, buffer, bufferSz); if (ret != 0) { // Handle error } // Continue processing as needed
This approach allows applications to process and verify large or streaming PKCS7 data efficiently, without the need to load the entire content into memory.
Benefits
- Efficiency: Reduces memory usage by processing data in chunks.
- Flexibility: Supports a wider range of PKCS7 encoding scenarios, including those using indefinite lengths.
- Standards Compliance: Aligns with BER encoding standards for PKCS7 structures.(GitHub)
These enhancements make wolfSSL more adaptable for applications requiring secure, real-time data processing.
If you have questiona about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: Achieving Avionics Security with DO-178C-Certified Cryptography
If you’re developing avionics software or working on embedded systems for aerospace, DO-178C certification isn’t optional. It’s essential for safety, compliance, and market acceptance. Join us on May 28th at 9 AM PT for a live webinar, “Achieving Avionics Security with DO-178C-Certified Cryptography,” presented by wolfSSL Software Engineer Tesfa Mael.
Register Now: Achieving Avionics Security with DO-178C-Certified Cryptography
Date: May 28th | 9 AM PT
Learn how to leverage DO-178C-certified cryptographic libraries and a FIPS 140-3 validated certificate (#4718) to streamline your certification process while protecting airborne systems against cybersecurity threats. Discover how wolfBoot, our secure bootloader, extends DO-178C support to modern embedded platforms like Intel Tiger Lake, enabling secure boot, firmware updates, and trusted runtime environments.
This webinar will cover:
- Introduction to wolfSSL and Our Embedded Security Missio
- DO-178C Overview: Objectives and Applicability in Avionics
- wolfSSL’s Path to DO-178C Certification
- Real-World Use Case: DO-178C in a Customer Avionics Project
Register now to discover how wolfSSL can accelerate your DO-178C projects with certifiable, aviation-grade security.
As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfSSL 5.8.0: Easier NXP SE050 Development with Automatic Key Deletion
The NXP EdgeLock SE050 is a popular secure element providing a strong root of trust for IoT devices, known for its “Plug & Trust” simplicity. wolfSSL has consistently supported the SE050, enabling robust hardware-based security for TLS, cloud onboarding, and data protection. However, managing cryptographic keys on secure elements during development can often be a cumbersome task.
With the release of wolfSSL 5.8.0, we’re excited to introduce enhancements that significantly streamline the developer experience with the NXP SE050, most notably a new feature for automatic key deletion.
Simplifying Key Management with Automatic Key Deletion
During development and testing, developers frequently create and discard numerous cryptographic keys. On the SE050, these keys occupy persistent storage slots. Without careful manual cleanup, the keystore can quickly fill up, leading to errors and slowing down progress.
The Solution: WOLFSSL_SE050_AUTO_ERASE
A key improvement in wolfSSL 5.8.0. is the introduction of the WOLFSSL_SE050_AUTO_ERASE preprocessor define. When wolfSSL is compiled with this option, any key generated on or loaded into the SE050 via wolfSSL will be automatically erased from the secure element when the corresponding wolfCrypt key object in your application is freed (e.g., via wc_ecc_free()).
Benefits for Developers:
- Faster Iteration: Experiment freely without worrying about manual SE050 key cleanup.
- Simplified Testing: Automated tests that generate keys on the SE050 become more robust, as the risk of a full keystore is minimized.
- Reduced Clutter: Keeps the SE050 keystore clean from temporary development keys.
- Focus on Application Logic: Spend more time on your core application and less on SE050 housekeeping during development.
This feature is a significant quality-of-life improvement, making the powerful SE050 even more accessible, especially during rapid prototyping and testing phases.
Complementary SE050 Refinements
Alongside this key management enhancement, wolfSSL 5.8.0 also includes other refinements to our SE050 implementation. While the automatic key deletion is a highlight for developer workflow, these additional contributions are vital for the overall stability and performance of wolfSSL’s SE050 support, ensuring a polished and reliable experience.
Why These Enhancements Matter
These improvements in wolfSSL 5.8.0 underscore our commitment to providing security solutions that are not only robust but also developer-friendly. By reducing friction in the development process, we empower you to build secure applications more efficiently.
Getting Started
- Download wolfSSL 5.8.0: Get the latest release from our download page.
- Enable Automatic Key Deletion: Compile wolfSSL with the WOLFSSL_SE050_AUTO_ERASE define. For example, using autoconf: ./configure –with-se050 CFLAGS=”-DWOLFSSL_SE050_AUTO_ERASE” This is an opt-in feature, ideal for development and testing builds.
- Consult Documentation: For full details on SE050 integration, refer to the README_SE050.md in the wolfSSL source (wolfcrypt/src/port/nxp/) and our examples in the wolfssl-examples repository.
Conclusion
The SE050 enhancements in wolfSSL 5.8.0, especially the automatic key deletion feature, make integrating hardware security with NXP’s SE050 smoother and more efficient. wolfSSL continues to provide cutting-edge security that is easy for developers to use.
- Explore the Code: Dive into the source code for these new SE050 enhancements on the wolfSSL GitHub repository: (https://github.com/wolfSSL/wolfssl).
- Contact Us: For questions, email us at facts@wolfssl.com or visit our support forums.
We’re excited for you to try these new features and experience a more streamlined SE050 development workflow!
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
Enhancing wolfSSL’s CMake Build System: Adding WOLFSSL_CLU Support
The wolfSSL team recently merged a significant improvement to their CMake build system with Pull Request #8548. This enhancement adds a new WOLFSSL_CLU option to CMakeLists.txt, providing CMake users with the same functionality that was previously only available through the –enable-wolfclu option in the autotools build system.
What is wolfCLU?
Before diving into the technical details, let’s understand what wolfCLU is. The wolfSSL Command Line Utility (wolfCLU) is a powerful tool that provides cryptographic operations through a command-line interface. It leverages wolfSSL’s cryptographic library (wolfCrypt) to perform common operations such as:
- Creating certificates and certificate requests
- Generating public/private key pairs
- Creating and verifying digital signatures
- Encrypting and decrypting files
- Parsing X.509 certificates
- Establishing certificate chains with a Certificate Authority
wolfCLU serves as an alternative to OpenSSL’s command-line tools, particularly for environments where OpenSSL is not installed or for users who prefer wolfSSL’s lightweight and security-focused implementation.
The Technical Enhancement
The PR adds a new WOLFSSL_CLU option to wolfSSL’s CMakeLists.txt that, when enabled, automatically configures wolfSSL with all the features required by wolfCLU. This includes:
- Certificate Operations:
- Certificate Generation (WOLFSSL_CERTGEN)
- Certificate Request Generation (WOLFSSL_CERTREQ)
- Certificate Extensions (WOLFSSL_CERTEXT)
- Cryptographic Algorithms:
- MD5 (WOLFSSL_MD5)
- AES Counter Mode (WOLFSSL_AESCTR)
- ED25519 for digital signatures (WOLFSSL_ED25519)
- SHA-512 (WOLFSSL_SHA512)
- Triple DES (WOLFSSL_DES3)
- Additional Features:
- Key Generation (WOLFSSL_KEYGEN)
- OpenSSL Compatibility (WOLFSSL_OPENSSLALL)
- PKCS#7 Support (WOLFSSL_PKCS7)
- Compiler Flags:
- -DHAVE_OID_ENCODING: Enables OID encoding functionality
- -DWOLFSSL_NO_ASN_STRICT: Disables strict ASN.1 parsing
- -DWOLFSSL_ALT_NAMES: Enables alternative name support
- -DOPENSSL_ALL: Ensures OpenSSL compatibility functions are available
The PR also updates the GitHub Actions workflow to test this new option, ensuring it works correctly in the CI environment.
How to Use It
To build wolfSSL with wolfCLU support using CMake, simply add the -DWOLFSSL_CLU=yes option to your CMake command:
mkdir build cd build cmake .. -DWOLFSSL_CLU=yes make
This will configure wolfSSL with all the necessary features and compiler flags to support wolfCLU.
Conclusion
This PR demonstrates wolfSSL’s commitment to providing consistent build options across different build systems and improving the developer experience. By adding the WOLFSSL_CLU option to CMakeLists.txt, the wolfSSL team has made it easier for developers to build and use wolfCLU with wolfSSL, regardless of their preferred build system.
For more information about wolfCLU and its capabilities, visit the wolfSSL website or check out the wolfCLU GitHub repository.
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
Using secp256k1 with wolfSSL: A Step-by-Step Guide
Elliptic curve cryptography (ECC) is increasingly popular in secure communications, and secp256k1—famous for its use in Bitcoin and Blockchains—is a widely used curve. This blog post will walk you through building wolfSSL with support for secp256k1, generating an ECC certificate using that curve, and using it in a TLS connection with wolfSSL’s example client and server.
Step 1: Build wolfSSL with secp256k1 Support
Start by cloning the wolfSSL repository and building it with custom curve and certificate generation support:
# Download wolfssl from https://www.wolfssl.com/download/ cd wolfssl ./configure --enable-ecccustcurves=all --enable-keygen --enable-certgen --enable-certreq --enable-certext make sudo make install
Step 2: Generate a secp256k1 Certificate
Next, use the certgen example from wolfSSL’s examples repository.
git clone https://github.com/wolfssl/wolfssl-examples cd wolfssl-examples/certgen
Modify the example for secp256k1
In certgen_example.c, modify the key generation line to explicitly use secp256k1:
- ret = wc_ecc_make_key(&rng, 32, &newKey); + ret = wc_ecc_make_key_ex(&rng, 32, &newKey, ECC_SECP256K1);
Add Key Output in PEM Format
To write the private key to a file, add the following block after certificate generation (be sure to add in proper error checks):
derBufSz = wc_EccKeyToDer(&newKey, derBuf, LARGE_TEMP_SZ); pemBufSz = wc_DerToPem(derBuf, derBufSz, pemBuf, LARGE_TEMP_SZ, ECC_PRIVATEKEY_TYPE); if (pemBufSz < 0) goto exit; file = fopen("newCert.key", "wb"); if (!file) goto exit; ret = (int)fwrite(pemBuf, 1, pemBufSz, file); fclose(file);
Build and Run
make ./certgen_example
You should now have newCert.pem and newCert.key files using a secp256k1 key.
Step 3: Configure Client/Server for secp256k1
Go back to the wolfssl directory and modify the client example to explicitly support the secp256k1 curve:
+++ b/examples/client/client.c @@ -3707,6 +3707,9 @@ #endif + + wolfSSL_CTX_UseSupportedCurve(ctx, WOLFSSL_ECC_SECP256K1); + #if defined(HAVE_SUPPORTED_CURVES)
Run the Server and Client
Use the generated cert/key with the server, and run the client with a trusted CA cert:
./examples/server/server -d -c newCert.pem -k newCert.key ./examples/client/client -A ./certs/ca-ecc-cert.pem
If everything is set up correctly, you'll see output like:
SSL version is TLSv1.2 SSL cipher suite is TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 SSL curve name is SECP256K1 I hear you fa shizzle!
You’ve just built wolfSSL with support for custom ECC curves, generated a certificate using secp256k1, and successfully used it in a TLS session. This setup is great for anyone integrating Bitcoin-style cryptography into embedded or resource-constrained systems using wolfSSL.
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
Weekly updates
Archives
- July 2025 (1)
- June 2025 (22)
- May 2025 (25)
- April 2025 (24)
- March 2025 (22)
- February 2025 (21)
- January 2025 (23)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)