RECENT BLOG NEWS

Ensuring your TLS certificates are still valid and haven’t been revoked is critical for secure communications. Two methods exist for this:

Certificate Revocation Lists (CRLs) are signed lists published by Certificate Authorities that clients download and check offline. They contain serial numbers of revoked certificates and must be regularly updated and cached by clients to remain effective. CRLs are simple and privacy-friendly but can become large over time and may not reflect revocations in real-time, leaving a window of vulnerability between updates.

Online Certificate Status Protocol (OCSP) lets clients query a CA’s responder in real-time to check if a certificate is revoked. It provides up-to-date, on-demand validation with lower bandwidth than downloading full CRLs. However, it requires an active network connection and can introduce latency or privacy concerns if the client queries the CA directly. OCSP Stapling addresses these issues by allowing the server to “staple” a recent OCSP response to the TLS handshake, improving performance and protecting client privacy.

wolfSSL supports both CRL and OCSP checking, plus OCSP stapling, giving you flexible, layered certificate validation that fits any use case. Enable CRL support to verify certificates against cached revocation lists, and OCSP for live, up-to-the-minute status checks. Use both together for maximum security—CRLs handle offline or initial checks, and OCSP keeps your system aware of recent revocations.

In wolfSSL, enabling these features is straightforward:

// Enable and load CRL
wolfSSL_CTX_EnableCRL(ctx, WOLFSSL_CRL_CHECKALL);
wolfSSL_CTX_LoadCRL(ctx, "crl.pem", WOLFSSL_FILETYPE_PEM, 0);

// Enable OCSP checking and stapling
wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_CHECKALL);
wolfSSL_CTX_EnableOCSPStapling(ctx);

Check out our manual for more information on these APIs:

• function wolfSSL_CTX_EnableCRL
• function wolfSSL_CTX_EnableOCSP

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

Most TLS libraries leave your certificates and private keys sitting in RAM long after they’re used — a jackpot for attackers with memory access. wolfSSL is the only TLS library that gives you the power to erase them completely with the wolfSSL_UnloadCertsKeys API. This function doesn’t just free memory — it securely zeroes out every byte of your sensitive data, ensuring nothing remains to be stolen.

From IoT devices and payment terminals to aerospace, automotive, and defense systems, wolfSSL_UnloadCertsKeys helps you meet the toughest security and compliance requirements. Combined with wolfSSL’s FIPS 140-3 validated cryptography, you get end-to-end protection: strong encryption for data in transit, and proactive memory sanitization for keys at rest in RAM. This synergy reduces your attack surface, thwarts memory dump attacks, and helps satisfy stringent standards like GDPR, HIPAA, and PCI DSS.

With wolfSSL, you’re not just encrypting traffic — you’re safeguarding the secrets behind it.

You can find more information on the wolfSSL_UnloadCertsKeys API in our manual.

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

The wolfSSL team is deprecating the following:

• WOLFSSL_TLS13_DRAFT preprocessor macro
• –enable-tls13-draft18 configure option

These components were originally introduced during the TLS 1.3 standardization process to support interoperability with implementations based on Draft 18 of the TLS 1.3 specification. During the multi-year standardization process (2014-2018), multiple draft versions were published before the final RFC 8446 was released in August 2018.

The –enable-tls13-draft18 configure option currently has no functional effect in the codebase and serves no purpose.

The WOLFSSL_TLS13_DRAFT macro, when defined, modifies version number handling in TLS handshakes to use draft-specific version numbers (TLS_DRAFT_MAJOR = 0x7f) instead of the final TLS 1.3 version numbers. This was designed to maintain compatibility with implementations during the transition period which ended long ago.

Maintaining compatibility with obsolete specifications introduces unnecessary complexity. The TLS ecosystem has fully migrated to the TLS 1.3 standard. For these reasons, we are eliminating draft compatibility.

This decision is not yet final. If you think you need these configuration flags to be available, please reach out to us at support@wolfssl.com and let us know.

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

Device Identifier Composition Engine (DICE) represents a fairly simple approach to hardware-based device identity and secure boot. DICE creates Cryptographic Device Identities (CDIs) through a blockchain-like verification process, where each boot stage measures the next component and derives unique Compound Device Identifiers using the following formula:

CDI_n = HMAC(CDI_n-1, Hash(program))

CDI_0 = UDS

The formulas mean that each element of the bootchain cryptographically verifies the previous CDI and then generates its new CDI to be passed on to the next stage boot loader. Of course the initial CDI is not a CDI at all, but a UDS (Unique Device Secret). This could be supplied by a PUF (Physically Unclonable Function) but does not need to be; as long as it is unique. wolfHSM is an excellent platform to securely store and sign this secret data. The same process is recursively repeated up the bootchain.

This creates an immutable chain of trust from hardware root secrets through firmware verification, enabling remote attestation and secure key provisioning for IoT devices. The observant reader will note that this differs from a conventional boot chain in that it allows for firmware later in the bootchain to verify the integrity of all the entities in the bootchain before it. Normally, entities in the boot chain only verify software images AFTER them in the boot process.

The specification supports and allows for a plethora of algorithms, notably DICE-compatible algorithms including ECDSA P-256, SHA-256, and Hash DRBG, making it ideal for resource-constrained embedded systems. For system integrators who have minimal binary footprint requirements, wolfCrypt can be built for Bare Metal ARM to support these algorithms within 30KB.

wolfBoot serves as an ideal secure bootloader for DICE-enabled systems, providing memory-efficient firmware authentication and update capabilities. The bootloader’s minimalist design and tiny HAL API also provides secure firmware update mechanisms.

Beyond wolfBoot, custom bootloaders can leverage the same optimized cryptographic implementations to build DICE-compatible secure boot solutions tailored to specific hardware platforms and security requirements.

Are you interested in seeing this work as part of your DICE bootchain? There is no need to wait any longer! Send a message to facts@wolfssl.com to register your interest in DICE with our team and raise the priority in our roadmap for wolfBoot and wolfHSM!

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