-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Permit unencrypted key exports from CNG #109119
Conversation
CNG, by default, loads PKCS#12 certificate private keys as "AllowExport", not "AllowsPlaintextExport". When users attempt to export the private key from a loaded PKCS#12, they will receive an error that the operation is not permitted because they are expected to perform an encrypted export. This is counter-intuitive to some people, as the general expectation is that they can export private keys they just loaded. Starting in .NET 9, we are loading more PKCS#12 private keys in CNG instead of the legacy CSP, meaning users will hit this problem more. This is also a regression from .NET 8. The default provider changed, meaning keys that were once exportable no longer are. This pull request makes a change similar to what we do for macOS. If a user asks for an unencrypted export of the private key, and the key does not permit that, we will ask CNG for an encrypted export of the private key and decrypt it for them. This makes the unencrypted exports "just work", as they do on other platforms.
@@ -105,18 +113,38 @@ public override ECParameters ExportParameters(bool includePrivateParameters) | |||
{ | |||
ECParameters ecparams = default; | |||
|
|||
const string TemporaryExportPassword = "DotnetExportPhrase"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to have a problem with CredScan after we merge this? We should try pushing this change to the internal mirror and make sure it doesn't trip CredScan before we merge this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was back-channeling with @GrabYourPitchforks on this - we (well, Levi) is going to run it - especially since this might be a thing we try to fix for 9.0.
src/libraries/Common/src/System/Security/Cryptography/ECDsaCng.ImportExport.cs
Outdated
Show resolved
Hide resolved
src/libraries/Common/src/System/Security/Cryptography/ECDsaCng.ImportExport.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Security.Cryptography/tests/X509Certificates/ExportTests.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/ECDsaCng.cs
Outdated
Show resolved
Hide resolved
/ba-g Windows-only change, won't affect wasm. |
@GrabYourPitchforks ran 3811dde through credscan and reported it came back "clean", so, merging. |
/backport to release/9.0 |
Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/11470191357 |
CNG, by default, loads PKCS#12 certificate private keys as "AllowExport", not "AllowsPlaintextExport". When users attempt to export the private key from a loaded PKCS#12, they will receive an error that the operation is not permitted because they are expected to perform an encrypted export.
This is counter-intuitive to some people, as the general expectation is that they can export private keys they just loaded. Starting in .NET 9, we are loading more PKCS#12 private keys in CNG instead of the legacy CSP, meaning users will hit this problem more. This is also a regression from .NET 8. The default provider changed, meaning keys that were once exportable no longer are.
This pull request makes a change similar to what we do for macOS. If a user asks for an unencrypted export of the private key, and the key does not permit that, we will ask CNG for an encrypted export of the private key and decrypt it for them. This makes the unencrypted exports "just work", as they do on other platforms.
Fixes #109059