I was trying out the std.http.Client (and subsequently, std.crypto.tls.Client), and have ran into an issue where there weren’t much feedback except for error.TlsInitializationFailed and a stack trace.
After adding a bunch of std.debug.print in std/crypto/tls/Client.zig, I believe this is likely a case where if the server sends the certificate chain out of order, the client fails to initialize.
Looking at RFC 8446, I noticed the below “SHOULD” (not required) part:
Note: Prior to TLS 1.3, “certificate_list” ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
Is there a way to use std.http.Client to allow out-of-order certificate chains?