fix certificate ctx on windows and macOS

[wfurt]

This is follow up on #38364
After some search, it seems like there is really no way how to give certificate chain to Schannel.
So instead, we try to add certificates to intermediate CA store. So when Schannel/CAPI needs them, they can get them without network IO.

I updated existing tests to fail if peer does not send full chain (-1)

Fixes #35844

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[bartonjs]

Do you really want to add all intermediates? Or just the ones that the OS ends up using in a chain?

e.g. Add all of intermediates to chain.ChainPolicy.ExtraStore and build again; then add anything relevant (preferably using a diffing algorithm so that it doesn't potentially reset custom store property overrides).

Using a second chain object (you could copy the policy object over) would make the diff easy, just walk each position and compare that cert.RawData values SequenceEqual.

Ideally, after each add you'd rerun the offline/no-extra build to see if you can avoid invalidating existing higher-scoped entries.

[bartonjs]

(While a diffing algorithm and a while loop sound potentially expensive, most chains are three items long, so there aren't many iterations)

[wfurt]

I was considering to add some more complicated logic. But as you said if most chains are 3 long, it does not matter that much. I assumed that adding intermediate once to store is cheap enough so I decided not to care.

[bartonjs]

There's one thing to check:

• Add an intermediate to the store
• Open the intermediates store in MMC (e.g. add snap-in, certificates, local computer, then pick Intermediate Certificate Authorities / Certificates in the nav tree)
• Pick that same certificate, right click, Properties
• Pick "Enable only the following purposes"
• Toggle some checkmarks
• Use the API as you have it
• Right click on the Certificates entry in the nav bar and refresh
• Reopen the properties dialog.

If the property resets, we need to do complex stuff here. If it doesn't, we're good. (I think we do "merge properties", which should (generally) be safe, but it's good to test that before we run the risk of altering machine state)

[wfurt]

that assumes same CA set between runs, right? (right now we generate unique set for each test run and I had situation where it would build up before adding cleanup to the tests)

[bartonjs]

It assumes that we ever get something in the intermediates collection that's already in the store. E.g. if what we need is a 4 hop chain:

• root -> intermed1 -> intermed2 -> end-entity

And intermed1 is already in the store, but intermed2 wasn't; we'll end up calling store.Add(intermed1) which will cause the merge logic to apply. Since it changes system persisted state we need to be careful to ensure it's only additive, not destructive.

[wfurt]

here is what I did:

• modified the test helper to save/load certificates from pfx and I disabled the cleanup
• I run the test and I check both CA.
• I removed root CA, run tests and verified that it triggers the adding logic
• I removed root again and I modified properties on intermediate and I also added friendly name
• run test again. Root CA was added again and intermediate preserved with my modifications

so the conclusion is that adding existing certificate is not destructive.

[wfurt]

I made suggested changes and also fix macOS. That needed more structural changes as the flow is different.
This is ready for another review round.

[wfurt]

can you please take another look @bartonjs ?