OpenSSL: no "legacy" provider

[Thierry Lelégard]

Hi John,

Thanks for your response. First, let me say that I am not a DragonFlyBSD specialist.

Let me also provide some context. My project compiles on Linux, macOS, FreeBSD,
NetBSD with OpenSSL. I have an issue on DragonFly (and another one on OpenBSD
but this is obviously off-topic here). The project also works on Windows but
using the native MS cryptographic library, not OpenSSL.

Most users are on Linux, Windows, macOS, and maybe FreeBSD. I try to expand the
supported base to all BSD systems.

On DragonFly, I use the OpenSSL package which was installed using "pkg install openssl".

Using LibreSSL is not an option. When LibreSSL was forked, OpenSSL was in version 1.x
and LibreSSL was compatible. This is no longer the case. The API's have diverged, not
that much, but sufficiently to break applications using modern v3.x functions.

So, at some point, using the real OpenSSL became a necessity for some applications.
This will be more and more the case when more applications use the v3 API. I must
add that LibreSSL was created, I think, in response to the infamous HeartBleed bug,
also considering that the code was crappy. This situation has changed. Because so
much of the Internet relied on OpenSSL, a general effort was provided and, somehow,
the quality has been improved to some acceptable level. About cryptography (my
concern), all improvements are implemented on OpenSSL, especially the optimizations
for AVX512 (OpenSSL 3.1) and Arm64 SIMD and SVE. Today, LibreSSL is less relevant,
less at the state of the art. 

This is why I need OpenSSL, the one which is in /usr/local, not the default LibreSSL.

In this OpenSSL package, the "legacy" provider is missing. This is the problem
I need to fix.

-Thierry Lelégard (thierry at lelegard.fr)


-----Original Message-----
From: John <dragonflybsd at marino.st>
To: Thierry <thierry at lelegard.fr>
Date: Friday, 6 February 2026 3:06 PM CET
Subject: Re: OpenSSL: no "legacy" provider


I need to add this -- on dports you might be limited to new libreSSL.  Ravenports supports simultaneous installations of SSL (openssl 1.1, openSSL 3.0, libreSSL x, etc) whereas dports can't do that due to conflicting installation.


On Fri, Feb 6, 2026 at 8:03 AM John Marino (DragonFly) <dragonflybsd at marino.st> wrote:

So between FreeBSD and NetBSD you are mixing up your SSL sources.  You quoted the base SSL on FreeBSD and you quoted the pkgsrc version of openssl.


So I assume you are looking at the base SSL of DragonFly which is actually an older libreSSL.


What you should be looking at is the dports or Ravenports version of openssl 3.0, because you would be linking with those, not the base SSL library.


For ravenports, openssl3 does indeed install a legacy.so.
https://www.ravenports.com/catalog/bucket_B9/openssl30/std/
https://raw.githubusercontent.com/Ravenports/Ravenports/master/bucket_B9/openssl30


John




On Fri, Feb 6, 2026 at 7:58 AM Thierry Lelégard <thierry at lelegard.fr> wrote:

Hi,

I maintain an open source project (tsduck.io) which uses OpenSSL as cryptographic
library. For some old format, DES is used. No need to comment why DES shall no
longer be used, it's for management of old data only.

With OpenSSL, DES is now part of the "legacy" provider module. The provider must
be explicitly activated in the application.

On FreeBSD 15.0 with OpenSSL 3.5.4, the legacy provider module is in
/usr/lib/ossl-modules/legacy.so.

On NetBSD 9.3 with OpenSSL 3.6.0, it is in /usr/pkg/lib/ossl-modules/legacy.so.

However, on DragonFly BSD 6.4.2 with OpenSSL 3.0.15, there is no "legacy" module.
The only SSL module is the "fips" one in /usr/local/lib/ossl-modules/fips.so.
And of course, all DES operations fail.

It is not a matter of OpenSSL version, the principle of "providers" was introduced
in 3.0 and the legacy provider was created to host old algorithms.

Is there a "legacy" OpenSSL module with DragonFly BSD or was it completely removed
from the OpenSSL package? I found no additional package which could install it.

Thanks for your help.

-Thierry Lelégard  (thierry at lelegard.fr)