# TLS Client and out-of-order certificate chains?

**URL:** <https://ziggit.dev/t/tls-client-and-out-of-order-certificate-chains/15926>\
**Category:** Help\
**Tags:** standard-library\
**Created:** [June 5, 2026, 2:36am UTC](https://ziggit.dev/t/tls-client-and-out-of-order-certificate-chains/15926 "2026-06-05T02:36:22Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![EncryptedSushi](https://ziggit.dev/letter_avatar_proxy/v4/letter/e/9d8465/32.png) [@EncryptedSushi](https://ziggit.dev/u/EncryptedSushi)\
**Post date:** [June 5, 2026, 2:36am UTC](https://ziggit.dev/t/tls-client-and-out-of-order-certificate-chains/15926/1 "2026-06-05T02:36:22Z")

</div>

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:

> **[RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 | RFC Editor](https://www.rfc-editor.org/info/rfc8446/#section-4.4.2)**
>
> rfc-editor.org is maintained by the Internet Engineering Task Force | This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed...

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?

---

<div class="post-metadata">

**Author:** ![ianic](https://ziggit.dev/user_avatar/ziggit.dev/ianic/32/2844_2.png) [@ianic](https://ziggit.dev/u/ianic)\
**Post date:** [June 5, 2026, 7:23am UTC](https://ziggit.dev/t/tls-client-and-out-of-order-certificate-chains/15926/2 "2026-06-05T07:23:34Z")

</div>

I think that you are experiencing same problem as this one: [https://codeberg.org/ziglang/zig/issues/30853](https://codeberg.org/ziglang/zig/issues/30853)  
There is PR here: [skip certificate which is not part of the chain by ianic · Pull Request #25618 · ziglang/zig · GitHub](https://github.com/ziglang/zig/pull/25618)

---

<div class="post-metadata">

**Author:** ![EncryptedSushi](https://ziggit.dev/letter_avatar_proxy/v4/letter/e/9d8465/32.png) [@EncryptedSushi](https://ziggit.dev/u/EncryptedSushi)\
**Post date:** [June 5, 2026, 8:39am UTC](https://ziggit.dev/t/tls-client-and-out-of-order-certificate-chains/15926/3 "2026-06-05T08:39:21Z")

</div>

Oh wow! Thank you so much!