OxiTLS 0.3.0 Released — Leaf-Only-Chain OCSP False-Rejections Fixed, HPKE LabeledExpand Panic Eliminated

A security check that rejects legitimate traffic is still a bug, even when the bug is on the paranoid side.

Today we released OxiTLS 0.3.0 — a correctness release for the COOLJAPAN Pure Rust TLS transport stack. It fixes an OCSP staple validation bug that could turn a legitimate, CA-signed certificate into an unconditional handshake failure, converts an RFC 9180 HPKE helper from panicking to returning Result, and hardens the workspace’s own attacker-facing parsers with three new fuzz targets.

No OpenSSL. No native-tls. No ring on the default path. No FFI, no -sys crates on the path you actually ship. OxiTLS compiles to a single static binary with no system libraries and no build-time C toolchain — Pure Rust from the byte that hits the socket to the AEAD that protects it.

Why OxiTLS 0.3.0 is a game changer

Correctness releases are where a TLS stack either earns trust or loses it — a false rejection is embarrassing, but a false acceptance is dangerous, and the fix has to land on the right side of that line every time:

• OcspClientVerifier resolved the OCSP signer key by synthesising the end-entity certificate as its own issuer whenever the peer sent no intermediates. A CA-signed leaf presented with an empty intermediates list — a completely ordinary, spec-compliant server configuration — had its legitimate stapled OCSP response resolved against the leaf’s own SPKI instead of its real issuer’s, turning a valid staple into an unconditional BadSignature handshake failure that even SoftFail policy could not escape.
• labeled_expand, the RFC 9180 HPKE LabeledExpand primitive underneath every DhKem encap/decap call, panicked on a too-short PRK or an oversized output length instead of returning an error — a caller-controlled input shape could bring down the process rather than fail the handshake gracefully.
• The workspace’s own hand-rolled, attacker-facing wire-format parsers — SCT lists, precert TBSCertificate reconstruction, OCSP staples — had fuzz coverage on some paths but not all of them.

OxiTLS 0.3.0 ends all of that.

• The leaf-only-chain OCSP bug is fixed at the root cause. The end-entity certificate is now only treated as its own issuer when it is structurally self-signed (subject == issuer); otherwise a missing issuer correctly reports the staple as unverifiable (Unparseable), which policy governs from there instead of a hard-coded signature-forgery rejection. Six new tests pin the fix, including the exact case that broke: a CA-signed leaf with no intermediates under both SoftFail and HardRequire policy.
• labeled_expand can no longer panic. It now returns Result, and every internal caller — key_schedule_base, kem::extract_and_expand, and all four DhKem::encap/decap implementations — propagates the error instead of aborting the process.
• Three new fuzz targets close the parser coverage gap, alongside the existing client_config_parser: sct_list_parser (RFC 6962 §3.3 SCT list wire format), precert_hash_parser (RFC 6962 §3.2 precert TBSCertificate reconstruction), and ocsp_staple_parser — which fuzzes staple bytes end-to-end through the public OcspClientVerifier trait entry point against a fixed valid certificate pair.
• deny.toml now documents every intentional advisory and FFI edge with a written justification — cargo deny check advisories and cargo deny check bans both pass clean, with wrappers scoping on ring / aws-lc-rs / aws-lc-sys / security-framework limited to the specific dev-only, bench-only, or quarantine-crate edges that need them.
• sha2 and rand_core are each a single workspace.dependencies entry instead of six and two independently-pinned copies respectively, tightening the dependency graph without touching the deliberately-separate pins inside the vendored oxitls-rustcrypto-provider fork.
• 364 tests passing with default features (451 with --all-features) across 11 workspace crates (28,254 SLOC, tokei), zero clippy / compiler / rustdoc warnings.

Technical Deep Dive: where the fix lives, and what’s new around it

1. The crypto engine (oxitls-core, oxitls-rustcrypto-provider, oxitls-adapter-rustls-rustcrypto). The HPKE LabeledExpand fix lives in oxitls-adapter-rustls-rustcrypto/src/hpke/kdf.rs; the OCSP and SCT-adjacent verifier hardening lives in oxitls-adapter-rustls-rustcrypto/src/verifier/ocsp_client.rs, specifically the new end_entity_is_self_signed check that replaces the old blanket assumption.
2. New fuzz targets (oxitls-adapter-rustls-rustcrypto/fuzz). sct_list_parser, precert_hash_parser, and ocsp_staple_parser join client_config_parser, all targeting the crate’s own parsers rather than the upstream rustls-pemfile surface.
3. Four new runnable examples (oxitls/examples). tls13_client.rs, tls13_server.rs, mtls.rs, and verifier_composition.rs ship in this release — the last one builds the exact layered verifier pipeline (WebPkiServerVerifier → CertPinVerifier → SctVerifier → OcspClientVerifier) that would have surfaced the leaf-only-chain bug this release fixes.
4. Workspace hygiene. New root-level rustfmt.toml and clippy.toml pin the workspace MSRV (1.89) consistently; stale [compile-blocked] annotations on three already-passing RFC 7250 raw-public-key integration tests were removed from oxitls-adapter-rustls-rustcrypto/TODO.md.

Getting Started

cargo add oxitls

The client and server API is unchanged in 0.3.0 — the fixes in this release are internal correctness hardening, not surface changes:

use oxitls::{ClientBuilder, TlsError};

#[tokio::main]
async fn main() -> Result<(), TlsError> {
    let stream = ClientBuilder::new()
        .server_name("example.com")
        .connect("example.com:443")
        .await?;
    Ok(())
}

Want to see the exact verifier composition that surfaced the leaf-only-chain OCSP bug, and confirm it now resolves correctly? Run the new example directly:

cargo run --example verifier_composition -p oxitls

It layers CertPinVerifier → SctVerifier → OcspClientVerifier over WebPkiServerVerifier, connects to a local Pure-Rust TLS 1.3 server with no intermediates in its chain, and exercises the exact code path this release fixed.

What’s New in 0.3.0

• Fixed: OCSP staple false-rejection on leaf-only chains — OcspClientVerifier no longer treats a CA-signed end-entity as its own issuer when no intermediates are present; labeled_expand (RFC 9180 HPKE) no longer panics on a too-short PRK or oversized output length, returning Result instead.
• Added: three new fuzz targets (sct_list_parser, precert_hash_parser, ocsp_staple_parser); four new runnable examples (mtls.rs, tls13_client.rs, tls13_server.rs, verifier_composition.rs); root-level rustfmt.toml and clippy.toml.
• Changed: deny.toml now documents every RUSTSEC advisory exception and FFI-crate wrappers scope with a written justification; oxitls-native-certs’s platform-specific dependencies (security-framework, schannel) are now gated per-target instead of unconditional; sha2 and rand_core consolidated to single workspace.dependencies entries; post-quantum feature docs corrected to reflect that X25519MLKEM768 is fully wired (not a namespace reservation); oxiarc-deflate 0.3.6 → 0.4.1; p256/p384 0.14.0-rc.15 → 0.14.0 (stable).

Tips

• If you compose custom ServerCertVerifier stacks with OcspClientVerifier, re-test against leaf-only chains. Before 0.3.0, a CA-signed leaf presented with zero intermediates and a valid staple could hard-fail even under SoftFail policy — that specific shape now correctly falls through to a policy-governed Unparseable outcome instead.
• If you call oxitls_adapter_rustls_rustcrypto’s HPKE KEM functions directly, check your error handling. labeled_expand and everything built on it (key_schedule_base, extract_and_expand, all four DhKem::encap/decap impls) now returns Result where it used to be able to panic — a caller relying on the old panic-as-crash behavior needs to handle the new error path.
• Run cargo deny check advisories and cargo deny check bans after upgrading. Both now pass clean against this workspace’s own deny.toml, with every RUSTSEC exception and FFI wrapper edge documented inline — useful as a template if you maintain your own deny.toml downstream.
• The four new examples double as living documentation. verifier_composition.rs in particular is the clearest way to see how CertPinVerifier, SctVerifier, and OcspClientVerifier decorate WebPkiServerVerifier and delegate trust-chain validation onward.
• Two p256/p384 version lines are still expected in your Cargo.lock. oxitls-rustcrypto-provider tracks a proven 0.13.x fork line independently of the rest of the workspace’s 0.14.0 (now stable, no longer -rc); Cargo resolves both without conflict.

This is the foundation

OxiTLS belongs to NoFFI — the COOLJAPAN initiative to replace every C / C++ / Fortran / -sys FFI dependency in the Rust ecosystem with a clean, memory-safe, 100% Pure Rust implementation. A correctness release that closes a false-rejection on a completely ordinary certificate shape is exactly the kind of hardening that keeps that promise credible.

OxiTLS sits underneath a growing list of sibling COOLJAPAN projects — all bumped to oxitls = "0.3.0" (or one of its subcrates) as part of this release: OxiHTTP, OxiQUIC, and OxiRPC carry it as their transport-security layer; OxiSQL depends on it directly for its Postgres and MySQL adapters’ CryptoProvider; OxiGDAL pulls in oxitls-core, oxitls-adapter-rustls-rustcrypto, and oxitls-webpki-roots individually; and OxiRS, CeleRS, MielinOS, and VoiRS round out the list.

Repository: https://github.com/cool-japan/oxitls

Star the repo if you want a TLS stack where a false-rejection bug on an ordinary certificate chain gets fixed at the root cause, not patched around at the call site.

The era of a security check that’s paranoid at the cost of correctness is over. Pure Rust TLS — sovereign, safe, and precise about what it rejects — is here.

— KitaSan at COOLJAPAN OÜ August 6, 2026