SqlClient CryptographicException is back on High Sierra 10.13.4

[winzig]

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?

[danmoseley]

@bartonjs

[bartonjs]

Confirmed. Sigh. Looking into why.

[bartonjs]

It looks like they've made some fundamental changes to X509Chain processing in 10.13.4.

[bartonjs]

Okay, maybe less fundamental than I thought. Apparently my test rig was in a corrupted state.

[danmoseley]

@MattGal how do we get or test boxes updated to 10.13.4? In general if they updated automatically that would be a good thing.

[winzig]

@bartonjs Thanks for fixing this so rapidly. What would be the best way for me to go about getting this on my system until the next release of core? Can I just clone and build this repo and drop it somewhere into my system?

Update: Just found this page which describes how to dog food the latest corefx, so I’ll try that.

[bartonjs]

@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 😄)

[winzig]

Crud, appreciate the help, but looks like I'm unable to build for some reason. I'll try to figure out what I'm doing wrong, but barring that, I'm assuming I'm waiting for an official release. Do you think it will make it in for 2.0.7? And is there an ETA on that release?

[MattGal]

@danmosemsft I'm not sure about how to configured automated updates for OSX machines in a way that doesn't accidentally break things like OpenSSL building but I filed https://github.com/dotnet/core-eng/issues/3091 to track updating the 10.13 agents, please use this to track the update.

[bartonjs]

This was merged in for 2.0.7 with dotnet/corefx#28675. @leecow do we have a published target release date?

[leecow]

Targeting 4/17 pending validation.

[winzig]

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

[bartonjs]

(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.

[bartonjs]

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.