runtime: SqlClient CryptographicException is back on High Sierra 10.13.4

My issue today seems the same as this: https://github.com/dotnet/corefx/issues/22453

Yesterday (on High Sierra 10.13.3) my .net core 2.0 web project ran fine, connecting to SQL Server.

Last night my machine was updated to 10.13.4, and now this morning when I run the project I get this error:

An unhandled exception was thrown by the application.
System.TypeInitializationException: The type initializer for 'XXX' 
threw an exception. ---> System.Data.SqlClient.SqlException: A connection 
was successfully established with the server, but then an error occurred 
during the pre-login handshake. (provider: SSL Provider, error: 31 - 
Encryption(ssl/tls) handshake failed) ---> 
System.Security.Cryptography.CryptographicException: 
Error occurred during a cryptographic operation.

Anyone else on 10.13.4 able to successfully connect to SQL Server this morning?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 5
  • Comments: 25 (12 by maintainers)

Most upvoted comments

@winzig If you want to peel back the tamper-evident seal and void the warranty you could do something like

  • Pull down the repository
  • ./build-native.sh -release
  • locate System.Security.Cryptography.Native.Apple.dylib
  • For each of those in a 2.x release, cp bin/OSX.x64.Release/native/System.Security.Cryptography.Native.Apple.dylib <dest>

Slightly safer would be to save the existing one before overwriting it, using my favorite bash syntax (or a less fun syntax, I guess…) cp <dest>{,.orig} (where <dest> is something you replace, and {,.orig} isn’t 😄)

https://github.com/dotnet/core/issues/1456 says that 2.0.7 is out now. The build labels say that the 10.13.4 changes were included, so upgrading to the 2.0.7 runtime should resolve the problems.

Since the fixes for 2.0 and 2.1 are both already in, and things are just waiting on releases to happen, I’m going to close this issue. Closed != locked, so feel free to add information if things like grabbing a latest daily 2.1 (or manually patching 2.0) don’t fix the issue for you.

(From a comment on the rel/2.0 PR)

With last version 2.1.300-preview3-008437 on Mac OSX High Sierra 10.13.4 (17E199) still happens.

$ tar -tzvf dotnet-sdk-latest-osx-x64.tar.gz  | grep "Apple.dylib\|csc.dll"
-rwxr-xr-x buildagent/staff    65724 2018-03-14 09:06 ./shared/Microsoft.NETCore.App/2.1.0-preview2-26314-02/System.Security.Cryptography.Native.Apple.dylib
-rw-r--r-- buildagent/staff   101376 2018-04-03 11:38 ./sdk/2.1.300-preview3-008437/Roslyn/bincore/csc.dll

So SDK 2.1.300-preview3-008437 contains runtime 2.1.0-preview2-26314-02.

The latest runtime from https://github.com/dotnet/core-setup#daily-builds, on the other hand:

$ tar -tzvf dotnet-runtime-latest-osx-x64.tar.gz | grep Apple.dylib
-rwxr-xr-x buildagent/staff    65724 2018-04-03 21:06 ./shared/Microsoft.NETCore.App/2.1.0-preview3-26404-01/System.Security.Cryptography.Native.Apple.dylib

Is version 2.1.0-preview3-26404-01. The fix went into master on 31 March, so any 2.1.0-preview2-2640* build should have it.

So the SDK is currently lagging by a couple of weeks, it seems. But you can grab the runtime package and use it with an existing SDK.

Thanks @bartonjs, now that the build issue was resolved, I was able to implement your steps and get back up and running!