Issue when attempting to use a key from keychain for signing data

After either

  • latest upgrade to Monterey 12.6 or
  • having installed the azure command line tools from brew

I am having issues with my .NET application when it attempts to use the keychain for signing data:

lientCertificateCredential authentication failed: The operation couldn’t be completed. (OSStatus error -25293 - CSSM Exception: -2147416032 CSSMERR_CSP_OPERATION_AUTH_DENIED)
 ---> Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (OSStatus error -25293 - CSSM Exception: -2147416032 CSSMERR_CSP_OPERATION_AUTH_DENIED)
   at Interop.AppleCrypto.NativeCreateSignature(SafeSecKeyRefHandle privateKey, ReadOnlySpan`1 dataHash, PAL_HashAlgorithm hashAlgorithm, PAL_SignatureAlgorithm signatureAlgorithm)
   at Interop.AppleCrypto.CreateSignature(SafeSecKeyRefHandle privateKey, ReadOnlySpan`1 dataHash, PAL_HashAlgorithm hashAlgorithm, PAL_SignatureAlgorithm signatureAlgorithm)
   at System.Security.Cryptography.RSAImplementation.RSASecurityTransforms.SignHash(Byte[] hash, HashAlgorithmName hashAlgorithm, RSASignaturePadding padding)
   at System.Security.Cryptography.RSA.SignData(Byte[] data, Int32 offset, Int32 count, HashAlgorithmName hashAlgorithm, RSASignaturePadding padding)

I post this here because the core of the exception appears to be an exceptional access pattern that results in the following failure code:

OSStatus error -25293 - CSSM Exception: -2147416032 CSSMERR_CSP_OPERATION_AUTH_DENIED

Unfortunately I haven't found much about this on the internet. I created an issue with the relevant dotnet repo,, but feel that it may make sense to follow this up here.

My current (very tedious)workaround is to restart the machine - a re-login doesn't help, but a reboot makes this work as it previously did after which, somehow, the exception resurfaces again after some time (as if something expires?)

Post not yet marked as solved Up vote post of FrankQ Down vote post of FrankQ
1.4k views
Posted by
FrankQ
Reply

  • Saddened to report that after the dotnet update the problem had lost its teeth, now it has come back. I need to reboot again.

    —
    FrankQ
Add a Comment

Replies

Error -25293 is errSecAuthFailed, which is described as The user name or passphrase you entered is not correct. As to what’s triggering this, it’s hard to say. I usually see this when there’s a problem with the keychain itself. To sign data you need to use a private key and that key is stored in the keychain. If the system fails to unlock the keychain for some reason, you may well see this error.

In what context are you running this code? From the Terminal app itself? When logged in via SSH? Or perhaps in some sort of automation context, like a launchd daemon?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Post not yet marked as solved Up vote reply of eskimo Down vote reply of eskimo

  • The code is running in the context of a process running under the "dotnet" executable. See also my answer.

    —
    FrankQ

  • "A problem with the keychain itself" - are there any procedures to mitigate that?

    —
    FrankQ
Add a Comment

How the things have proceeded in the past 2 days:

  • The code was running under dotnet, so I upgraded dotnet to its latest SDK (according to some other user, a reinstall would also help)
  • after that, when the app was trying to access the keychain it would ask me (the user) for allowance by requesting my password.

What can be seen is that the situation has improved considerably. I am not saying that it is completely fixed as I still that particular exception on some occasions, but it is not comparable to previously. So, in some ways this is resolved, but I'm left with the feeling that I didn't really resolve the core issue, if you know what I mean.

Posted by
FrankQ
Up vote reply of FrankQ Down vote reply of FrankQ
Add a Comment

when the app was trying to access the keychain it would ask me (the user) for allowance by requesting my password.

Does that alert have an Always Allow button? If so, does clicking prevent the alert coming up again?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • It asked me to "Allow", "Always Allow" - it seemed to work. Can I maybe revoke that somewhere and then save myself the reboot cycle?

    —
    FrankQ
Add a Comment

Hello I just wanted to notify you that I have what seems to be the exact same problem as FrankQ.

After recently updating my macOS to Monterey 12.6 I started to get this error when trying to sign data. Previously it was not a problem whatsoever. It works the first time when I restart my mac but after that it stops working completely. I have updated to the latest dotnet SDK and runtime versions as recommended by some but without any success. The code runs in a dotnet console application.

The error message looks just like FrankQs so it's redundant to post it.

Posted by
martinstenberg
Post not yet marked as solved Up vote reply of martinstenberg Down vote reply of martinstenberg
Add a Comment

The fact that both you and FrankQ are using the same third-party tooling seems significant. I recommend that you escalate this via the support channel for that tooling.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Thank you for the reply and yes that's sounds like a good idea.

However, I have at least found a temporary solution for my setup and I will share it in case it might provide some value for future forum visitors.

So I updated to the lastest dotnet SDK and i use Rider as my IDE. What I realized is that I could get around the error if I did a clean build of the solution every time I altered the code in the slightest way. It's a bit tedious but at least it got me back to be able to work.

That's all thanks.

Posted by
martinstenberg
Post not yet marked as solved Up vote reply of martinstenberg Down vote reply of martinstenberg

  • Thanks for posting, can confirm that this helps and is certainly the quicker workaround than rebooting. Will try to see if I can move the issue I created with the .NET people to a more appropriate repository.

    Even so, the underlying cause is the OS upgrade, since .NET executables didn't change at the time, even though it only seems to appear with .NET. Will be interesting to see if any other access patterns appear through a different set of binaries

    —
    FrankQ
Add a Comment

Just an information that from my point of view this problem has gone away after the OS upgrade to Ventura.

Posted by
FrankQ
Up vote reply of FrankQ Down vote reply of FrankQ
Add a Comment