I am trying to port an OpenSSL-based C program from Linux to macOS, and I would like to use a library for TLS which is officially supported by the OS, because then the OS keeps that library up-to-date and secure without any extra work for me or the user of my application.

I though LibreSSL was officially supported in macOS and I have already ported my program have a LibreSSL backend, but I'm unsure of the state of LibreSSL within macOS. Is there any official documentation that addresses whether developers should treat the LibreSSL library as depricated or not?

PS: I've searched on Apple's developer site, but the official Apple documentation about encrypting network communication makes ABSOLUTELY NO mention of LibreSSL (which is not the same as OpenSSL).

  • Please focus on one issue per question/post, you can always ask several questions in parallel (assuming question 2 doesn't depend on an answer to question 1). Questions about "why does Apple do this and that" are always off-topic though.
    – nohillside
    May 2, 2018 at 20:04
  • Also I'm not sure whether "If you use OpenSSL in your publicly shipping apps, you must provide your own copy of the OpenSSL libraries, preferably as part of your app bundle; the OpenSSL libraries that OS X provides are deprecated" (from the documentation you linked, emphasis mine) does basically answer your question.
    – nohillside
    May 2, 2018 at 20:05
  • @patrix This is one question. The quesion is: "How official is libressl support". It's right there in the title. I will edit it for extra clarity on what I am asking.
    – rexroni
    May 2, 2018 at 21:18
  • 1
    For what it's worth, Apple makes no mention of LibreSSL on their Open Source Page going all the way back to Lion.
    – Allan
    Aug 26, 2018 at 2:59
  • 1
    @Allan Honestly that is the clearest answer to the question so far.
    – rexroni
    Aug 27, 2018 at 16:38

3 Answers 3


To answer the question asked:

How “official” is libreSSL support in High Sierra?

There is no official support. Apple makes available all Open Source code that it uses in macOS/OS X. From the latest version of High Sierra (10.13.3) all the way back to Lion 10.7.0, there is no mention of libreSSL.

This is not to say that it will not work if you choose to install the libraries. It's that they don't officially use the code in macOS. If you do get it working and something breaks when you upgrade macOS, it will be up you to fix it.

Apple has deprecated* OpenSSL and instead is utilizing Common Crypto, something Apple develops.

*Deprecated as in no longer developed but not removed. OpenSSL is still included for backward compatibility, but developers are notified that there is no further development and should begin to move to the newer technology.

  • Thanks! This was the only answer that actually used official, up-to-date documentation to answer the question
    – rexroni
    Aug 27, 2018 at 20:26
  • @rexroni Unfortunately, even though it is a straightforward answer, it is also incorrect. Common Crypto does not support TLS at all, so it is not a replacement for LibreSSL for TLS support. If you look at the top of the linked page, it also says that this page is no longer updated. If you take a look at my answer to your question, which was posted some months earlier, I have actually linked the official and up-to-date documentation, which is still being updated - and which is for the actual TLS support that Apple encourages developers to use - namely Secure Transport.
    – jksoegaard
    May 30, 2019 at 13:15
  • @jksoegaard this question was never about whether or not Secure Transport supported or even preferred. We both agree on that. This question was about how to treat the libreSSL library and your answer did not address libreSSL at all, but this answer did.
    – rexroni
    May 31, 2019 at 15:25
  • @rexroni Well, I think that’s stretching it a bit. The question specifically says in the first section that he wants to use an official supported library. I then answer that the official supported library is Secure Transport. I don’t see how it will help him porting his application if the answer is just that his idea with LibreSSL is wrong, and then send him the way of a library that doesn’t even support TLS...
    – jksoegaard
    May 31, 2019 at 16:55
  • @jksoegaard Well, I wrote the question, and I can tell you that the first section is context as to why the question was being asked at all. You'll notice in the second I mentioned that I had already written a port of my software to libressl. But if I released that version of my software, it would be dynamically loading the system's libtls.so. But if I was going to rely on that I needed to know how official libressl support was. Hence the title in the question, and the very clear restatement of the question in the last sentence before the PS.
    – rexroni
    Jun 3, 2019 at 1:55

MacOS provided openssl-0.9.8 (when the world was using 1.0.2, and contemplating 1.1 and 1.1.1) until High Sierra release. Now in MacOS 10.13.5 it's libressl-2.2.7, while the current libressl is 2.7.4.

It looks like MacOS-provided LibreSSL does not come with any engines, and it is unclear whether it's possible to even add an engine to it. That means - no openssl using keys on hardware tokens accessible via PKCS#11, no hardware RNG accessible via PKCS#11 or RDRAND, etc. UPDATE: It also doesn't seem to have the include files required to compile your applications. So it seems that you cannot build your software against MacOS LibreSSL even if you wanted to (well, you might be able to by downloading LibreSSL-2.2.7 yourself, etc. - but I'm very sure it isn't worth the hassle).

Since I don't want to write code that runs only on Mac, I can't afford to get stuck with Apple Secure Transport or such.

Therefore my personal recommendation would be to install and work with a "real" openssl, installing it via Macports (as I did for the "production" stuff on my systems) or Brew. In that case, the package maintainers would track the updates and security fixes for you, but you maintain compatibility with your Linux code with minimal efforts.

  • Hey thanks for detailed investigation! For now I ended up sticking with my openssl backend, but because I can't ask all my users to install openssl separately, I am statically linking the openssl libraries to my binary, as suggested by the depricated OpenSSL on Mac documentation that I linked to. It is not ideal, but maybe someday I'll write a SecureTransport backend.
    – rexroni
    Jun 27, 2018 at 3:03
  • Linking OpenSSL statically is what OpenSC github.com/OpenSC/OpenSC.git is doing, quite successfully.
    – Mouse
    Jun 28, 2018 at 3:34
  • The 2.2.7 tag of LibreSSL (on github) is 3 years old. Is that really the default openssl provided on macOS today? That makes no sense to me :-/... I am not sure I understand what openssl is provided by the system on my High Sierra... Jul 24, 2018 at 20:58
  • This is about what Apple does to MacOS, up to and including High Sierra. Nobody said it was supposed to make any sense. :-) :-( As for what OpenSSL is provided by the system - do '/usr/bin/openssl version' and you'll see for yourself. Whether an old LibreSSL (2.2.7) is better than an old OpenSSL (0.9.8) is another question.
    – Mouse
    Aug 26, 2018 at 2:15
  • 1
    I'm seeing LibreSSL 2.6.5 as the installed version on my brand new MacBook Pro.
    – Andy
    Jan 4, 2019 at 23:59

The only officially supported TLS library on macOS is Apple Secure Transport:

Secure Transport

Secure network communication using standardized transport layer security mechanisms.

The Security.SecureTransport API gives you access to Apple's implementation of Secure Sockets Layer version 3.0 (SSLv3), Transport Layer Security (TLS) versions 1.0 through 1.2, and Datagram Transport Layer Security (DTLS) version 1.0.

This means that LibreSSL is NOT supported by Apple for use as a TLS library in your application.

This means that as a responsible developer, you should either:

a) Use Apple Secure Transport

b) Statically link with a library, such as LibreSSL, you support yourself


c) Dynamically link with a a library, such as LibreSSL, that you clearly indicate to the user that he needs to support himself through for example HomeBrew

  • Thank you for answering! This is definitely an alternative I am considering but this isn't actually an answer to the question, which is about how to treat the LibreSSL library.
    – rexroni
    May 3, 2018 at 12:40
  • What I’m saying is that Apple supports Secure Transport for what you’re doing. Not LibreSSL.
    – jksoegaard
    May 4, 2018 at 14:31
  • 1
    But how do you actually know that LibreSSL isn't supported? Evidence that "X IS supported" is not the same as evidence that "Y is NOT supported", particularly in the case where Apple supports multiple other SSL APIs, like the CFNetwork API and the URL Loading System.
    – rexroni
    May 5, 2018 at 4:16
  • 1
    I think it is the other way round. Something is only supported if it is explicitly documented as such by Apple. You can’t say that everything is supported by Apple, unless they say it’s not.
    – jksoegaard
    May 5, 2018 at 8:28
  • I suppose in most situations your are right. But this is a somewhat special situation where OpenSSL was depricated (implying previously supported, but I haven't been developing for Mac long enough to know), then it was removed and replaced with LibreSSL, which smells like that has been a plan in the works for a long time, and that LibreSSL would be supported. It seems crazy that they would go through the effort of porting whatever software they have that used to depend on OpenSSL to work with LibreSSL only to list LibreSSL as "depricated" the instant they put it on their system.
    – rexroni
    May 5, 2018 at 13:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .