Make AiaCompletionHasLimits handle Windows variance

[bartonjs]

Fixes #130947 (theoretically)

I've run this on Windows 11 25H2 26200.8893 both with a registry override to force 3 (by setting the limit to 4) and in the default behavior (which wincrypt.h says is 3, but black box says is 2).

This should definitely eliminate failures from getting 5 on the first answer. But, along the fix development path it appears that Windows is squirrelling away the previous AIA fetches, and so RetryHelper might take a problem and amplify it. (Since I don't see the certs ending up in persisted stores, I'm going to guess they don't count AIA fetches if they're in memory in the Windows version of the AIA fetch cache)

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates the AiaCompletionHasLimits revocation test to tolerate observed Windows differences in how many AIA certificates can be materialized per X509Chain.Build call (2 vs 3), reducing test flakiness across Windows builds.

Changes:

• Increase the generated intermediate CA chain length used by AiaCompletionHasLimits (from 6 → 8).
• Add branching logic to accept either 4 or 5 chain elements after the first build, and adjust subsequent expected counts and extra-store cloning accordingly.
• Update final chain expectations to reflect the longer chain (ending at 10 elements).

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/libraries/System.Security.Cryptography/tests/X509Certificates/RevocationTests/AiaTests.cs:336

• RetryHelper.Execute retries on any exception by default, including xUnit assertion failures. For this test, re-running the chain-building sequence on assertion failures can change the observed counts (AIA/cache effects) and produce harder-to-diagnose AggregateException output. Consider retrying only on non-assertion failures by supplying retryWhen.

                    }
                });

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/libraries/System.Security.Cryptography/tests/X509Certificates/RevocationTests/AiaTests.cs:339

• RetryHelper.Execute retries on any exception by default (including xUnit assertion failures). For this test, a failing assertion can be a stable logic/behavior mismatch and rerunning can also perturb the observed behavior due to chain/AIA caching side effects. Consider restricting retries to non-assertion failures (or dropping RetryHelper entirely once the test is isolated).

                        }
                    }
                });

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/libraries/System.Security.Cryptography/tests/X509Certificates/RevocationTests/AiaTests.cs:268

• These comments are a bit hard to parse (and have minor grammar issues). Since the test now explicitly tolerates multiple Windows behaviors, it would help to state directly that the first Build is expected to produce 4 (limit=2) or 5 (limit=3) elements, and that this branch handles both.

                                    // Current Windows only allows 2, by black box testing, but 3 does seem to happen
                                    // on some builds.  So, variant test for it being over-sized