Triage for dotnet/runtime#116294 by hiddenshadow21 - Exporting to pfx causes certificate to be unusable

[MihuBot]

Triage for dotnet/runtime#116294.
Last updated: 2025-06-04_07-24-33

Exporting to pfx causes certificate to be unusable by hiddenshadow21
[Tool] Searching for X509Certificate2 Export Pfx unusable, certificate unusable after export X509ContentType.Pfx, HttpClient Local Security Authority cannot be contacted, X509Certificate2 Export HttpClient AuthenticationException, X509Certificate2 Exported certificate unusable (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=False, CreatedAfter=N/A)
[Tool] Found 45 issues, 25 comments, 45 returned results (10260 ms)

Here are related issues and discussions from the dotnet/runtime repository that are relevant to issue #116294 ("Exporting to pfx causes certificate to be unusable"):

---

Highly Relevant Issues

Issue #71064 (June 2022) - "creating mTLS connection in win2019 server returns 'The Local Security Authority cannot be contacted' error"

• Summary: User encountered the same Win32Exception (0x80090304): The Local Security Authority cannot be contacted when using an X509Certificate2 with HttpClient. The discussion points to how the certificate is loaded and the provider selected. A key insight is that on Windows, TLS does not work with ephemeral keys, and using X509KeyStorageFlags.PersistKeySet may help. The issue was resolved by running the application as administrator, indicating permissions can also play a role.
• Key Comment: "This comes from the OS afaik and it is related to how the certificate is loaded and what provider is selected. Can you try to load it with X509KeyStorageFlags.PersistKeySet? In general, on Windows TLS does not work with ephemeral keys." (wfurt)
• Resolution: Running as administrator resolved the issue, suggesting permissions on the private key are critical.

Issue #36899 (May 2020) - "Cannot export certificate data even with X509KeyStorageFlags.Exportable"

• Summary: Discusses issues with exporting and re-importing certificates, particularly around the exportability of the private key. The discussion reveals that Windows may mark keys as Exportable but not PlaintextExportable, which can cause issues when trying to use the key after export/import cycles.
• Key Comment: "When Windows exports a PFX, it includes CSP key ID. So when you re-import the certificate, it gets that key handle... your RSA key in CNG is marked as Exportable but not PlaintextExportable."
• Workaround: Export the key encrypted, then import it again with the correct export policy to allow plaintext export.

Issue #36273 (May 2020) - "Issue when accessing the private key from a certificate after it has been exported"

• Summary: After calling Export(PFX) on a certificate, subsequent attempts to access the private key can fail due to how ephemeral and persisted key properties are handled. This can result in the certificate being unusable for operations like TLS.
• Key Insight: The export operation can change the state of the key in memory, leading to failures when the certificate is used again.

Issue #27460 (September 2018) - "Exporting a X509Certificate2 produces a certificate not usable by IIS centralized certificate store"

• Summary: Exporting a certificate using .NET's PKCS12 export can result in a PFX that is not usable by some Windows components (like IIS CCS) until it is re-exported via MMC or PowerShell. The discussion suggests that the export process in .NET may not always produce a PFX with the expected properties for all consumers.
• Key Comment: "The Export-Method of X509Cert2... does not have any switches... allowing me to use these flags." (glatzert)

---

Other Related Issues

Issue #109881 (November 2024) - ".Net 9 - X509CertificateLoader.LoadPkcs12 - private key throws error on certificate load"

• Summary: In .NET 9, loading a PFX results in "Keyset does not exist" errors, even though the same PFX works in .NET 8. The private key is not accessible after loading, which is similar to the unusable state described in #116294.
• Key Comment: "The issue is related with the privatekey, something changed from .net8 to .net9, because even the old method running on .net 9 invalidate the private key on certificate load."

Issue #98691 (February 2024) - "HttpClient.GetAsync(...) throws Win32Exception when request sent first to https://FQDN and then to https://FQDN:8000"

• Summary: Reports the same Win32Exception (0x80090304): The Local Security Authority cannot be contacted, but in a different context (order of requests). The workaround is to use separate HttpClient instances.

Issue #77590 (October 2022) - "Cannot export certificate data even with X509KeyStorageFlags.Exportable"

• Summary: Similar to #36899, this issue discusses the inability to export private key parameters after importing a PFX, due to export policy flags not being set correctly.

Issue #87571 (June 2023) - "TLS handshake fails on HttpClient, but works on WebRequest"

• Summary: HttpClient fails to use a client certificate, but WebRequest works. The discussion includes attempts to re-export and re-import the certificate, and issues with key permissions and Enhanced Key Usage (EKU).

Issue #23631 (September 2017) - "HttpClient is not able to send Client certificate unless the cert is in Windows Cert Store"

• Summary: HttpClient may not use a certificate unless it is present in the Windows Certificate Store, which can be related to how the certificate and its private key are loaded and stored.

---

Key Takeaways and Patterns

• Export/Import Cycle: Exporting a certificate to PFX and then using the same X509Certificate2 instance can result in the private key becoming unusable, especially for operations like TLS. This is often due to how Windows handles key handles and export policies.
• Workaround: The most reliable workaround is to re-import the certificate from the exported PFX bytes, as described in your issue and confirmed in several related issues.
• Key Storage Flags: Using appropriate X509KeyStorageFlags (such as PersistKeySet or MachineKeySet) and ensuring the process has sufficient permissions (possibly running as administrator) can be necessary.
• Platform Differences: There are differences in how .NET and Windows handle private keys, especially with ephemeral vs. persisted keys, and with export policies (Exportable vs. PlaintextExportable).
• Known .NET Limitation: This is a known limitation/quirk in the .NET X509Certificate2 API on Windows, and is not unique to your scenario.

---

Summary Table

Issue #	Date	Title/Link	Key Insight/Resolution
#71064	Jun 2022	mTLS connection returns LSA error	Certificate loading/provider selection and permissions are critical; ephemeral keys don't work for TLS.
#36899	May 2020	Cannot export certificate data even with Exportable	Exported keys may not be plaintext exportable; workaround is to re-import with correct policy.
#36273	May 2020	Private key access fails after export	Exporting can change key state, making it unusable for further operations.
#27460	Sep 2018	Exported cert not usable by IIS CCS	.NET's PKCS12 export may not produce a PFX with expected properties for all consumers.
#109881	Nov 2024	.Net 9 PFX load error	.NET 9 changes in key loading can make private keys inaccessible.
#77590	Oct 2022	Cannot export certificate data	Export policy flags are critical for private key usability after import.
#87571	Jun 2023	TLS handshake fails on HttpClient	Key permissions and EKU can prevent certificate use in HttpClient.
#23631	Sep 2017	HttpClient needs cert in store	HttpClient may require certs to be in the Windows Cert Store.

---

Conclusion

Your issue is a known behavior in .NET/Windows certificate handling. The workaround you listed (re-importing the certificate after export) is the standard solution, and is confirmed in multiple related issues. The root cause is a combination of how Windows manages private key handles and export policies, and how .NET interacts with them. There is no evidence of a recent regression, but changes in .NET 9+ may have made this more prominent.

If you need more technical details or want to track progress on improvements, issues #36899 and #77590 have in-depth discussions and workarounds.

Let me know if you need a deeper dive into any specific issue or workaround!