unable to get local issuer certificate during partial chain verification

Direct Answer

OpenSSL 3.x does not provide a deterministic, documented algorithm for selecting a trust anchor when multiple valid partial chains exist to different anchors in the same X509_STORE. The legacy provider does not change trust-anchor discovery for X509_V_FLAG_PARTIAL_CHAIN; it supplies cryptographic algorithm implementations, while chain building and store lookup remain in the core X509 verification engine.

Established behavior versus uncertainty

Established behavior: X509_V_FLAG_PARTIAL_CHAIN causes verification to succeed when any intermediate CA in the presented chain is found in the trust store, without requiring a self-signed root. Trust anchors loaded with SSL_CTX_load_verify_locations() are stored in the X509_STORE and are available to the verification engine regardless of which provider is active.

Uncertain or implementation-dependent: The exact order in which candidate anchors are tried when several partial chains are valid is not specified by the public API. OpenSSL's internal chain builder performs a depth-first search over the supplied certificates and store lookups, but the iteration order over store entries can depend on internal hash-table layout, insertion order, or build-specific details. This means two builds, or even two runs with the same inputs, may select different anchors. Treat any assumption about a single "correct" anchor as unsafe.

Legacy provider interaction

The legacy provider in OpenSSL 3.x exists to supply deprecated algorithms (for example, older digests or ciphers). It does not own the X509_STORE or the chain-building loop. Activating or deactivating the legacy provider therefore has no documented effect on which trust anchors are discovered when X509_V_FLAG_PARTIAL_CHAIN is set. If an application observes different verification results after toggling the legacy provider, the likely cause is an algorithm-availability failure during signature checking, not a change in anchor selection logic.

Practical guidance

1. Do not rely on OpenSSL to pick a specific anchor among several valid partial chains. If your policy requires a particular intermediate to act as the anchor, remove the others from the X509_STORE or verify the chain explicitly.
2. To confirm behavior on your platform, build a small test harness that loads two overlapping anchors and the same leaf/intermediate chain, then inspect the verified chain returned by the verification context.
3. Review the chain-building source in crypto/x509/x509_vfy.c for your exact OpenSSL 3.x version if you need to understand the current traversal order. Because this is internal implementation detail, do not treat it as a stable contract.

If your deployment depends on reproducible anchor selection across restarts or hosts, the only safe design is to constrain the trust store so that exactly one valid partial chain exists, rather than depending on OpenSSL's internal iteration order.