[release/3.1] Data loss - Don't delete private keys detected from SerializedCert imports

[bartonjs]

Port of dotnet/runtime@2bcf713

[bartonjs]

Description

Importing a certificate from a SerializedCert import can import the identifier for a private key, but doesn't actually import the key itself. This violates an assumption in the single-cert import path, and results in a massive surprise when the key is erased on Dispose/Finalize.

Customer Impact

If a customer has a certificate with a private key, exports it as SerializedCert, and then re-imports it later on the same system (or a system with a compatible persisted import) then the X509Certificate2 object will erase the persisted private key from disk when the object is freed. We believe usage of SerializedCert is very low, but the impact is potentially very high.

Regression

Regression from .NET Framework

Testing

Added a new test to cover the scenario for both single-cert import (affected) and collection import (not affected).

Risk

Low. There are a large number of unit tests for other, existing, behavior; and this change makes the single-cert import look more like it did in .NET Framework (and does in collection import) with regard to registering for key cleanup.

[danmoseley]

original pr dotnet/runtime#33603
issue dotnet/runtime#33543

[wtgodbe]

1 test failure in System.Security.Cryptography.X509Certificates.Tests - is it the same one being fixed in #42875?