TLS chain validation issue with ISRG Root X1 on nRF7002 using Zephyr

Question

Hi Nordic team, 
 I'm using the nRF5340 + nRF7002 to securely connect to my backend over HTTPS using Wi-Fi and the native TLS support (mbedTLS). 
 
 What works:

I can successfully connect to my server using the Let's Encrypt R11 intermediate certificate , provisioned via tls_credential_add(..., TLS_CREDENTIAL_CA_CERTIFICATE, ...) .

The server sends the full certificate chain (leaf + intermediate), and verification succeeds.

What I want (but can't get to work):

I would like to provision only the ISRG Root X1 certificate (the root CA that signs all Let's Encrypt intermediates) to avoid reflashing devices whenever Let's Encrypt rotates intermediates (e.g., R10 to R11 to R14).

However, when I provision only the root certificate, TLS handshake fails , even though the server includes the full chain and the chain validates correctly in OpenSSL.

My assumption: 
 This suggests that mbedTLS (or Zephyr’s TLS socket layer) is not building the full chain from leaf → intermediate → root, and instead only validates the server certificate if its direct issuer is found in the trusted list. 
 
 What I’ve tried:

Provisioning only ISRG Root X1 → TLS fails

Provisioning ISRG Root X1 + R11 together → TLS succeeds (but device remains pinned to R11)

Verified that the server sends a valid full chain (checked via openssl s_client )

Attempted to find a config like CONFIG_MBEDTLS_CERTIFICATE_CHAIN_PARSING , but it doesn’t seem to exist in current NCS

Verified that TLS_PEER_VERIFY is set to REQUIRED

Using TLS_CREDENTIAL_CA_CERTIFICATE with correct sec_tag in both provisioning and socket setup

My goal: 
 I would like to trust only the ISRG Root X1 and have mbedTLS/Zephyr perform proper full-chain validation during handshake, as any standard TLS client would. 
 
 My questions:

Is there an official or recommended way to enable full chain validation in Zephyr on the nRF7002 Wi-Fi platform?

Does Zephyr’s net_tls or tls_credentials system support full certificate chain building?

Is mbedTLS in Zephyr expected to always require the direct issuer (intermediate) to be provisioned?

Would using raw mbedTLS APIs (not Zephyr sockets) resolve this limitation?

Are there any planned improvements to make the TLS client more robust for real-world deployments?

I’m happy to share logs, configuration, or a minimal test project if it helps. I'm trying to establish a long-term certificate provisioning strategy that doesn't break every time Let's Encrypt rotates intermediates. 
 Best regards