Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Is RSACng from X509Certificate2.GetRSAPrivateKey thread-safe? #128681

Answered by bartonjs
acu-kevinb asked this question in Q&A
Discussion options

I have an asp.net core web application that needs to sign a jwt using the private key associated with a certificate loaded from the windows certificate store, using code similar to this:

RSA privateKey;
X509Certificate2 cert;
using (var store = new X509Store(StoreName.My, StoreLocation.CurrentUser))
 {
 store.Open(OpenFlags.ReadOnly);
 //Locate the required 'Current' certificate using the distinguished name, and create
 // the snapshot wrapper for it
 var certs = store.Certificates.Find(X509FindType.FindBySubjectName, configuration.Current.SubjectName, validOnly: validCertificatesOnly);
 cert = certs[0];
}
privateKey = cert.GetRSAPrivateKey();

Is it safe to use the same RSA instance for signing operations on multiple threads? The call to GetRSAPrivateKey seems to be fairly expensive in terms of time (multiple milliseconds) so I'd rather not take the hit on every request, but I can't find any documentation on whether or not it's thread safe. I've also seen the RSA returned by GetRSAPrivateKey suddenly become unusable after a period of time for no apparent reason (throwing a CryptographicException with a message of 'File not found' for an instance that previously worked fine.

You must be logged in to vote

The instance members are not documented as thread-safe.

The full implementation of the returned object (which is only RSACng on Windows) is an OS component which does not document itself as thread-safe, so the only way we could document the class as thread-safe is if we instilled our own locking, which we don't do.

My personal belief, though not a recommendation you should depend on, is that the native implementations are thread-safe (assuming you don't parallelize the operation with Dispose), so it's "probably fine", but we (.NET) do not guarantee it, and wouldn't make any changes to our code in response to a data-corruption thread-safety bug report.

Replies: 1 comment

Comment options

The instance members are not documented as thread-safe.

The full implementation of the returned object (which is only RSACng on Windows) is an OS component which does not document itself as thread-safe, so the only way we could document the class as thread-safe is if we instilled our own locking, which we don't do.

My personal belief, though not a recommendation you should depend on, is that the native implementations are thread-safe (assuming you don't parallelize the operation with Dispose), so it's "probably fine", but we (.NET) do not guarantee it, and wouldn't make any changes to our code in response to a data-corruption thread-safety bug report.

You must be logged in to vote
0 replies
Answer selected by bartonjs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet

AltStyle によって変換されたページ (->オリジナル) /