Macos Openssl


The Webmin install preamble mentions to check Perl + OpenSSL versions. PB 667+X11+TCSH, Mac OS X (10.3.9) Posted on Mar 6, 2006 6:48 AM. #install new OpenSSL: brew install openssl # generate private key and enter pass phrase openssl genrsa -des3 -out privatekey.pem 2048 # create certificate signing request, enter '' as a 'Common Name', leave 'challenge password' blank.

  1. Macos Openssl Libressl
  2. Mac Update Openssl
  3. Macos Update Openssl
  4. Macos Openssl Headers

Some people have offered to provide OpenSSL binary distributions for selected operating systems. The condition to get a link here is that the link is stable and can provide continued support for OpenSSL for a while.

  1. Available for: OS X El Capitan 10.11.6, macOS Sierra 10.12.6, macOS High Sierra 10.13.1. Impact: An application may be able to read restricted memory. Description: An out-of-bounds read issue existed in X.509 IPAddressFamily parsing. This issue was addressed with improved bounds checking. CVE-2017-3735: found by OSS-Fuzz.
  2. This affects OpenSSL versions including 1.0.1f which is the version on my up-to-date Mavericks computer Mac (because I used port/brew to install other software which updated my openssl without me realizing it): $ openssl version OpenSSL 1.0.1f 6 Jan 2014 This demonstrates I am not using the Mavericks version of OpenSSL.

Note: many Linux distributions come with pre-compiled OpenSSL packages. Those are already well-known among the users of said distributions, and will therefore not be mentioned here. If you are such a user, we ask you to get in touch with your distributor first. This service is primarily for operating systems where there are no pre-compiled OpenSSL packages.

Important Disclaimer:The listing of these third party products does not imply any endorsement by the OpenSSL project, and these organizations are not affiliated in any way with OpenSSL other than by the reference to their independent web sites here. In particular any donations or payments to any of these organizations will not be known to, seen by, or in any way benefit the OpenSSL project.

Use these OpenSSL derived products at your own risk; these products have not been evaluated or tested by the OpenSSL project.

Third Party OpenSSL Related Binary Distributions
Product Description URL
OpenSSL for Windows Works with MSVC++, Builder 3/4/5, and MinGW. Comes in form of self-install executables.
OpenSSL for Windows Pre-compiled Win32/64 libraries without external dependencies to the Microsoft Visual Studio Runtime DLLs, except for the system provided msvcrt.dll.
OpenSSL for Windows Reproducible 1.1.x builds with latest MinGW-w64/GCC, 64/32-bit, static/dynamic libs and executable.
OpenSSL for Solaris Versions for Solaris 2.5 - 11 SPARC and X86
OpensSSL for Windows, Linux, OSX, Android Pre-compiled packages at package manager:
Windows x86/x86_64 (Visual Studio 10, 12, 14, 15)
Linux x86/x86_64 (gcc 4.6, 4.8, 4.9, 5, 6, 7)
OSx (Apple clang).
Cross-building ready recipe: Linux ARM, Android.
OpenSSL for Windows Pre-compiled Win32/64 1.0.2, 1.1.0 and 1.1.1 libraries without external dependencies, primarily built for François Piette's Internet Component Suite (ICS) for Embarcadero (Borland) Delphi and C++ development tools, but may be used for any Windows applications. The OpenSSL DLLs and EXE files are digitally code signed 'Open Source Developer, François PIETTE', so applications can self verify them for corruption.
OpenSSL for Windows Pre-compiled 64-bit (x64) and 32-bit (x86) 1.1.1 executables and libraries for Microsoft Windows Operating Systems with a dependency on the Microsoft Visual Studio 2015-2019 runtime. The distribution may be used standalone or integrated into any Windows application. The distribution's EXE and DLL files are digitally signed 'FireDaemon Technologies Limited'.

Some third parties provide OpenSSL compatible engines. As for the binaries above the following disclaimer applies:

Important Disclaimer:The listing of these third party products does not imply any endorsement by the OpenSSL project, and these organizations are not affiliated in any way with OpenSSL other than by the reference to their independent web sites here. In particular any donations or payments to any of these organizations will not be known to, seen by, or in any way benefit the OpenSSL project.

Third Party OpenSSL compatible engines
Product Description URL
Intel® QuickAssist Technology engine Intel® QuickAssist Technology ( provides acceleration for a number of cryptographic algorithms. QAT_engine adds support for Intel® QuickAssist Technology to OpenSSL-1.1.0 via the ENGINE framework. The definitive list of algorithms exposed into OpenSSL (a subset of those supported in the device) is defined on the associated github page.
ATECCX08 engine Support for the Atmel ATECC508A ( hardware to provide secure key storage, ECC cryptographic calculations for the ECC NIST P-256 curve, and FIPS certified hardware Random Number Generator.
GOST engine A reference implementation of the Russian GOST crypto algorithms for OpenSSL. The presence of this engine also enables the built-in OpenSSL support for GOST TLS ciphersuites. (Note: this engine is for OpenSSL version 1.1.0 and above. Previous versions of OpenSSL used a built-in GOST engine)
ISARA Radiate Solution Suite OpenSSL Connector Commercially available engine and source code patch for OpenSSL 1.0.2 branch. The ISARA Radiate OpenSSL Connector lets you implement OpenSSL using quantum safe algorithms. ISARA Radiate ( gives you the cryptographic building blocks to create applications that will resist attacks by quantum computers.
BEE2EVP engine Implements the Belarusian national cryptography: symmetric and public-key encryption, MAC, AEAD, hashing, digital signature. Encapsulates the Bee2 core cryptographic library into OpenSSL using the EVP interface.
Retrieved from ''


How to Compile OpenSSL 1.1.1 for Apple Silicon

You have an app on the Mac App Store which depends on OpenSSL for receipt validation, among other things. This validation may be done through Receigen, Swifty Receipt Validator, or your own home-grown receipt validation logic.

But Apple recently announced another instruction set that you need to support in your mac app: ARM64. These new machines could come as early as Big Sur’s general availability, which is likely in October 2020. This means that you have about three months left to update your macOS application.


Unfortunately CocoaPods hasn’t offer any OpenSSL distributions for Apple Silicon macintosh computers yet. Sure there are a few pre-compiled ARM64 binaries but those links against iOS frameworks, not macOS.

Wouldn’t it be great if you have your Mac App ready for Apple Silicon on the same day Big Sur is on Golden Master?

Here are the steps that you need to do to get a copy of OpenSSL ready for inclusion in your Universal 2 application for the Mac:

Macos Openssl Libressl

  1. Download OpenSSL 1.1.1g sources.
  2. Extract the archive into two different folders, one for Intel and the other for ARM instruction sets, respectively.
  3. Configure and compile each separately.
  4. Join results of the two together to create a Universal Library.

In this article I’m going to assume that you are going to extract OpenSSL sources into sibling folders with the following names:

  • openssl-1.1.1g-x86_x64 – for the Intel build.
  • openssl-1.1.1g-arm64 – for the ARM build.

Building the Intel Half

Mac Update Openssl

Building the x86_64 portion would be straight-forward since this is currently supported by OpenSSL 1.1.1g. You need to extract the OpenSSL sources into a dedicated folder for the architecture, run configure and then make. Optionally set the macOS deployment target if you need your app to run on earlier versions of the operating system.

You can find an example below. Pay special attention on the arguments to the Configure script.

By the time make completes, you should get four files that comprises of the static and dynamic libraries of OpenSSL.

  • libssl.1.1.dylib
  • libcrypto.1.1.1.dylib
  • libssl.a
  • libcrypto.a

Building the ARM Half

However the arm64 portion requires changes to OpenSSL’s build configuration as the macOS build of the instruction set is not currently supported by the library.

Having extracted the OpenSSL sources (be sure extract it into a separate location than the one you’ve used to build the Intel portion), then modify file Configurations/10.main.conf to add the macOS arm64 build configuration. Add the following snippet at around line 1560, right under the entry for “darwin64-x86_64-cc”.

(Special thanks to OpenSSL PR 12254 for the above configuration snippet).

When you’re done, the file should look like the following:

Then run Configure and make similar to before. Take note that the Configure script takes a different set of arguments.

By the time make completes, you would get four files that comprises of the static and dynamic libraries of OpenSSL, having the same file names as the ones previously compiled for Intel. This is why you should create a copy for each architecture and compile it in two different folders.

Creating Universal Libraries

Having the libraries compiled for the respective Intel and ARM64 instruction sets, the last step would be combining the two halves of the each library file into their respective universal library files. Use lipo for this, as follows.

When you’re done combining the library files, check them using the file tool and verify that indeed you have a universal library.

If you use OpenSSL for license validation, you should use the static library version. Which are the libcrypto.a and libssl.a files. Static linking reduces the risk of code injection via library replacement. In other words, it’ll be harder to for crackers to replace the OpenSSL libraries inside your app bundle and make your app use their compromised replacement version instead.

Nevertheless if you use OpenSSL as dynamic libraries, then you would need to change its install names be embeddable into your app bundle’s Frameworks folder. Plain compilation of OpenSSL dynamic libraries are meant to be installed in a shared folder.

Use install_name_tool on the dynamic versions of the library files as follows:

As always, it’ll be prudent to check your work. Use otool -D to print the install name of a dynamic library.

Next Steps

In case you’re in a hurry, I’ve compiled these libraries for you that you can download and drop them into your project. These were built on Xcode 12 Beta 4 running on the Apple Silicon version of Big Sur. These library files are temporary stop-gap until OpenSSL officially support Apple Silicon.

This article was tested with Xcode 12 Beta 4 running on the Apple Silicon version of Big Sur Beta 4. You don’t need an Apple Silicon mac to compile libraries or applications for the processor — Xcode 12 can produce ARM64 binaries even when running on Intel macs. However to test the ARM64 half of a Universal Binary you would need an Apple Silicon mac.

An Apple Silicon mac can run both the Intel and the ARM64 portions of a universal binary application. But not the other way around. Intel binaries are emulated under Rosetta 2 on Apple Silicon, but there is no emulation of ARM64 on Intel-based mac.

But even when you don’t have an Apple Silicon Mac (yet), merely compiling for Universal Binary would be a good start. You’ll know which pre-built 3rd party libraries to update, for which OpenSSL is likely one of several. There are likely ARM-related compiler warnings to heed out for.

Why wait? Get your Xcode Beta copy today and start building your Mac app for ARM64!

Until next time.

Macos Update Openssl

Macos Openssl Headers

Leave a Reply