Certificate Chain Validation using NetX Secure STM32U585 - local vs. server-supplied certificate

[PJose.4]

I am using Azure RTOS NetX Secure / NetX Duo on an STM32U585 for TLS client communication and would like clarification regarding certificate chain verification.

I have the following scenario:

• The TLS server sends a valid server certificate.
• The server also sends an expired intermediate CA certificate as part of the certificate chain.
• The client has a valid copy of the same intermediate CA certificate stored locally and added using nx_secure_tls_local_certificate_add().
• The trusted root CA is also configured in the TLS trusted certificate store.

During debugging, I observed the following:

1. _nx_secure_tls_process_remote_certificate() correctly parses the certificates received from the server. Wireshark also confirms that the server is sending the expired intermediate certificate.
2. _nx_secure_x509_remote_endpoint_certificate_get() correctly identifies the remote endpoint certificate.
3. During _nx_secure_x509_certificate_chain_verify(), NetX calls:
   _nx_secure_x509_store_certificate_find()
   to locate the issuer certificate.
4. In this scenario, the issuer lookup resolves to the locally stored valid intermediate CA certificate, rather than the expired intermediate certificate received from the server.
5. As a result, the expiration check is performed against the valid local certificate, and the TLS connection succeeds even though the server supplied an expired intermediate certificate.
6. When I remove the locally stored intermediate certificate from the TLS configuration, NetX uses the expired certificate received from the server and the TLS handshake fails as expected.

My questions are:

• Is this certificate path-building behavior expected and intended in NetX Secure?
• Does _nx_secure_x509_store_certificate_find() intentionally allow a locally configured certificate to be used as an issuer for a remotely received certificate?
• If both a remote and local certificate have the same Subject/Issuer relationship, what is the expected search/selection priority?
• Is there any official NetX Secure documentation that explicitly describes this behavior?
• When an intermediate certificate is supplied by the server, should NetX validate that exact certificate, or is it allowed to construct an alternative certification path using locally available certificates?

I would appreciate any clarification from the NetX Secure/Azure RTOS team or anyone familiar with the certificate verification implementation.

Thanks and Regards
Philip