Meeting evolving security requirements like CNSA 2.0 and FIPS 140-3 is becoming a critical challenge for satellite systems, especially when deployments must remain secure for decades with limited ability to update. Design decisions made early in the architecture directly impact certification timelines, long-term security, and system maintainability. Register today: Designing Secure Satellite Systems with FIPS […]
Read MoreMore TagMonth: May 2026
Getting Started with wolfHSM for Automotive
Secure automotive ECUs without vendor lock-in or fragmented HSM APIs. Join us on May 13 at 9 AM PT for a technical introduction to wolfHSM for automotive systems. Register now: Getting Started with wolfHSM Date: May 13 | 9 AM PT Modern vehicle platforms must support secure boot, firmware authentication, key management, and evolving cryptographic […]
Read MoreMore TagCaliptra: Your Silicon’s Security Chaperone
As a member of the wolfSSL team, each day is a new opportunity to learn. This time, we delve into Caliptra and our plans for it in the near future. Architecture and Purpose Caliptra isn’t just a piece of software or hardware, it is a specification for software combined with hardware as its own module, […]
Read MoreMore TagFIPS 140-3 Validated Proxmox VE: Is There Demand?
We’re looking at bringing FIPS 140-3 validated cryptography to Proxmox VE. Before we commit, we want to know if the market actually wants it. Here’s the situation. Broadcom’s VMware licensing changes are pushing a lot of enterprise customers toward Proxmox. Proxmox is solid (Debian-based, KVM, mature, production-proven) and the migration makes technical sense. But organizations […]
Read MoreMore TagwolfSSL as a Cryptographic Service Provider for VPP
The engineering team at wolfSSL is working on integrating wolfCrypt as a cryptographic service provider for FD.io’s Vector Packet Processing framework. This will give VPP deployments access to FIPS 140-3 validated cryptography, hardware acceleration support, and wolfSSL’s battle-tested implementations directly within the high-performance data plane. This work targets network packet workloads demanding both regulatory compliance […]
Read MoreMore TagwolfProvider: Drop-In FIPS 140 Compliance for OpenSSL Applications
Do you have a Linux application, service, container, or distribution that depends on OpenSSL and must meet FIPS 140 requirements, or interoperate with systems operating in FIPS-approved mode? wolfProvider is an OpenSSL provider module that enables OpenSSL-based applications to use wolfSSL’s FIPS-validated cryptographic implementations. wolfProvider replaces OpenSSL’s cryptographic engine as the provider layer. Existing OpenSSL […]
Read MoreMore TagSecuring wolfHSM POSIX Transport with TLS
The recent addition of a TLS transport to the wolfHSM project provides improved transport-level protection for POSIX-based communications and was included with the latest release. Previously, when wolfHSM was used over POSIX transports (such as TCP sockets on a local system), security largely depended on controlling access to that transport. If an attacker could access […]
Read MoreMore TagNew X.509 Certificate Extension APIs in wolfSSL and wolfSSL JNI
wolfSSL now adds new public X.509 certificate-generation APIs for key identifiers, CRL distribution points, and Netscape certificate type handling. wolfSSL JNI builds on top of these APIs and now exposes matching Java methods in WolfSSLCertificate. New public wolfSSL APIs (C) int wolfSSL_X509_set_subject_key_id(WOLFSSL_X509* x509, const unsigned char* skid, int skidSz); int wolfSSL_X509_set_subject_key_id_ex(WOLFSSL_X509* x509); int wolfSSL_X509_set_authority_key_id(WOLFSSL_X509* x509, […]
Read MoreMore TagWebSocket Support Comes to the wolfMQTT Broker
wolfMQTT clients have been able to speak MQTT over WebSocket for a while. Now the broker can too. Starting with the latest code on master, the wolfMQTT broker accepts WebSocket connections alongside standard TCP – no proxy, no bridge, no extra infrastructure. Pass -w to open a WebSocket listener: ./src/broker -p 1883 -w 9001 This […]
Read MoreMore TagMigrating CRL Workflows from Bouncy Castle to wolfSSL JNI
If your Java stack currently uses Bouncy Castle for certificate tooling, moving CRL generation to wolfSSL’s JNI is straightforward once you map the flow correctly. wolfSSL JNI/JSSE uses wolfSSL’s native C crypto/TLS library, so projects can share one crypto implementation across Java and non-Java components. In environments that require validated cryptography, wolfSSL has significant experience […]
Read MoreMore Tag