This guide was almost helpful, except it’s out of date – e.g. the Makefile.in patch it provides no longer applies cleanly – and simply doesn’t work – once you get the John The Ripper configure script to see the OpenSSL devel headers, it then just complains that it can’t find a valid libssl anyway.

Even the Pro version of John The Ripper, which isn’t cheap, doesn’t look like a good option since its web page has the hallmarks of something that hasn’t been updated in many, many years.  e.g. talk about support for Mac OS X 10.7 Lion being planned.

And although it appears to support using CommonCrypto instead of the now deprecated OpenSSL, that doesn’t work – even when configured that way it still compiles in code that requires OpenSSL, for SHA1.  Sigh.

Trying to get it to use a fresh build of OpenSSL (1.1.0) also seems an intractable failure – OpenSSL 1.1.0 out of the box produces libraries which don’t contain SSL_library_init, which is of course necessary for any OpenSSL user and foils any attempt to use the built libraries by way of missing symbol errors in the link phase.

And OpenSSL 0.9.8zh’s build system is just screwy.  By default it builds only 32-bit and only static libraries (no matter how hard you tell it to build shared ones).  You have to bypass its first layer of configery and do it ‘manually’, like so:

./configure --prefix=<install location> darwin64-x86_64-cc -no-shared enable-camellia

You can then configure JohnTheRipper to point to that version of OpenSSL, like so:

./configure CPPFLAGS='-I <OpenSSL install location>/include' LDFLAGS='-L <OpenSSL install location>/lib' OPENSSL_LIBS="-lcrypto"

Now it’ll finally get past the OpenSSL issues, and build successfully.

Note:  don’t use the Makefile.in patch provided in the aforelinked guide.  That actually breaks the build now, even if you properly apply it manually.