FIPS 140-3 Enabled Linux Network Infrastructure with GnuTLS-wolfSSL

wolfSSL is thrilled to announce that core network infrastructure applications can now achieve FIPS 140-3 compliance through our GnuTLS-wolfSSL integration. This breakthrough comes from our ongoing work integrating wolfSSL’s FIPS 140-3 certified cryptography (wolfCrypt) into GnuTLS, enabling a true drop-in solution for Linux applications.

For developers and system administrators in government, defense, finance, healthcare, and other regulated industries, this eliminates a critical barrier to deploying secure network infrastructure that must meet federal compliance standards.

What We’ve Built

Unlike traditional approaches requiring extensive rewrites, our solution operates entirely behind the scenes. By patching GnuTLS at the library level with wolfCrypt’s certified cryptographic operations, applications can gain FIPS 140-3 compliance without changing a single line of their code. Simply rebuild with our patched GnuTLS library, and your entire networking stack achieves FIPS compliance.

We’re continuously validating this integration through CI/CD testing against 17 applications, testing target versions, latest releases, and master branches to ensure rock-solid compatibility. Our fork is now debianized, making deployment as simple as installing a standard Debian package.

Network Applications Now FIPS-Ready

chrony – The widely-deployed NTP implementation for time synchronization across Linux systems, critical for distributed infrastructure and audit logging.

NetworkManager – The standard Linux network connection manager that handles everything from WiFi to VPN connections in modern distributions.

libnice – Implements ICE protocol for NAT traversal, essential for WebRTC and real-time communication applications.

curl & wget – The ubiquitous data transfer utilities now gain a clear path to FIPS compliance for secure communications.

How We Enable FIPS Compliance

These applications rely on GnuTLS for TLS connections, certificate handling, and cryptographic operations. By integrating wolfSSL’s FIPS 140-3 certified wolfCrypt module into GnuTLS, we deliver a true drop-in solution. Depending on the algorithms your application uses, you may need no code changes at all, just rebuild with our patched library and achieve FIPS compliance across your network infrastructure.

The debianized package makes deployment straightforward: install our GnuTLS-wolfSSL package on your Debian-based system, and your network applications automatically benefit from FIPS-certified cryptography.

Questions?

Take a more in-depth look at our integration on the wolfSSL GitHub, if you need support we are more than happy to help you out, you can email us at support@wolfssl.com.

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

FIPS 140-3 Enabled Linux Desktop & Media Applications with GnuTLS-wolfSSL

wolfSSL is thrilled to announce that desktop, development, and media applications can now achieve FIPS 140-3 compliance through our GnuTLS-wolfSSL integration. This breakthrough comes from our ongoing work integrating wolfSSL’s FIPS 140-3 certified cryptography (wolfCrypt) into GnuTLS, enabling a true drop-in solution for Linux applications.

For developers and organizations in government, defense, finance, healthcare, and other regulated industries, this eliminates barriers to deploying user-facing applications and specialized libraries that must meet federal compliance standards.

What We’ve Built

Unlike traditional approaches requiring extensive rewrites, our solution operates entirely behind the scenes. By patching GnuTLS at the library level with wolfCrypt’s certified cryptographic operations, applications gain FIPS 140-3 compliance without changing a single line of their code. Simply rebuild with our patched GnuTLS library, and your entire application stack achieves FIPS compliance.

We’re continuously validating this integration through CI/CD testing against 17 applications, testing target versions, latest releases, and master branches to ensure rock-solid compatibility. Our fork is now debianized, making deployment as simple as installing a standard Debian package.

Desktop & Media Applications Now FIPS-Ready

glib-networking – The GNOME network stack that provides TLS support for countless GTK-based applications across Linux desktops.

libvnc – Enables VNC client and server functionality for remote desktop access and support tools.

libvte – The terminal emulator widget library used by GNOME Terminal and other popular Linux terminal applications.

libcups – The Common Unix Printing System library that handles secure printing operations across networks.

libcamera – Modern camera support library for Linux systems, handling secure camera data streams.

QPDF – PDF manipulation library for viewing, editing, and transforming PDF documents securely.

libjcat – Archive verification library used by fwupd and other tools for validating signed package integrity.

RTMP – Real-Time Messaging Protocol implementation for secure streaming media applications.

How We Enable FIPS Compliance

These applications rely on GnuTLS for TLS connections, certificate handling, secure communications, and cryptographic operations. By integrating wolfSSL’s FIPS 140-3 certified wolfCrypt module into GnuTLS, we deliver a true drop-in solution. Depending on the algorithms your application uses, you may need no code changes at all, just rebuild with our patched library and achieve FIPS compliance across your desktop and media applications.

The debianized package makes deployment straightforward: install our GnuTLS-wolfSSL package on your Debian-based system, and your applications automatically benefit from FIPS-certified cryptography.

Questions?

Take a more in-depth look at our integration on the wolfSSL GitHub, if you need support we are more than happy to help you out, you can email us at support@wolfssl.com.

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

New Docker containers for Python FIPS 140-3 integration

For developers seeking to implement FIPS 140-3 compliance in their secure Python applications, wolfSSL has already been offering effective solutions:

  • wolfProvider enables the use of wolfCrypt as the underlying crypto provider for OpenSSL.
  • The wolfSSL Python ports let you completely replace OpenSSL with wolfSSL in Python’s ssl module.

However, we understand that the initial setup – compiling wolfSSL with the right flags and correctly configuring the Python environment – can introduce friction, especially when you need to get a project off the ground quickly.

The wolfSSL Python containers

To streamline your development workflow, we’ve launched a new set of wolfSSL Docker containers which provide a ready-to-use Python environment pre-configured to use FIPS 140-3 validated wolfSSL technology.
We provide three different Dockerfiles. Which one you should choose depends on your needs:

  • Dockerfile.provider: uses wolfProvider to register wolfSSL as the default OpenSSL provider in the container. This results in a Python runtime that still uses OpenSSL, but with FIPS certified wolfSSL crypto underneath.
  • Dockerfile.provider-min: a simpler Dockerfile that achieves the same result as above. Instead of building Python on top of an Alpine base image, it directly uses the official Python Alpine image, making it easier to update to new Python versions.
  • Dockerfile.osp: uses the wolfSSL Python ports, resulting in a Python runtime that uses wolfSSL only. The Dockerfile also deletes traces of OpenSSL from the system to prevent OpenSSL usage, which may cause some non-Python applications to stop working. This solution is useful in strict FIPS scenarios where OpenSSL must be entirely excluded.

Getting started

Setting up these containers requires an active wolfCrypt FIPS license. Feel free to contact fips@wolfssl.com for more information.
Once you have the appropriate 7z archive password, building and running the containers is as simple as cloning the GitHub repository, writing your password to a password.txt file and executing make run-provider, make run-provider-min or make run-osp. Further information is available in the README.

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

FIPS 140-3 Enabled WebKit2GTK with wolfSSL

wolfSSL is thrilled to announce that it is now possible to build FIPS 140-3 compliant applications using WebKit2GTK. This achievement comes from our recent porting efforts, integrating wolfSSL’s FIPS 140-3 certified cryptography (wolfCrypt) into core cryptographic libraries: GnuTLS, OpenSSL, and Gcrypt.
For developers in government, defense, finance, healthcare, and other regulated industries, this eliminates a key hurdle to deploying modern, secure Linux applications that must meet federal standards.

What is WebKitGTK?

  • WebKitGTK is the engine that renders web content inside most Linux applications, bringing browser-like capabilities to custom software.
  • WebKit: The open-source core rendering engine used in Apple’s Safari browser. It’s responsible for parsing HTML, CSS, and JavaScript, then rendering to display webpages.
  • GTK: A widely used toolkit for crafting graphical user interfaces (GUIs) on Linux, handling elements like windows, buttons, menus, and user interactions.
  • WebKitGTK: The integration layer that lets developers embed WebKit’s rendering power directly into GTK-based apps. This is ideal for building kiosks, secure browsers, information dashboards, or any app that needs to display web content without relying on a standalone browser.

How We Enable FIPS Compliance

WebKitGTK relies on cryptographic libraries for secure operations, including establishing TLS connections (e.g., HTTPS via GnuTLS in libsoup), certificate handling, and data encryption (usually via OpenSSL or libgcrypt). By porting wolfSSL’s FIPS 140-3 certified wolfCrypt module into these libraries, we’ve delivered a true drop-in solution. Depending on the algorithms your application uses, you may need no code changes at all, just rebuild with our patched libraries and your entire stack achieves FIPS compliance.

Question?

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 giving Libgcrypt FIPS 140-3 cryptography

The wolfSSL-libgcrypt integration demonstrates how a shim layer architecture can bridge two large, independently developed cryptographic libraries while maintaining API compatibility and achieving FIPS 140-3 compliance. This project specifically targets libgcrypt version 1.11.0 and the current and future work of the port can be viewed in the wolfSSL/libgcrypt-wolfssl repo.

Architecture: The Shim Layer Approach

The integration was designed as a non-invasive shim layer that keeps libgcrypt’s public API completely intact. It uses conditional compilation and dynamic function pointer assignment to redirect crypto operations to wolfSSL, all while being totally invisible to the apps using it.
Function Redirection Mechanism
At its core, the shim layer acts like a proxy, intercepting API calls and sending them to the right backend. You’ll find the main implementation in cipher/cipher.c, where the _gcry_cipher_setup_mode_ops function is the central switchboard for cipher operations.
When HAVE_WOLFSSL is defined, special preprocessor blocks containing switch statements on algorithm identifiers (like GCRY_CIPHER_AES) decide which function pointers get assigned to the cipher handle’s c->mode_ops structure. For example, if wolfSSL is enabled, an AES-GCM operation sets the encrypt function pointer to _wc_cipher_aes_gcm_encrypt instead of the usual _gcry_cipher_gcm_encrypt.
Data Structure Extension
Instead of replacing libgcrypt’s main context structures, the project extends them to keep things stable. The gcry_cipher_handle struct has new unions containing new wolfSSL-specific context structures (like wc_ccm_context_t and wc_gcm_context_t). These are only included when HAVE_WOLFSSL is defined and store state and buffers used only by the wolfSSL backend.
FIPS Compliance Through Build-Time Enforcement
The project’s FIPS 140-3 compliance model is enforced during the build process through conditional compilation. This provides stronger security guarantees than just checking at runtime. The –enable-wolfssl-fips flag defines the ENABLED_WOLFSSL_FIPS preprocessor macro and modifies algorithm lists to include only FIPS-approved primitives.
Algorithm Status with FIPS
Enabled Algorithms (wolfSSL backend):

  • AES-128/192/256 (ECB, CBC, CTR, OFB modes)
  • AES-GCM and AES-CCM authenticated encryption
  • AES-CMAC message authentication
  • RSA operations (sign, verify, encrypt, decrypt with key size ? 2048)
  • ECDSA with NIST curves P-192, P-256, P-384, P-521
  • SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
  • SHA3-224, SHA3-256, SHA3-384, SHA3-512
  • HMAC with approved SHA algorithms

The codebase uses preprocessor macros like ENABLED_WOLFSSL_FIPS and HAVE_WOLFSSL to conditionally compile out entire algorithms, specific cipher modes, and non-compliant test cases. This means it’s impossible for the library to run non-approved algorithms in FIPS builds because the code simply isn’t there in the compiled binary.

Symmetric Cipher Implementation

AES Block Cipher Modes
The implementation for standard block cipher modes (ECB, CBC, OFB, CTR) in cipher/rijndael.c is a direct mapping between libgcrypt and wolfSSL APIs. Wrapper functions like _wc_aes_cbc_enc and _wc_aes_ctr_enc are just thin shims that translate libgcrypt calls into wolfSSL bulk API calls.
Necessary state (like initialization vectors and counter blocks) is managed within the wolfSSL Aes context. The wc_aes_setkey function initializes both encryption and decryption contexts within the RIJNDAEL_context struct, making sure all key schedules are ready when users set keys.

AES Authenticated Encryption (AEAD) Modes

Integrating AES-GCM and AES-CCM required solving a fundamental API mismatch. libgcrypt’s API supports streaming operations where data can be fed in incrementally.
The solution involves a buffering and re-computation strategy:

  • Contextual Buffers: wolfSSL-specific context structures hold dynamically allocated buffers for AAD, plaintext, and ciphertext, plus members to track length and capacity.
  • Data Accumulation: When users call libgcrypt functions, wolfSSL wrappers intercept and accumulate the data. For instance, _wc_cipher_aes_gcm_authenticate appends AAD chunks to internal buffers, resizing them as needed.
  • Deferred and Repeated Execution: The actual wolfSSL function call is deferred and re-executed with each new data chunk. The _wc_cipher_aes_gcm_encrypt function passes entire accumulated buffers to wc_AesGcmEncrypt on every invocation, then calculates the correct offset into the newly generated ciphertext and copies only the portion corresponding to the most recent input.

Asymmetric Cryptography Implementation

Multi-Precision Integer (MPI) Interoperability
The biggest technical challenge was the fundamental incompatibility between libgcrypt’s gcry_mpi_t and wolfSSL’s mp_int multi-precision integer representations. A robust data marshalling layer was developed using raw byte arrays as a standardized intermediary format.
Key helper functions _libgcrypt_mpi_to_wc_mpi and _wc_mpi_to_libgcrypt_mpi handle the conversion:

  • gcry_mpi_t to mp_int: Uses _gcry_mpi_aprint (with GCRYMPI_FMT_USG flag) to serialize libgcrypt MPI objects into unsigned, big-endian byte arrays, then mp_read_unsigned_bin to load values into wolfSSL mp_int structures.
  • mp_int to gcry_mpi_t: Uses mp_to_unsigned_bin to serialize mp_int into byte arrays, followed by _gcry_mpi_scan to create new gcry_mpi_t objects.

Critical details include padding and alignment handling, as wolfSSL functions often need fixed-length inputs, while libgcrypt produces minimally sized arrays omitting leading zero bytes.

RSA Implementation

RSA operations in cipher/rsa.c use the MPI marshalling layer to translate key components and data before calling wolfSSL primitives. The wc_rsa_sign function extracts key components (n, e, d, p, q, u) from libgcrypt S-Expressions, converts them to wolfSSL RsaKey structures, performs signing operations via wc_RsaPSS_Sign or wc_RsaDirect, then converts results back to gcry_mpi_t objects.

ECC/ECDSA Implementation

ECDSA implementation follows the same marshalling pattern, but with additional complexities for curve identification and parameter alignment. The _gcry_ecc_ecdsa_sign function maps libgcrypt’s string-based curve names to wolfSSL integer constants, converts private keys and message hashes to byte arrays, manually right-aligns private key material into fixed-size buffers matching curve field sizes, then imports into wolfSSL ecc_key structures for signing operations.

Hashing and Message Authentication

Hash Algorithm Integration
Hash algorithm replacement was done by modifying core digest specification structures. For each algorithm, gcry_md_spec_t structures were updated (using conditional compilation) to redirect function pointers to wolfSSL wrapper functions when HAVE_WOLFSSL is defined.
Context structures like SHA256_CONTEXT were extended to include wolfSSL objects (e.g., wc_Sha256). Wrapper functions operate on these embedded contexts, with wolfssl_sha256_init calling wc_InitSha256 and wolfssl_sha256_final calling wc_Sha256Final.

HMAC and CMAC Integration

HMAC integration uses the generic hashing framework. The _gcry_md_open function checks for GCRY_MD_FLAG_HMAC and routes calls to _gcry_wc_md_open for wolfSSL context setup. The gcry_wc_md_context structure contains linked lists of GcryWcDigestEntry nodes, each holding wolfSSL Hmac contexts and algorithm identifiers, allowing single libgcrypt handles to manage multiple concurrent HMAC.
CMAC implementation in cipher/mac-cmac.c is more direct, populating wc_aes_cmac_ops structures with wolfSSL wrapper functions that call wolfSSL CMAC APIs like wc_InitCmac, wc_CmacUpdate, and wc_CmacFinal. FIPS-related modifications replaced non-FIPS-approved functions with compliant equivalents.

Questions?

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

Download wolfSSL Now

Securing BoringTun with wolfSSL’s FIPS 140-3 Cryptography

We’re excited to announce that wolfSSL is taking the next step in its journey to bring FIPS 140-3 compliance to the WireGuard ecosystem. Following our successful ports of our FIPS crypto into both WireGuard-linux and Wireguard-GO, we are setting our sights on a new target: BoringTun.

BoringTun is a popular, high-performance implementation of the WireGuard protocol written in Rust. It’s used by major players in the tech industry and as the demand for robust, certified cryptographic solutions grows — especially within government and highly regulated sectors — it is a logical next step to provide the same level of cryptographic assurance for this key WireGuard implementation.

wolfSSL has begun the process of integrating our FIPS 140-3 validated library wolfCrypt directly into BoringTun. This project will replace BoringTun’s existing cryptographic backend with a FIPS-compliant alternative, providing the same high-speed, modern protocol that WireGuard is known for, but with the added assurance of a government-certified cryptography module.

This will make BoringTun a viable option for organizations that have a CMMC 2.0, FEDRAMP, or FIPS 140-3 requirement. Are you interested in a FIPS certified BoringTun?

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

Download wolfSSL Now

Top 15 FIPS Terms You Should Know – The Full Breakdown

We recently shared our top 15 FIPS acronyms and terms to help you get familiar with the basics. Now, let’s dive deeper into what each of these means and why they matter in the FIPS 140-3 certification process.

  1. FIPS – Federal Information Processing Standards

    FIPS are standards published by the U.S. federal government that specify security requirements for cryptographic modules. FIPS 140-3 is the current standard for validating cryptographic modules, ensuring they meet strict security and implementation guidelines for use in government and regulated industries.

  2. NIST – National Institute of Standards and Technology

    NIST develops and maintains FIPS standards. It also oversees the Cryptographic Module Validation Program (CMVP), coordinating with testing labs and vendors to ensure modules meet FIPS 140-3 requirements.

  3. CMVP – Cryptographic Module Validation Program

    This is the official program, jointly run by NIST and Canada’s CCCS, that validates cryptographic modules against the FIPS 140-3 standard. Vendors submit their modules to CMVP-accredited labs, which test and verify compliance before issuing certificates.

  4. CAVP – Cryptographic Algorithm Validation Program

    Before a cryptographic module can be validated, each cryptographic algorithm it uses (such as AES, SHA, ML-KEM, ML-DSA, RSA, ED25519, KDF’s for various protocols… etc.) must be validated under CAVP. This ensures the algorithms are correctly implemented and function as intended and guarantees interoperability with any other validated module(s).

  5. ESV – Entropy Source Validation

    Entropy Source Validation is a separate validation process that verifies the quality and reliability of the randomness source used by the cryptographic module, crucial for secure key generation and other cryptographic operations that depend on high quality entropy to guarantee certain levels of bit-strength.

  6. ACVP – Automated Cryptographic Validation Protocol

    ACVP is the automated system that facilitates cryptographic algorithm testing within the CAVP framework. It allows machine-to-machine communication between vendors and validation servers (DEMO), and labs and validation servers (PRODUCTION) speeding up the testing process and reducing errors.

  7. NVLAP – National Voluntary Lab Accreditation Program

    NVLAP accredits independent labs authorized to perform FIPS 140-3 testing. Only NVLAP-accredited labs can conduct the official testing required for CMVP certification.

  8. SP – Security Policy

    The Security Policy is a detailed document that describes the cryptographic module’s security features, intended use, and operational modes. It defines how the module should be configured and used to remain compliant and in the approved mode of operation.

  9. UG – User Guide

    The User Guide provides instructions for deploying and operating the cryptographic module securely and in compliance with FIPS requirements. It ensures end users configure and use the module correctly so it is running the FIPS 140-3 approved mode of operation.

  10. OE – Operational Environment

    The Operational Environment refers to the specific combination of hardware (chipset), operating system, and cryptographic module configuration used during testing. Different OEs require separate validation to ensure proper validation/certification.

  11. Tested Configuration

    The Tested Configuration specifies the exact hardware and software setup (including form factor, OS version, chipset details) that was used during testing. Users must match this configuration to maintain FIPS 140-3 validation.

  12. OEUP – Operational Environment Update

    An OEUP is a process to add a new Operational Environment (new chipset or OS) to an existing FIPS certificate without undergoing full revalidation. This allows validated modules to support more platforms efficiently over time.

  13. UPDT – Module Update

    A Module Update (UPDT) applies when there are security-relevant changes to the cryptographic module, such as updates to code, algorithms, or key management. It requires a new certificate and resets the module’s sunset date.

  14. PAA – Processor Algorithm Acceleration

    Processor Algorithm Acceleration refers to hardware-assisted cryptographic acceleration features, like AES-NI or Arm Crypto Extensions, which improve performance and efficiency of cryptographic operations within validated modules.

  15. RBND – Rebrand

    Rebranding (RBND) lets a company apply its own branding and logo to an existing FIPS 140-3 certified module, often referred to as white-labeling. This helps companies market validated products without needing to repeat the entire certification process or point to a third-party certificate for their products.

Understanding these terms is critical whether you’re developing, integrating, or managing FIPS 140-3 validated cryptographic modules. At wolfSSL, we leverage this knowledge to help customers navigate complex validation requirements and deliver secure, compliant solutions.

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

Top 15 FIPS Terms You Should Know

Working with FIPS 140-3 can get confusing fast, especially with all the acronyms involved. To help cut through the noise, here are our top 15 FIPS-related terms:

  • FIPS – Federal Information Processing Standards
  • NIST – National Institute of Standards and Technology
  • CMVP – Cryptographic Module Validation Program
  • CAVP – Cryptographic Algorithm Validation Program
  • ESV – Entropy Source Validation (separate from but complimentary to a FIPS certificate)
  • ACVP – Automated Cryptographic Validation Protocol
  • NVLAP – National Voluntary Lab Accreditation Program
  • SP – Security Policy
  • UG – User Guide
  • OE – Operational Environment (Chipset + OS + Cryptographic module)
  • Tested Configuration – OE description including form factor used for testing
  • OEUP – Operational Environment Update (add an OE to an existing FIPS certificate)
  • UPDT – Module Update (Security relevant changes to an existing FIPS module, results in a new certificate # and new sunset date)
  • PAA – Processor Algorithm Acceleration (Hardware assisted cryptographic acceleration)
  • RBND – Rebrand an existing FIPS certificate into your company’s own letter/logo-head for marketing purposes (often referred to as a white-label)

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

MCP (Model Context Protocol) and FIPS-140-3 Requirements

Are you one of our customers tasked by the US federal government to implement their newly minted AI initiatives? Then go get a cup of coffee and sit down because you are going to want to hear what we have to say about the MCP (Model Context Protocol) and how it relates to FIPS 140-3.

The Model Context Protocol (MCP) is a framework that provides AI models with relevant, structured context to improve efficiency and accuracy around how the data is used. It ensures AI agents receive pertinent data and environmental cues for optimal performance, reducing ambiguity, enhancing decision-making, and streamlining AI-environment interaction.

The protocol works on a client-server model. The servers are, generally speaking, data and service providers while the clients are the AI agents. MCP servers can provide real-time sensor data, historical archives, structured databases (CRM, ERP), knowledge bases, and external API access (weather, mapping, translation). MCP clients are AI entities, from chatbots to complex autonomous systems, needing external data/services. Examples include, LLMs, decision-making AIs and robotics/autonomous vehicles.

Here are just a few examples of servers within agencies of the US Federal Government:

The messages are formatted as JSON with some predefined fields. The important part is that these messages need to be authenticated, encrypted, and integrity checked. From the https://modelcontextprotocol.io/docs/concepts/transports:

> Always use TLS/HTTPS for production deployments

So if the US federal government is going to be contracting you to create an AI MCP client to leverage these servers, then you can bet your bottom dollar that it needs to be using FIPS 140-3 certified cryptography.

Want to learn more about our laddered-approach to FIPS 140-3 certifications and our evergreen licensing model? Send a message to fips@wolfssl.com or facts@wolfssl.com and we’ll be happy to explain it all to you!

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 Advances FIPS Leadership with New Certificate #5041 and Evergreen FIPS 140 Strategy

EDMONDS, Wash., Aug. 4, 2025 /PRNewswire-PRWeb/ — wolfSSL Inc., a globally renowned leader in cryptography and network security solutions, announces the latest milestone in its FIPS strategy with the issuance of FIPS 140-3 Validated Certificate #5041 for the wolfCrypt cryptographic module. This marks yet another step forward in wolfSSL’s long-term strategy to deliver agile, secure, and compliant cryptography across embedded and enterprise environments.

Evergreen FIPS 140-3 Subscription Program

FIPS 140-3 Validated Certificate #5041, effective through July 2030, extends the life cycle of wolfSSL’s industry-first SP800-140Br1 FIPS 140-3 Validated Certificate #4718, providing customers with flexibility, long-term assurance, and uninterrupted compliance under evolving FIPS 140-3 requirements.

This new certificate represents more than just continuity, it’s a reflection of our unwavering commitment to security leadership and customer success, said Todd Ouska, wolfSSL CTO. With our Evergreen Certificate Subscription, organizations using wolfSSL maintain continuous compliance, seamlessly transitioning to the latest validations without disruption or compliance gaps.

wolfSSL’s Evergreen Certificate Subscription eliminates expiration gaps for FIPS 140-3 validations. Customers purchasing an Evergreen FIPS Subscription automatically transition from Certificate #4718 to #5041 upon #4718’s expiration. With three more certificates already in the queue, each with rolling expiration dates, wolfSSL’s customers can easily maintain continuous FIPS coverage at an economic price.

Full Linux FIPS 140-3

wolfSSL’s Full Linux FIPS offering simplifies FIPS compliance for operating systems that host a variety of cryptography libraries. This solution is for NVIDIA Open GPU, Alpine, Dynebolic, Debian, Alma, Yocto, Rocky,Gentoo, KALI and other Linux distributions that don’t have a current FIPS solution. By patching key libraries, including GnuTLS, OpenSSL, NSS, libgcrypt, and the Linux kernel, wolfSSL enables FIPS 140-3 compliance without modifying application code. This solution can also be made available for BSD. Linux consumers will no longer be burdened with leaving their favorite distro to go to an expensive per cpu subscription to get to FIPS compliance.

This integration simplifies the lives of maintainers that need to get to FIPS 140-3 for government use. It provides immediate access to wolfCrypt’s validated algorithms, cutting down the time and complexity of certification from years to months.

Post Quantum FIPS 140-3 support

wolfSSL stays ahead of FIPS 140-3 certification with two additional certifications in process:

  • Our next cert adds SRTP and XTS to support secure real-time communications and encrypted storage
  • Post-Quantum FIPS 140-3 Certification: Aligned with CNSA 2.0 guidance and kicking off this year, this certification will feature quantum-resistant algorithms such as ML-KEM ML-DSA, LMS, and XMSS

These upcoming certifications reinforce wolfSSL’s reputation as the most agile and forward-compatible cryptographic provider on the market.

Contact us at: fips@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

Posts navigation

1 2 3 4 5 6