Arduino TLS certificate validation fails across Wi-Fi and Ethernet stacks despite successful DNS resolution

On Arduino boards using WiFiNINA, WiFiS3, or Ethernet with Arduino_SSLClient, DNS resolution can succeed while the TLS handshake rejects the server certificate. The supported path separates name resolution from secure client initialization, leaving the exact validation behavior dependent on the installed board package and library version.

The unresolved decision is whether an unconfigured trust anchor should cause the client to fail closed or skip verification. Some wrappers require a root CA or pinned certificate before the handshake proceeds, while others accept an explicit insecure mode. Additionally, connecting by resolved IP rather than hostname breaks hostname verification, and boards without a real-time clock may reject otherwise valid certificates if the system time falls outside the X.509 validity window.

Which library and firmware combinations define the default certificate validation behavior when no trust anchor is supplied, and does the handshake fail closed or proceed without verification? How can a sketch reliably separate a hostname verification failure from a clock-driven X.509 validity rejection when connecting by hostname versus by resolved IP? What version-specific checks are required to confirm whether a coprocessor-based Wi-Fi module performs TLS validation in firmware, independent of sketch-level certificate configuration?