Description
When loading a PKCS#12/PFX on Windows without specifying either the PersistKeySet or EphemeralKeySet storage options, .NET determines when a private key is no longer needed and should be erased. In prior versions of .NET (and in .NET Framework) two different sets of logic were utilized. In .NET 9 this has been simplified to one.
Version
.NET 9 Preview 7
Previous behavior
When loading a certificate (and its private key) from a PKCS#12/PFX with new X509Certificate2(pfx, password, flags), the loaded certificate represented the lifetime of the private key. When this certificate object was disposed (or finalized if it was garbage collected without being disposed) the associated private key would be deleted. No shared ownership or transfer of ownership occurred.
When loading a certificate (and its private key) from a PKCS#12/PFX with X509Certificate2Collection.Import(pfx, password, flags) each loaded certificate that had a private key would track the lifetime, as with the single certificate load. But, in addition, a marker was placed on the native copy of the certificate to indicate that any copies should also track the private key lifetime. If a second X509Certificate2 object was created in terms of the same underlying PCERT_CONTEXT value, then whichever copy was disposed (or finalized) first would erase the private key out from under the other.
New behavior
Starting in .NET 9, the lifetime is always associated with the X509Certificate2 instance that was directly produced from the PKCS#12/PFX load.
In previous versions, this code will fail (either with a CryptographicException, or a NullReferenceException) because the private key was deleted. In .NET 9 it will succeed.
X509Certificate2Collection coll = new X509Certificate2Collection(pfx, password, X509KeyStorageFlags.DefaultKeySet);
X509Certificate2Collection coll2 = coll.Find(X509FindType.FindBySubjectName, "", false);
coll2 = null;
GC.Collect();
GC.WaitForPendingFinalizers();
using (RSA key = coll[0].GetRSAPrivateKey())
{
key.SignData(pfx, HashAlgorithmName.SHA256, RSASignaturePadding.Pss);
}
Type of breaking change
Reason for change
Most workloads loading a PKCS#12/PFX use the single certificate load, and understand the lifetime mechanics associated with that method. The mechanics associated with the collection load were often surprising, and could lead to premature key erasure.
Recommended action
Users who understood the collection-load lifetime management and were depending on calling Dispose on a clone to cause key erasure should ensure that they are also (or instead) calling Dispose on the original loaded object.
Feature area
Cryptography
Affected APIs
- System.Security.Cryptography.X509Certificate2Collection.Import (all overloads)
Associated WorkItem - 320278
Description
When loading a PKCS#12/PFX on Windows without specifying either the
PersistKeySetorEphemeralKeySetstorage options, .NET determines when a private key is no longer needed and should be erased. In prior versions of .NET (and in .NET Framework) two different sets of logic were utilized. In .NET 9 this has been simplified to one.Version
.NET 9 Preview 7
Previous behavior
When loading a certificate (and its private key) from a PKCS#12/PFX with
new X509Certificate2(pfx, password, flags), the loaded certificate represented the lifetime of the private key. When this certificate object was disposed (or finalized if it was garbage collected without being disposed) the associated private key would be deleted. No shared ownership or transfer of ownership occurred.When loading a certificate (and its private key) from a PKCS#12/PFX with
X509Certificate2Collection.Import(pfx, password, flags)each loaded certificate that had a private key would track the lifetime, as with the single certificate load. But, in addition, a marker was placed on the native copy of the certificate to indicate that any copies should also track the private key lifetime. If a secondX509Certificate2object was created in terms of the same underlyingPCERT_CONTEXTvalue, then whichever copy was disposed (or finalized) first would erase the private key out from under the other.New behavior
Starting in .NET 9, the lifetime is always associated with the X509Certificate2 instance that was directly produced from the PKCS#12/PFX load.
In previous versions, this code will fail (either with a CryptographicException, or a NullReferenceException) because the private key was deleted. In .NET 9 it will succeed.
Type of breaking change
Reason for change
Most workloads loading a PKCS#12/PFX use the single certificate load, and understand the lifetime mechanics associated with that method. The mechanics associated with the collection load were often surprising, and could lead to premature key erasure.
Recommended action
Users who understood the collection-load lifetime management and were depending on calling
Disposeon a clone to cause key erasure should ensure that they are also (or instead) calling Dispose on the original loaded object.Feature area
Cryptography
Affected APIs
Associated WorkItem - 320278