Manual Validation Callbacks vs. External TLS Engines for Certificate Verification

Direct answer

For long-term compatibility with the evolving std.crypto.tls API, a manual validation callback using std.crypto.x509 is preferred over linking an external TLS engine. It avoids external ABI and allocator dependencies and tracks the Zig standard library API surface. The manual callback approach does not provide sufficient built-in primitives for full RFC-5280 chain validation without additional work. std.crypto.x509 gives parsing and signature verification primitives; path building, name constraints, policy mapping and revocation are left to the caller.

Confirmed facts

• std.crypto.tls client does not perform RFC-5280 chain verification by default. It accepts any presented certificate unless a custom validation callback is supplied.
• Manual callbacks using std.crypto.x509 avoid external ABI dependencies and can be kept aligned with the Zig standard library's evolving API.
• std.crypto.x509 exposes certificate parsing and signature-verification primitives. Full RFC-5280 path validation including name constraints, policy mapping and revocation checking is not built in.
• External TLS engines provide complete, audited certificate verification at the cost of larger dependency footprints and potential allocator/ABI friction with Zig.

Likely explanation and practical trade-off

The stdlib choice keeps the binary lightweight and isolates you from C library versioning. The cost is you must implement trust store management, chain building, expiry, hostname verification and any policy rules yourself. An external engine gives you a battle-tested verifier immediately, but introduces a C ABI boundary, build complexity and a second moving target for upgrades.

For long-term maintenance, isolate verification behind a narrow interface so TLS handshake code does not change when you swap implementations.

Steps needed for this case

1. Decide verification requirements. If you need CRL/OCSP revocation, complex name constraints or policy mapping, plan for an external engine or a substantial manual implementation.
2. Inspect std.crypto.x509 in the Zig source you are targeting to confirm which RFC-5280 features are implemented and which are left to the caller.
3. Wrap the std.crypto.tls validation callback behind an internal interface. Implement hostname verification, expiry checks and basic chain signature verification using std.crypto.x509 primitives.
4. Build a small test client with a known certificate chain and compare the manual callback result against openssl verify output for parity.
5. Check Zig release notes or standard library documentation for breaking changes to the std.crypto.tls callback API before upgrading.

Assumptions and uncertainty: Zig std.crypto.tls and std.crypto.x509 APIs are still evolving. Callback signatures and x509 feature coverage may change between releases. Code written today may require updates. Verification and revocation handling are not guaranteed by the standard library.

One missing diagnostic detail that changes the recommendation: Do you require revocation checking via CRL or OCSP? If yes, an external engine is strongly preferred unless you are prepared to implement fetching and validation yourself.