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)
@winzig If you want to peel back the tamper-evident seal and void the warranty you could do something like
./build-native.sh -releaselocate System.Security.Cryptography.Native.Apple.dylibcp 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)
So SDK
2.1.300-preview3-008437contains runtime2.1.0-preview2-26314-02.The latest runtime from https://github.com/dotnet/core-setup#daily-builds, on the other hand:
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!