sdk: Installing and Running on OS X 10.11 SSL Fails to Link Using Brew

Steps to reproduce

Following steps here: https://www.microsoft.com/net/core#macos

brew update
brew install openssl
brew link --force openssl

Expected behavior

System is configured

Actual behavior

$ brew link --force openssl output:

Warning: Refusing to link: openssl
Linking keg-only OpenSSL means you may end up linking against the insecure,
deprecated system version while using the headers from the Homebrew version.
Instead, pass the full include/library paths to your compiler e.g.:
  -I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib

If I try to use the CLI, I get crypto errors: $ dotnet restore output:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'Crypto' threw an exception. ---> System.TypeInitializationException: The type initializer for 'CryptoInitializer' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'System.Security.Cryptography.Native': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
   at Interop.CryptoInitializer.EnsureOpenSslInitialized()
   at Interop.CryptoInitializer..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto.GetRandomBytes(Byte* buf, Int32 num)
   at System.IO.Path.GetCryptoRandomBytes(Byte* bytes, Int32 byteCount)
   at System.IO.Path.GetRandomFileName()
   at Microsoft.DotNet.InternalAbstractions.TemporaryDirectory..ctor()
   at Microsoft.Extensions.EnvironmentAbstractions.DirectoryWrapper.CreateTemporaryDirectory()
   at Microsoft.DotNet.Configurer.NuGetPackagesArchiver..ctor()
   at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(INuGetCacheSentinel nugetCacheSentinel)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)
Abort trap: 6

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.11
 OS Platform: Darwin
 RID:         osx.10.11-x64

$ brew -v output:

Homebrew 0.9.9 (git revision b999e; last commit 2016-07-29)
Homebrew/homebrew-core (git revision a69e; last commit 2016-07-29)

$ brew info openssl output:

openssl: stable 1.0.2h (bottled) [keg-only]
SSL/TLS cryptography library
https://openssl.org/
/usr/local/Cellar/openssl/1.0.2h_1 (1,691 files, 12M)
  Poured from bottle on 2016-07-29 at 18:47:22
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/openssl.rb
==> Dependencies
Build: makedepend ✘
==> Options
--universal
    Build a universal binary
--without-test
    Skip build-time tests (not recommended)
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/openssl/certs

and run
  /usr/local/opt/openssl/bin/c_rehash

This formula is keg-only, which means it was not symlinked into /usr/local.

Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/openssl/lib
    CPPFLAGS: -I/usr/local/opt/openssl/include

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 60
  • Comments: 58 (10 by maintainers)

Commits related to this issue

Most upvoted comments

@carlsoncoder did you set yourself as owner of the /usr/local folder?

sudo chown -R whoami /usr/local

To recap, for workaround this issue you need to:

  1. Remove the openssl version you installed (1.0.2): brew uninstall openssl
  2. Set yourself as owner of the /usr/local folder (the -R is for recursively): sudo chown -R whoami /usr/local
  3. Install version 1.0.1 of openssl: brew install homebrew/versions/openssl101
  4. Perform the linking: brew link --force homebrew/versions/openssl101

I have the same problem about that.

When the documentation gets updated it will be suggesting of manually bringing in the dylib symlinks, but not doing the rest of the work that brew link did. Therefore the recommendation is

ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/

after doing brew install openssl (the 1.0.2 version)

I follow the solution from the link below and issue is resolved. http://stackoverflow.com/questions/38670295/brew-refusing-to-link-openssl

Thanks Jeremy, After having another read of the homebrew issue, it seems the HomeBrew crew are against that option due to the potential to break unknown things globally. I.e. any software that expects the headers it uses to align to the libraries installed in /usr/local/lib will now be in an inconsistent state. That said, my DYLD_LIBRARY_PATH suggestion causes the same problem.

I looked into the other option that was suggested for setting the rpath on the library. I think the following is a better solution that will only effect this specific library.

sudo install_name_tool -add_rpath /usr/local/opt/openssl/lib /usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Security.Cryptography.Native.dylib

In effect, rather than telling the operating system to always use the homebrew version of SSL and potentially causing something to break, we’re telling dotnet how to find the correct library.

Additionally this solution can be easily incorporated into the homebrew cask version of the installation process as it should know where openssl is installed (I believe that this was your contention to this approach).

As an aside, I found it a little odd that the sudo was necessary to fix this up as most things I’ve installed in /usr/local via homebrew are owned by “myuser:admin”. Is there are reason why this is necessary / suggested for the dotnet installation?

I had this same problem when I was trying to install PHP’s mongo extension using PECL pecl install mongo, what I did to fix the issue was to define two environment variables LDFLAGS and CPPFLAGS so PECL could find the correct openssl library.

In my case I run these two commands:

  • export LDFLAGS=-L/usr/local/opt/openssl/lib
  • export CPPFLAGS=-I/usr/local/opt/openssl/include

How did I find this out? brew info openssl

  1. install port: https://guide.macports.org/
  2. install or upgrade openssl package: sudo port install openssl or sudo port upgrade openssl
  3. that’s it, run openssl version to see the result.

The stackoverflow / earlier version of openssl approach will cease working once you update brew (see https://github.com/Homebrew/brew/pull/612). The following workaround worked for me on a hello world project:

export DYLD_LIBRARY_PATH=/usr/local/opt/openssl/lib
dotnet new

See https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html#//apple_ref/doc/uid/TP40001928-SW21 for info on how the library search process works on OS X.

Homebrew maintainer here!

If building dotnet from source, allow the user to set the correct lib path and bake that path into the dylib

Agreed 👍

If installing from the pkg file, use the install_name_tool to set the correct rpath on the dylib If installing from homebrew-cask do the install_name_tool fix automatically (I’m happy to put a PR for this).

Agreed as a short-term hack but the “right” OS X solution is to bundle OpenSSL with your software. As a longish-term OS X user/dev anything that asks the user to manually to install things before installing/running it points to a badly configured installer or application bundle.

Speaking as a long-time osx and brew user - your interim solution isn’t a solution that your target audience is going to accept. I hit it when I was trying to get C# support working in Visual Studio Code. The window does tell me what’s going on:

Finished
[ERROR] The debugger cannot be installed. A required component, OpenSSL, is not correctly configured.
In order to use the debugger, open a terminal window and execute the following instructions.
See https://www.microsoft.com/net/core#macos for more details.

  brew update
  brew install openssl
  mkdir -p /usr/local/lib
  ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
  ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/

But my immediate reaction was that Visual Studio Code was doing something insane with OpenSSL.

@nbellocam - thanks for the quick reply. What I ended up doing (may help some others), is I found out how to just update the OpenSSL version on my Mac to latest (1.0.2h) from source.

[http://bytefish.de/blog/net_core_mac_os/]

Once I did this, “openssl version” reported 1.0.2h, and the dotnet new command ran without errors.

I understand this might not be the BEST approach (if you had something else on your system depending on a specific version of OpenSSL), but it worked for me!

I followed the same instructions on the link @chanas mentioned, and I’m still getting the “Refusing to link” message. Anyone have any other ideas?

I think I may have been added to this conversation by mistake.

Thank you,

C. Hanas

Teacher of Principles of Engineering Teacher of Computer Science and Software Engineering HTHS Robotics & Coding Club Adviser High Technology High School 765 Newman Springs Rd Lincroft, NJ 07738

On Sun, Jul 31, 2016 at 9:20 PM, Justin Carlson notifications@github.com wrote:

I followed the same instructions on the link @chanas https://github.com/chanas mentioned, and I’m still getting the “Refusing to link” message. Anyone have any other ideas?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/cli/issues/3964#issuecomment-236470039, or mute the thread https://github.com/notifications/unsubscribe-auth/AHW1DGmWcsdAnm51jISXzuZAAATSTPx3ks5qbUnkgaJpZM4JYtzq .

@joshka regarding your comment on https://github.com/dotnet/sdk/issues/6690#issuecomment-236493536

Do you know is there a possible alternative for this on BigSur (and M1)? It seems there is no way to handle libssl/libcrypto and make it available to be used by AesGM ecncryption. I have tried many approaches, but DYLD_LIBRARY_PATH is ignored (even with SIP disabled), and symlinks are not being read.

@erensogut Did you follow the instructions at https://www.microsoft.com/net/core#macos?

I am also still getting this issue following the steps outlined:

brew update brew install openssl brew link --force openssl

more specifically I’m also trying to update python’s SSL but the following is not working for me as well.

brew install python --with-brewed-openssl

I resorted to building openssl myself following these steps:

http://stackoverflow.com/a/38710248

and using openssl version I can see that it has been installed correctly, however I am still unable to update python’s openssl through brew

@katopz If the instructions at https://www.microsoft.com/net/core#macos (Install pre-requisites) don’t work for you please open a new issue describing what you’ve done and what problem you’re having.

@evermeire this doesn’t sound like it would be related to the installation of openssl on OSX. Perhaps you could log this as a new issue?

Anyone figure out how to get the HttpClient in ASP.NET Core using SSL certificates to work on Azure. Currently, my code returns the following on Azure:

The specified CGI application encountered an error and the server terminated the process.

Hi all! Now it’s running.

I uninstalled OpenSSL, installed OpenSSL 1.0.1, linked brew with OpenSSL 1.0.1, executed ‘dotnet new’, ‘dotnet restore’ and ‘dotnet run’.

Everything worked well. Tks!

I have the same problem about that (2).