RECENT BLOG NEWS

Release 5.8.0 of our wolfSSL library implements hybrid key exchange algorithms that combine conventional elliptic curve cryptography with post-quantum key encapsulation mechanisms (KEMs).

New Hybrid Groups: Combining elliptic curves (SECP256/384/521, X25519, X448) with ML-KEM. This provides compatibility with Chromium and other organizations that are together with wolfSSL leading the way in post-quantum migration. Some of the new hybrid groups were already done in previous releases. Here is the complete list of hybrid key exchange groups in TLS 1.3:

• WOLFSSL_P256_ML_KEM_512
• WOLFSSL_P384_ML_KEM_768
• WOLFSSL_P256_ML_KEM_768
• WOLFSSL_P521_ML_KEM_1024
• WOLFSSL_P384_ML_KEM_1024
• WOLFSSL_X25519_ML_KEM_512
• WOLFSSL_X25519_ML_KEM_768
• WOLFSSL_X448_ML_KEM_768

The new release includes comprehensive test configurations demonstrating how to use these new hybrid groups in TLS 1.3 connections. Go ahead and start thwarting the “Harvest Now, Decrypt Later” threat model that is currently in play.

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 at wolfSSL would like to thank Goran Mahovlic and the entire Radiona team for inviting us to their headquarters in Zagreb, Croatia! We enjoyed the opportunity to present information on one of our flagship products, wolfBoot, during the recent OpenHardware Meet-up. The hospitality was outstanding and greatly appreciated!

Radiona is home to the awesome ULX3S FPGA + ESP32 board, first introduced to the general public by our friends over at the Crowd Supply Campaign and now available from Mouser Electronics.

Radiona embodies the true STEAM Spirit. So much more than the open source hardware is the community of passionate makers, students, engineers, and more. These people from all over the world participate in the Zagreb Makerspace and FER: the Faculty of Electrical Engineering and Computing at the University of Zagreb in Croatia.

A new and exciting board is also in the works from the collaboration between Radiona and Intergalaktik: the ULX4M! This is another open source FPGA board that has a CM4 connector for the many Raspberry Pi Carrier boards that accept a Compute Module.

The ULX3S is the only board (that we know of!) that is not only open source, but includes both open source FPGA and ESP32 projects, all on one board. Check out some of the many projects available.

New and exciting features will soon be added to the ULX3S, leveraging some of the features of the ESP32-S3. See the development README doc.

There’s extensive wolfSSL support for the ESP32, including not only Espressif ESP-IDF with optional Managed Components but also Arduino, PlatformIO, and more.

[gojimmypi] has several blogs on using wolfSSL with the ULX3S: Perhaps you’d like to SSH into the ESP32 on your ULX3S? That example leverages the core Espressif wolfSSH in the wolfssl-examples SSH-to-UART project.

The ULX3S could also be integrated into the Apple HomeKit ecosystem.

Interested in getting Started with wolfSSL on the ESP32? Check out our YouTube video:

See our prior blog about using the ULX3S FPGA to create your own soft-core RISC-V, the same Hazard3 core used on the Raspberry Pi Pico 2 RP2350.

Meet Us at Events:

• Upcoming wolfSSL events
  • CYSAT Europe | May 14-15
  • Barcelona Cybersecurity Congress | May 21-23

• Upcoming Radiona events
  • Radiona.org OpenLAB and Neo-retro Corner @ DORS/CLUC 2025 | May 22-23
  • Radiona Blogs

For more information:

• wolfSSL Docs
• wolfSSL Manual
• Other ESP32 blogs
• Learn more about Radiona and wolfSSL.

Post Quantum

Do you have code that can be upgraded to Post Quantum? Read our recent blog to learn more!

FIPS Certified!

When you are ready to move on to the next step, wolfSSL will be there for you! Need to have your project NIST Certified? Recently we announced that wolfSSL is the First in the World to offer FIPS 140–3 Automated Submission with our NIST Certificate #4718.

Find out more:

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub

Download wolfSSL Now

Summary

A critical security incident exposed KeyPlug malware infrastructure due to the improper use of wolfSSL test certificates in production. The 24-hour exposure revealed sophisticated attack tools linked to the RedGolf/APT41 threat group, demonstrating how poor certificate management can compromise even advanced threat actors’ operations.

The Certificate Failure

The compromised server was identified through its WolfSSL test certificate:

Subject Common Name: www[.]wolfssl[.]com
Subject Organizational Unit: Support_1024
Issuer Organizational Unit: Consulting_1024
SHA-256: 4C1BAA3ABB774B4C649C87417ACAA4396EBA40E5028B43FADE4C685A405CC3BF

Critical Issues

• Test Certificate Misuse
  • Production use of wolfssl.com test domain
  • Weak 1024-bit keys (indicated by “_1024” suffix)
  • Certificate sharing across multiple attack servers
• Security Impact
  • Exposed Fortinet exploitation tools and C2 infrastructure
  • Enabled infrastructure correlation through shared certificates
  • Compromised operational security of advanced threat actors

Best Practices for WolfSSL Implementation

To avoid security lapses like the one described, it’s critical to follow best practices when deploying wolfSSL in production environments. The following guidelines focus on certificate requirements, security controls, and monitoring techniques:

Production Deployments

• Certificate Requirements
  • Use only trusted CA-issued certificates
  • Implement minimum 2048-bit RSA keys
  • Maintain proper validation chains
• Security Controls
  • Never use test certificates in production
  • Implement certificate pinning
  • Regular certificate rotation

Monitoring and Detection

• Certificate Auditing
  • Regular infrastructure scans
  • Certificate inventory management
  • Automated validation checks
• Warning Signs
  • Domains containing “wolfssl.com”
  • Organizational units with test indicators
  • Key sizes below 2048 bits
  • Invalid trust chains

Recommendations

To mitigate risk and ensure strong certificate hygiene, both WolfSSL users and security teams should take immediate action. Below are tailored recommendations for each group:

Immediate Actions

1. For WolfSSL Users
   • Audit all certificates
   • Remove test certificates
   • Implement CA-issued certificates
   • Verify proper key lengths
2. For Security Teams
   • Monitor for test certificate usage
   • Implement certificate validation
   • Regular infrastructure scanning
   • Maintain certificate inventory

Conclusion

Organizations must maintain strict separation between development and production certificates and implement proper certificate management policies to prevent similar exposures.

Please do not use wolfSSL test certificates in production because the corresponding private keys are published as part of the wolfSSL source code package, so by design, these certificates are insecure. The test certificate private keys are public!

Source:

• KeyPlug-Linked Server Briefly Exposes Fortinet Exploits, Webshells, and Recon Activity Targeting a Major Japanese Company
• Exposed KeyPlug Malware Staging Server Contains Fortinet Firewall and VPN Exploitation Scripts

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 evolving landscape of cryptographic security, supporting multiple signature algorithms within a single certificate has become increasingly important. These certificates are known as Chimera certificates, a moniker coined by the X9.146 banking standards team. They provide enhanced security, flexibility, and agility, especially for the transition to post-quantum cryptography. As well, wolfSSL also understands the new TLS 1.3 CKS extension as defined by the X9.146 banking standard draft.

Chimera certificates are X.509 certificates that contain two public keys and signatures. These certificates are implemented through the use of three extensions:

• Subject Alternative Public Key Info (SAPKI): Contains an alternative public key
• Alternative Signature Algorithm: Specifies the algorithm used for the alternative signature
• Alternative Signature Value: Contains the actual bitstring of the alternative signature

In X.509 certificates, extensions can be marked as either “critical” or “non-critical.” Critical extensions MUST be understood and processed by the certificate validator. If a validator doesn’t recognize a critical extension, it MUST reject the certificate. Non-critical extensions can be safely ignored if not understood.

Before release 5.8.0, wolfSSL’s dual algorithm certificate implementation did not properly support the parsing of these extensions if they were marked as Critical. This was because the whole purpose of these extensions was to facilitate migration by allowing unmigrated systems to ignore the alternative public key and signatures. In that context, marking these extensions as critical made no sense.

That said, these extensions are standardized in the 2019 edition of the ITU-T X.509 standard. In that document, under recognition that there might be other future applications for these extensions, marking these extensions as critical is permitted.

The addition of critical extension support for Chimera certificates extensions represents an important compliance step. Without standards, interoperability would not be possible.

As the cryptographic landscape continues to evolve, especially with the ongoing transition to post-quantum algorithms, enhancements such as Chimera certificate support will become increasingly valuable. wolfSSL continues to demonstrate its commitment to providing a robust, standards-compliant, and forward-looking cryptographic library.

If you have question about any of the above, please contact us at >a href=”mailto”facts@wolfssl.com”>facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now